I'm currently learning about parsing but i'm a bit confused as how to generate an AST. I have written a parser that correctly verifies whether an expressions conforms to a grammar (it is silent when the expression conforms and raises an exception when it is not). Where do i go from here to build an AST? I found plenty of information on building my LL(1) parser, but very little on then going on to build the AST.
My current code (written in very simple Ruby, and including a lexer and a parser) is found here on github: https://gist.github.com/e9d4081b7d3409e30a57
Can someone explain how i go from what i have currently to an AST?
Alternatively, if you are unfamiliar with Ruby, but know C, could you tell me how i build an AST for the C code in the recursive descent parsing wikipedia article.
Please note, i do not want to use a parser generator like yacc or antlr to do the work for me, i want to do everything from scratch.
Thanks!
You need to associate each symbol that you match with a callback that constructs that little part of the tree. For example, let's take a fairly common construct: nested function calls.
Your terminal tokens here are something like:
And your nonterminal symbols are something like:
Obviously the second alternative above for the rule
FUNCTION_CALL
is recursive.You already have a parser that knows it has found a valid symbol. The bit you're missing is to attach a callback to the rule, which receives its components as inputs and returns a value (usually) representing that node in the AST.
Imagine if the first alternative from our
FUNCTION_CALL
rule above had a callback:That would mean that the AST resulting from matching:
Would be:
Now to extrapolate that to the more complex
a(b())
. Because the parser is recursive, it will recognize theb()
first, the callback from which returns what we have above, but with "b" instead of "a".Now let's define the callback attached to the rule that matches the second alternative. It's very similar, except it also deals with the argument it was passed:
Because the parser has already recognized
b()
and that part of the AST was returned from your callback, the resulting tree is now:Hopefully this gives you some food for thought. Pass all the tokens you match into a routine that constructs very small parts of your AST.
OK, so here I am again (and nope, this answer has nothing to do with Scintilla per se; although it WAS part of a Programming Language / Compiler Design adventure of mine, once).
Have you considered using Lex / Yacc ? That's what their main reason of existance is (= parsing; writing Lexers and Parsers, and thus, the way to build
AST
s), plus they are absolutely C-friendly.Here's a rough example (taken from my own open-sourced MathMachine compiler).
mm_lexer.l (the Lexer)
mm_parser.y (the Parser)
Sidenote : Unfortunately, I can't help you with anything Ruby-specific (since I'm not only an absolute newbie, but actually - for some unknown reason - I hate it); but, even in C, I hope this'll give you a rough idea... :-)