[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:
> [...]
>
>> The whole "{if...}" is an ExprList.  Within that the "if {a>0;} then
>> {f();g();}" can only be an expr, can't it?  (can't be an exprList as it
>> doesn't start with a '{', hence it needs a trailing ';').
>
> Really look at the trace information and see the flow through the grammar.
>
>
>> Here is the output for "{if {a>0;} then {f();g();} x();}" :
>
> Ugh.  Notice how your example input is actually malformed...

My input is not mal-formed with respect to what I want to achieve
(i.e. the original problem I posed), but it is mal-formed
according to the grammar you've proposed.  That is why I
couldn't see how that grammar solves my problem - it doesn't.

>
> {if {a>0;} then {f();g();} x();}

This is what I want for a well-formed input. Actually I'd prefer
"{if {a>0} then {f(); g()} x()}" - but that is the separator/terminator
argument we're ignoring for now.

>
> I.e., your grammar only allows one expression for the then block but
> you're
> trying to put in a sequence of expressions ("{f();g();} x();").

No I'm not.  The expr after then is "{f();g();}".  The "x()" is the
2nd expr in the outer-most exprList.  It may be clearer split into
multiple lines:

{
  if {a>0;} then
    {
      f();
      g();
    }    <--- I don't want to require a ';' here
  x();
}



According to the grammar the "x()" needs to be separated from the
'if' expr by a ';', but I don't
want it to be (as it is redundant - the '}' should be enough to
indicate the separation between an exprList and a following
expr in an exprList)

>
> So, the parser sees the 'x' but it's expecting e.g., the closing RCURLY.

Right - which is why the grammar fails to parse the input it needs to.

Please correct me if I'm still confused, but I think
I see now where we were missing each other's perspective.

Don't suppose you have another idea :))

Thanks for your help.  My problem is clearer in my mind. Alas it
doesn't look like it can be solved with the current versions of ANTLR.
(not without manually hacking the generated parser anyway)

-David.