Struggling to resolve shift/reduce conflict

[Tom Dodd]

Hello all,

I've been using SableCC for about nine months now - I'm really enjoying it! However, I've come across a shift/reduce conflict that I can not work out how to fix, and I can't see an easy solution if it exists. Usually I've fixed these issues through reasoning about how SableCC is trying to work, but this time I'm not able to see it.

Here is the syntax specification. For some context, it is a language currently similar to C, with a few differences here and there.

The error reported by SableCC is:

shift/reduce conflict in state [stack: PSetup TLPar TAddressOf *] on TName in {

[ P$AddressOf = TAddressOf * ] followed by TName (reduce),

[ PVariableName = * TName ] (shift)

}

I don't understand where the ambiguity comes from - inside the "setup" production, the only place an "address_of" token can appear is in "expression6{address_of}".

Regards,
Tom

[Etienne Gagnon]

Hi Tom,

The problem is due to a conflict between the "type" and "expression6" productions:

type =
		{basic} address_of* type_name |
		{function} address_of* l_par type r_par par_parameter_list;
expression6 =
		{prioritized} expression7 |
		{unary} unary_op expression6 |
		{dereference} dereference expression6 |
		{address_of} address_of variable_name;

I suggest to replace, in both alternatives of the "type" production, "*" by "?" if your objective was simply to make the "address_of" token optional as type prefix.

I am puzzled by the syntax of the "function" alternative of the "type" production. Its use of parentheses around the type will surely cause other conflicts.

Have fun!

Etienne

Etienne Gagnon, Ph.D.
https://sablecc.org

--
You received this message because you are subscribed to the Google Groups "SableCC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sablecc+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sablecc/d9f3fba4-5850-4177-85ea-25da0353ff31n%40googlegroups.com.

[Etienne Gagnon]

Hi Tom,

Effectively, after replacing "*" with "?" in both alternatives, new conflicts caused by the function alternative are detected. See the attached modified grammar.

Have fun!

Etienne

Etienne Gagnon, Ph.D.
https://sablecc.org

[Tom Dodd]

Dear Etienne,

Thanks for the help. You were absolutely correct that parentheses around the type was the issue; it was my first attempt at trying to have a syntax for a function type that didn't conflict with the syntax for a function call. I ultimately introduced a new keyword 'fn' to both the function type and function declaration syntax, and things now work nicely again :)

I just have a quick unrelated follow-up question, if that's okay: does the SableCC lexer expect any particular file encoding? I'm trying to look around the source of Lexer, PushbackReader and FileReader for some hints, but I'm still not sure.

Regards,
Tom

[Etienne Gagnon]

Hi Tom,

File encoding is handled by Java's FileReader class. Since Java version 11, this class has a specific constructor to specify the desired encoding:

public FileReader​(String fileName, Charset charset)

Have fun!

Etienne

Etienne Gagnon, Ph.D.
https://sablecc.org

To view this discussion on the web visit https://groups.google.com/d/msgid/sablecc/1761f5ac-36a6-4020-97bf-4f028aac54e0n%40googlegroups.com.