AST Generation Interface

[Baltoli]

The interface by which a user of the peggo library can have an AST generated needs to be thought about.

The user of the library presumably has an AST structure that is somewhat related to the grammar of the language that they're parsing, and that has non-terminal nodes as their key structural units. This would seem to suggest that some kind of mapping from non-terminals to user-supplied code is the way to go.

An initial thought is that it's difficult to properly glue user structures together into a tree if the constructor functions are separated. So the better solution is to build some better ways of extracting structure from a parse tree, and have the user call a construction function on the root of the parse tree.

The important things that the parse tree exposes are:

• Source ranges for productions
• The children of a production

The terminal nodes of a production probably aren't that interesting to the user, so constructors will be looking at the source text and the structures extracted recursively from the non-terminal children.

Next step is to write some experimental code and see what the nicest interface to this part of the library is going to be.

[Baltoli]

Have implemented a parser for a simple arithmetic grammar. The next step should be to turn this into some kind of binary AST (rather than the n-ary parse tree suggested by the repetition in the parsing structures).

Code for this exploration is on the ast-build branch for now.

[Baltoli]

Have merged the arithmetic AST implementation for now - it has a basic implementation of something like what we'll want to make generic in the future.

[Baltoli]

Thinking about it, I'm not sure how much of an interface it's worth putting on AST generation. Any consumer of the library will have their own AST structure, so enforcing convention on them isn't such a great idea.

Maybe worth writing up a guide on how best to write AST extractors from a parse tree?