Help with porting grammar from PEGjs to D for dustjs project!

Philippe Sigaud via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Aug 3 22:26:36 PDT 2014


On Mon, Aug 4, 2014 at 7:13 AM, Uranuz via Digitalmars-d-learn
<digitalmars-d-learn at 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.


More information about the Digitalmars-d-learn mailing list