[antlr-interest] Re: Semantic predicates that aren't & hoisting

[David Jung]

John D. Mitchell said:
>>>>>> "David" == David Jung <jungdl at ornl.gov> writes:
>>>>>>> John D. Mitchell said:
>>>>>>>> "David" == David Jung <jungdl at ornl.gov> writes:
> [...]
>
[...]
>> expr: ruleA | 'if' expr 'then' expr | ...  ruleA: ruleB ( ('+'|'-') expr
>> )?  ruleB ...  ...  ruleZ : exprList | number | ...  exprList: : '{' (
>> exprListOrStmt )* '}' ; exprListOrStmt : ('{')=>exprList | expr ';' ;
>
> Note that since you called it an exprList, I've presumed that the value of
> an exprList is the value of the last expression (that's pretty
> standard). In that case, e.g., 5 + {a(); b + g()} does actually make
> sense.
yes. That is the intention.  A program in an expr, so are namespaces,
classes etc. etc.

[...]
>> Secondly, and importantly, expr won't match:
>
>> "{if {a>0} then {f();g();} x();}", will it? (or am I going blind?)
>
> Of course it will:
>
> expr will match exprList.
>
> exprList will match expr will match if followed by an expr matching an
> exprList followed by then followed by an expr matching an exprList
> containing two exprs matching a list of function call expressions;
> followed
> by a function call expression.
>

I still don't get it.  It looks like your exprListOrStmt *requires*
a ';' to follow an expr.  So, if the above entire expression is
an exprList containing two exprs (first is 'if'... and second is x();),
why isn't a ';' required to follow the 'if' expr?


>
>> This is what I'm trying to solve. (note the absence of the ';' before
>> the
>> x. "{if {a>0} then {f();g();}; x();}" should be invalid syntax).
>
> That's exactly what my fragment supports.  As noted, it forbids the semi
> colon after the exprList (unless, of course, you allow empty statements
> :-).

That fragment doesn't contain a ';' after an exprList.  The ';'
before the x(); belongs to the 'if' expr, not the sub exprList following
the 'then'.

[...]
> Indeed, and now you can see why such a distinction is useful. :-)
Yes.  I may have to go that route after all, but I don't want
to cripple the language just to make writing the parser easier.

Cheers,
-David.