[antlr-interest] passing parameters...
Gavin Lambert
antlr at mirality.co.nz
Tue Dec 30 16:32:35 PST 2008
At 12:47 31/12/2008, Pady Srinivasan wrote:
>statementBlock[boolean result]
> : assignment[$result] | compoundStatement[$result]
> ;
>
>compoundStatement[boolean result]
> : ({$result}?=> ^(BLOCK statement*) )
> ;
>
>assignment[boolean result]
> : ({$result}?=> ^(EVAL statementExpression) )
> ;
>
>In the generated java class, I see code generated in the
>statement() method as follows: ( and is not compiling )
>
>..
> else if ( (LA2_0==BLOCK||LA2_0==EVAL) &&
((result)))
>{
> alt2=2;
> }
>..
>
>Where did the "result" variable come into the statement() method
?
Predicates (especially left-edge predicates) may be hoisted out of
the containing rule into parent rules, as an aid to
disambiguation. The presumption is that any predicate in that
position is helping to determine whether or not the rule is
appropriate to be invoked at all, and as such should generally
restrict itself to checking the input stream and internal parsing
state.
Using parameters (or return values) in such predicates is
problematic because they're not accessible in the parent
rule. You can use scopes to work around this, but:
... this isn't really an appropriate use of the predicates
anyway. The nodes will still be in the incoming input stream --
you can't simply skip the rule if you don't care about them,
you'll end up getting confused since you haven't dealt with the
subtree and moved on. A better way to write these rules, if you
still want to use a parameter-based approach, would be something
like this:
compoundStatement[boolean process]
: ^(BLOCK ({$process}? => statement* | .*))
;
assignment[boolean process]
: ^(EVAL ({$process}? => statementExpression | .))
;
Of course, it'd be even tidier if you got rid of the parameters
entirely and just used the approach I mentioned yesterday.
More information about the antlr-interest
mailing list