semantic actions

[philippesigaud]

semantic actions

[PhilippeSigaud]

On Sat, Aug 18, 2012 at 9:51 PM, callumenator [email protected]:

When i try to create a grammar module with semantic actions, like

asModule("parser","
Number < [0-9]+ {doStuff} "
);

The generated grammar always gives:

static assert(false, Bad grammar: ["PEGGED.Grammar failure at pos [index: 25, line: 1, col: 24]", "Pegged.EOI failure at pos [index: 25, line: 1, col: 24]"]);

Are semantic actions currently implemented? What is the correct way to use
them?

Yes yes, they are implemented (I use them in the xml example).

Hmm.

OK, I think I get it: as written, the PEG grammar allows for only one
suffix. I guess I never used it otherwise.

I just pushed a modification in Pegged allowing for more than one suffix.
It seems to generate the correct code, but I haven't tested it heavily,
obviously. Can you pull this new version of Pegged and tell me if it does
what you need?

[callumenator]

For the example I gave, that latest pull does fix it, but that example was just a trivial one I made up for testing (sorry!). The grammar I am actually trying to add a semantic action to is the arithmetic expression example you give. Without any semantic actions it works fine, however if i do this:

Expression < Expr
            Expr     < {doStuff} Factor AddExpr*
            AddExpr  < ('+'/'-') Factor
            Factor   < Primary MulExpr*
            MulExpr  < ('*'/'/') Primary
            Primary  < Parens / Number / Variable / '-' Primary
            Parens   < '(' Expr ')'
            Number   < [0-9]+
            Variable < Identifier

I get that same bad grammar assertion. It doesn't seem to matter where I put the {doStuff}. Maybe I am trying to use it the wrong way.

[callumenator]

Actually that latest pull now breaks the arithmetic example completely for me. Just the grammar straight from arithmetic.d gives this aasertion when built as module:

static assert(false, `Bad grammar: ["PEGGED.Grammar failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Definition failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Expression failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Sequence failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Suffix failure at pos [index: 24, line: 1, col: 23]", "Pegged.Or(OPTION, ONEORMORE, ZEROORMORE, NamedExpr, WithAction) failure for sub-expr # 0 `OPTION` at pos [index: 24, line: 1, col: 23]", "PEGGED.OPTION failure at pos [index: 24, line: 1, col: 23]", "Pegged.Lit!(?) failure at pos [index: 24, line: 1, col: 23]"]`);

[PhilippeSigaud]

On Sun, Aug 19, 2012 at 1:32 AM, callumenator [email protected]:

For the example I gave, that latest pull does fix it, but that example was
just a trivial one I made up for testing (sorry!). The grammar I am
actually trying to add a semantic action to is the arithmetic expression
example you give. Without any semantic actions it works fine, however if i
do this:

Expression < Expr
Expr < {doStuff} Factor AddExpr*
AddExpr < ('+'/'-') Factor
Factor < Primary MulExpr*
MulExpr < ('*'/'/') Primary
Primary < Parens / Number / Variable / '-' Primary
Parens < '(' Expr ')'
Number < [0-9]+
Variable < Identifier

I get that same bad grammar assertion. It doesn't seem to matter where I
put the {doStuff}. Maybe I am trying to use it the wrong way.

A semantic action must be put after an expression, like

Factor {doStuff} AddExpr* {otherStuff}

If you want an entire rule to be affected by an action, either put it in
parentheses:

(Factor AddExpr*) {doStuff}

or use the 'action-arrow', without any intervening space between the '<'
and the action:

Expr <{doStuff} Factor AddExpr*

As for the pull, I realized afterwards that I should have added the
possibility for more than one prefix also :(

[PhilippeSigaud]

Actually that latest pull now breaks the arithmetic example completely for
me. Just the grammar straight from arithmetic.d gives this aasertion when
built as module:

static assert(false, Bad grammar: ["PEGGED.Grammar failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Definition failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Expression failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Sequence failure at pos [index: 24, line: 1, col: 23]", "PEGGED.Suffix failure at pos [index: 24, line: 1, col: 23]", "Pegged.Or(OPTION, ONEORMORE, ZEROORMORE, NamedExpr, WithAction) failure for sub-expr # 0OPTIONat pos [index: 24, line: 1, col: 23]", "PEGGED.OPTION failure at pos [index: 24, line: 1, col: 23]", "Pegged.Lit!(?) failure at pos [index: 24, line: 1, col: 23]"]);

Indeed...

That was a '+' instead of a '*' . The parser was waiting for at least one
suffix after each expression.

I corrected that and also allowed for more and one prefix. I just pushed
it, sorry for the bug.

[callumenator]

Yep it was those Factor {doStuff} AddExpr* {otherStuff} type expressions that were failing, that last update seems to fix it all, many thanks!

Another small issue (which can be worked around with parenthesis around the RHS expressions like you mentioned above):
Rule1 <{Action1} works, while Rule1 <-{Action1} and Rule1 <~{Action1} do not.

[PhilippeSigaud]

On Sun, Aug 19, 2012 at 10:44 PM, callumenator [email protected]:

Yep it was those Factor {doStuff} AddExpr* {otherStuff} type expressions
that were failing, that last update seems to fix it all, many thanks!nk

Good to know, and thanks for reporting.

I'm working on a new engine behind Pegged (still top-down recursive-descent
for now), and I find it to be one-to-two orders of magnitude faster. (50
times faster occurs frequently). I'm slowly upgrading the engine to get all
the current functionalities working, so stay tuned.

Another small issue (which can be worked around with parenthesis around

the RHS expressions like you mentioned above):
Rule1 <{Action1} works, while Rule1 <-{Action1} and Rule1 <~{Action1} do
not.

That's because I defined <{ ...} to be an arrow by itself. I guess I
could delete this arrow and just use the convention that a lone action
block by itself before any sub-rule means the action should be applied to
the entire rule, but this changes the associativity of action blocks: most
of the times, they are after the rules they affect.

Oh, btw, while I think about it: another contributor commit templatized
ParseTree, Output and other parts of Pegged. So for a semantic action,
you should not use:

Output myAction(Output o)
{
...
}

The docs need to be updated on this (TODO). You should use a function
template:

O myAction(O)(O o)
{
...
}

That way your action can be applied on the current templated structs.

[callumenator]

I'm working on a new engine behind Pegged (still top-down recursive-descent
for now), and I find it to be one-to-two orders of magnitude faster.

That's awesome news! I have only been using pegged the last couple of days (writing a little VM for an OpenGL interpreter) and it is just sooo cool to go from string grammar to AST with a simple Rule.parse(), and have semantic actions executed as they are parsed. I'll definitely stay tuned.

[PhilippeSigaud]

On Sun, Aug 19, 2012 at 11:13 PM, callumenator [email protected]:

I'm working on a new engine behind Pegged (still top-down
recursive-descent
for now), and I find it to be one-to-two orders of magnitude faster.

That's awesome news! I have only been using pegged the last couple of days
(writing a little VM for an OpenGL interpreter) and it is just sooo cool to
go from string grammar to AST with a simple Rule.parse(), and have semantic
actions executed as they are parsed. I'll definitely stay tuned

That's great you like Pegged! The engine is almost OK (just have to deal
with parameterized rules and grammars). For now, it parses strings only (no
wstring or dstring), since I found it to represent 99% of my need, even for
my non-English language.