Parser Finished

I finally finished the parser! It can now parse a text file and produce the appropriate syntax tree. The next step will be to produce actual machine code from that tree. I think, however, I will leave this task for the future. Right now, I'm itching to get back to my other project. Not much else to report, hopefully I'll have new screenshots next week.

Parse All the Things

Packrat Parsers are interesting things. They basically try every possibility everywhere. Surprisingly, this turns out to be fast because they only do it once. They get away with this because they record every single thing they do. In recent years, computers started having enough memory that this idea is no longer completely ridiculous.

Been continuing work on the parser I started. The first stage is more or less complete. That is to say, I can give the parser a file, ask it if that file is valid, and get a yes-or-no answer. However, it's going to need to do a little more than that before it's useful. Ultimately, I will need a syntax tree representing the file. There are still a few more grammar rules that I need to add, but I'm going to cross those bridges when I come to them.

I've also been playing Skyrim in my spare time and getting a lot of ideas for things I could add to my other project. I got an idea for how to better organize possible features so I don't get inundated with all the possibilities. If I get burnt out on the parser, you might actually see some progress being made on that project someday.

Parsing Problems

Last week I mentioned that I'm going to be working on a parser for the programming language I designed. I've been trying to refine and simplify the language's grammar before starting that. For the most part, the language is C-like and most of the grammar can be summed up with a precedence chart. However, a few of the operators work strangely and throw a wrench into that.

The best example I can give is the colon operator. The colon operator fills the roles of both constructors and type casts. It is typically used like this:

foo int: bar + 10,

Which declares a variable, foo, of type int and initializes it to bar + 10. When the colon operator is used for casts, it might look something like this:

foo = bar + int: baz + 1,

Which is parsed like this:

foo = (bar + (int: (baz + 1)),

Basically, everything to the right of a colon 'belongs' to it. However, this creates a problem. It doesn't fit neatly into the precedence chart. The left side of the colon has a different precedence than the right. This makes the language's grammar more complex.

The behavior of the colon operator is usually pretty intuitive when actually writing code. Likewise, it's not particularly hard on the parser. However, it does substantially complicate learning the language. Instead of a simple precedence chart, I have an unwieldy spreadsheet.

The colon operator is not the only thing complicating the grammar. Right now, I'm trying to change things to reduce weird parsing rules. It cases like the colon operator, I would like to preserve it's general usage without making the user type a lot more.