On Mon, Aug 4, 2014 at 7:13 AM, Uranuz via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote: > I am real noob about grammar description languages so I need some > explanation about it. As far as I understand expressions in curly bracers > are used to modify syntax tree just in process of parsing instead of > modifying it after?
Yes, that's it. Or at least that's the way Pegged does it. I'm not such a specialist myself, I just dabbled in it to write Pegged. As I understand it, many parsers do not produce a parse tree, they only 'return' what their embedded action tell them to. Personally, I have a slight preference to using the parse tree once it's complete. a) Because that way I have access to all the information (parent nodes, sibling nodes, even far way) whereas when doing it with an action means you only have the local, current node context and b) because it decouples steps that are in my mind separated anyway: parsing, then producing a value out of the parse tree. A bit like ranges in D, and Walter and his components programming speech. > How I could use PEGGED to map some code to these parsed expressions to > generate code that will perform operations defined by this grammar? Should I > walk around all the syntax tree and just append code to some string and mix > it in then or are there some features for code generation? You can insert semantic actions inside the grammar definition, as is done by Dustjs, or you can have a function walking the tree afterwards. For D, since Pegged works at compile time, you can have your parse tree at compile time. Use the walking function to generate D code (a string) and mix it in. enum parseTree = Grammar(input); // CT parsing string codeMaker(ParseTree pt) { ... } // recursive walker mixin(codeMaker(parseTree)); See https://github.com/PhilippeSigaud/Pegged/wiki/Using-the-Parse-Tree If what you need is generating Javascript code, no need to do that at compile-time: you can assemble the JS code as a string at runtime and then write it to a file somewhere, I guess. > Something that I was thinking about is comparision of resulting syntax tree > to check if it was correctly implemented. It would be great if different > gramar parsers will output result in common format (JSON or XML for example) > and it will be possiple to compare them for equality. But different parsers > have different internal format of tree so maybe creating some transformation > is possible. With this feature it could be possible to say if parser is > working correctly. Different formats and also different languages. I don't see how you can compare a parse tree that's a D object and another tree made by dustjs: you never see the AST produced by dust, you only see the resulting JS code.