[antlr-interest] tree rewrite ambiguous enclosing rule/referenced in production

[Tim Williams]

On Thu, Aug 13, 2009 at 8:34 AM, Gavin Lambert<antlr at mirality.co.nz> wrote:
> At 13:45 13/08/2009, Tim Williams wrote:
>>For the scopedClause rule below, I'm getting this error(132):
>>"$scopedClause is ambiguous; rule scopedClause is enclosing rule
>>and referenced in the production (assuming enclosing rule)"
> [...]
>>scopedClause:
>>       LPAREN (scopedClause->scopedClause) ((OR_TOKEN s2=scopedClause)
>>->
>>^(OR $scopedClause $s2))+ RPAREN
>>    | LPAREN (scopedClause->scopedClause) ((AND_TOKEN
>>s2=scopedClause)
>>-> ^(AND $scopedClause $s2))+ RPAREN
>>    | LPAREN (scopedClause->scopedClause) ((NOT_TOKEN
>>s2=scopedClause)
>>-> ^(NOT $scopedClause $s2))+ RPAREN
>>       | searchClause
>>               -> searchClause
>>       ;
>
> I think the warning will go away if you explicitly label the first path --
> ie. replace all of your (scopedClause->scopedClause) fragments with
> (s1=scopedClause->$s1).  (Using $scopedClause in the second rewrite is
> correct though, and should be left like that.)

Unfortunately the error does not go away.  Is there a way to
explicitly reference the outer/parent/whatever-its-called clause?

> You could, however, improve performance by first left factoring it:
>
> scopedClause
>  :  LPAREN (s1=scopedClause -> $s1)
>     (  OR_TOKEN s2=scopedClause -> ^(OR $scopedClause $s2)
>     |  AND_TOKEN s2=scopedClause -> ^(AND $scopedClause $s2)
>     |  NOT_TOKEN s2=scopedClause -> ^(NOT $scopedClause $s2)
>     )+ RPAREN
>  |  searchClause -> searchClause
>  ;

I don't think that's a 1-to-1 refactoring.  I'm wanting to require
parens around heterogeneous clauses but not around homogeneous clauses
(e.g.
(cat or dog or mouse) => is ok
(cat or dog and mouse) => parse error

essentially forcing a user into explicit precedence.  My quick tests
leads me to think this isn't exactly the same as what I had?

> (Although that begs the question: is NOT really a binary operator in your
> language?

Well, it's a good question, the language[1] I'm trying to implement
does treat it as a binary operator.

> And is 'LPAREN searchClause RPAREN' supposed to be illegal?
>  Because as it stands, both are the case.)

Yeah, I think that's a result of the "forced outer parens" problem
I've got.  I want to achieve what described above but haven't figured
out a way to do it yet that doesn't require parens on the outermost
statement.  I'm living with it for now, trying to crawl, walk, run...

Thanks,
--tim

[1] - http://www.loc.gov/standards/sru/specs/cql.html#bnf