Hi Eli,
Why? Aren't they lovely, these conflicts?
OK, let's be serious. When looking at the conflict message, we see that
an _expression_ can be reduced to nothing. This is exhibited by
SableCC3's automatic inlining.
To find the source of the empty _expression_ alternative, it is useful to
look at the post-inlining grammar that SableCC3 outputs to the screen,
just before issuing the conflict message. In the current case, we get
the following:
[...]
_expression_
{-> P._expression_ } =
[...]
{others$call$11}
{-> New _expression_.others (New exp1.call (New function_call_expression ( ) ) ) } |
[...]
Now, that's interesting. SableCC3 transformed your grammar (by
inlining) and created the empty "other#call$11" alternative. This helps
our investigation a lot. We now know that the problem is due to the
original "others" alternative, and to the "call" alternative within it,
then to an anonymous alternative within it.
Here's the relevant pieces of the original (pre-inlining) grammar:
_expression_ =
[...]
{others} exp1;
exp1 =
[...]
{call} function_call_expression |
[...]
function_call_expression = |
{identifier} [function]:qualified_identifier lparen [arguments]:expression_list? rparen |
{parens} [function]:parenthetical_expression lparen [arguments]:expression_list? rparen;
Ouch! This one is difficult to see! Where's the anonymous alternative?
We easily see 2 named ones: "identifier" and "parens". Yet... There's
also an empty anonymous alternative. Look carefully:
function_call_expression = |
Yes, there's a spurious alternative operator "|" after the "=". That's
the (unwanted) empty alternative!
I had trouble seeing it, too. :)
Have fun!
Etienne
--
Etienne M. Gagnon, Ph.D.
SableCC: http://sablecc.org