Hi Eli,
The conflict I get, using your grammar and SableCC 3, is slightly
different. I get:
shift/reduce conflict in state [stack: TModule TUnqualifiedIdentifier TDefine
TUnqualifiedIdentifier TColon PLowerTypeForm TFirstclassFunctionArrow
PLowerTypeForm *] on TLsbracket in {
[ PFirstclassFunctionForm = PLowerTypeForm TFirstclassFunctionArrow
PLowerTypeForm * ] followed by TLsbracket (reduce),
[ PLowerTypeForm = PLowerTypeForm * TLsbracket TIntegerConstant
TRsbracket ] (shift),
[ PLowerTypeForm = PLowerTypeForm * TLsbracket TRsbracket ] (shift)
}
I will need the (upcoming) SableCC 4 LR engine to help debug this one.
Unfortunately, the stack reported by SableCC 3 does not help identifying
the context of the firstclass_function_form reduction.
Note that there is necessarily a local ambiguity given a 1 token
lookahead (i.e. an LR(1) conflict). The LALR compression loses some
context information but does create new shift/reduce conflicts. So,
there is some context where a firstclass_function_form can be followed
by a '['. We just can't seem to find it...
Etienne
On 2011-07-16 14:43, Eli Gottlieb wrote:
I say that it's funky because (as sometimes happens), I can't actually
spot where one of the alternatives is legal.
[exec] shift/reduce conflict in state [stack: TModule
TUnqualifiedIdentifier TDefine TUnqualifiedIdentifier TColon
PLowerTypeForm *] on TLsbracket in {
[exec] [ PLowerTypeForm = PLowerTypeForm * TLsbracket
TIntegerConstant TRsbracket ] (shift),
[exec] [ PLowerTypeForm = PLowerTypeForm * TLsbracket
TRsbracket ] (shift),
[exec] [ PTypeForm = PLowerTypeForm * ] followed by
TLsbracket (reduce)
[exec] }
As far as I can tell throughout my grammar, a type_form followed by a
'[' token simply should not be legal. A lower_type_form followed by a
'[' token should *always* indicate the {array} case.
--
Etienne M. Gagnon, Ph.D.
SableCC:http://sablecc.org
_______________________________________________
SableCC-Discussion mailing list
[email protected]
http://lists.sablecc.org/listinfo/sablecc-discussion
