Tim Williams wrote:
On Thu, Aug 13, 2009 at 8:34 AM, Gavin Lambert<[email protected]> 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.
Are you sure? NAND?
When rewrites get this convoluted it is usually (but not always) that
the grammar, while perhaps not wrong is in need of a rethink. You
generally don't want to throw out syntax errors if you can throw out
semantic errors later, so try accepting all forms in any combination
and using the standard rewrite forms. Just gather information about OR,
AND and NOT (add them to a lit perhaps or keep
lastOperator=AND_TOKEN/OR_TOKEN/NOT_TOKEN). When the RPAREN is found,
THEN check what you discovered and issue any relevant semantic errors.
You can also issue errors as you get new AND/OR/NOT if it is easier.
You should then be able to rework all this without any of the problems
you are having. Look to produce ANY valid parsable tree, not just the
one currently in your mind too ;-)
Jim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "il-antlr-interest" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
|
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
