Description

The following grammar

module dummy

imports
  Common

context-free start-symbols
  Expr

context-free syntax
  Literal.PosInf = [INF]
  Literal.NegInf = [-INF]
  
  Expr = Literal {prefer}
  Expr.UMin = [-[Expr]]
  Expr.Eq = [[Expr] == [Expr]]
  
context-free priorities
  Expr.UMin
> Expr.Eq
> Literal.PosInf

unambiguously parses these strings:

1. --INF
2. -INF == -INF

But the following grammar

module dummy

imports
  Common

context-free start-symbols
  Expr

context-free syntax
  Literal.PosInf = [INF]
  Literal.NegInf = [-INF]
  
  Expr = Literal {prefer}
  Expr.UMin = [-[Expr]]
  Expr.Eq = [[Expr] == [Expr]]
  
  Expr = Call
  Call.FuncCall = [[Expr].[ID]([{Expr ", "}*])]
  
context-free priorities
  Call.FuncCall <0>
> Expr.UMin
> Expr.Eq
> Literal.PosInf

parses -INF == -INF ambiguously. Note that by removing Call.FuncCall <0> from the priority chain, the parse is no longer ambiguous.

Current Workaround

The current workaround is to lift Literal.PosInf and Literal.NegInf into Expr:

module dummy

imports
  Common

context-free start-symbols
  Expr

context-free syntax
  Expr.PosInf = [INF]
  Expr.NegInf = [-INF]
  
  Expr.UMin = [-[Expr]]
  Expr.Eq = [[Expr] == [Expr]]
  
  Expr = Call
  Call.FuncCall = [[Expr].[ID]([{Expr ", "}*])]
  
context-free priorities
  Call.FuncCall <0>
> Expr.UMin
> Expr.Eq
> Expr.PosInf

Affected Versions

Spoofax 2.1.0 & 2.2.0

Submitted by Martijn on 2 May 2017 at 18:34

Hey Martijn,
I assume you’re using the new parse table generator. If so, first of all, you shouldn’t need the indexed priority (unless you are using it for tree filtering).
It is probably in the grammar because you do not want to filter out the inner expressions of FuncCall, which would happen using the SDF2 semantics for disambiguation, but that should be fixed by the new SDF3 table generator.
I tested your example with the latest version of the generator (the one I have locally) and I could not reproduce the problem.
The thing is, when the latest Spoofax was released, I was in the middle of writing the paper about the new generator, so I have done quite some changes/improvements/fixes to it that might already cover the issues you are finding.
I will try to workout with Gabriël if we can release a minor version or something, so we can have a more stable version of the generator in the latest Spoofax.
As I asked you privately, I do not know if it is possible, but if you could send me the Green-Marl grammar with the syntax tests you have, I can have a look and see if I find the same problems you are finding.

Eduardo, you should be able to access the GM syntax definition, since it’s in the front-end repository:
https://bitbucket.org/slde/greenmarl/src/a46aa86239c7a00ab936060d9ecacf323ba9cdf7/gm_lang/syntax/?at=master
I’m not sure where the syntax tests live. The repository contains all the older GM projects as well, so it’s a bit difficult to find the things that are actively worked on and used.

I was using the old parse table generator, but with the new parse table generator (the released version) the issue still exists. This is one of the fixes in your local version then.

first of all, you shouldn’t need the indexed priority

Good to know (though this does not solve the issue in the released version).

I will try to workout with Gabriël if we can release a minor version or something, so we can have a more stable version of the generator in the latest Spoofax.

That would be great! If it’s not possible, then we’ll just have to wait until 2.3.0. Oracle needs to get approval because of the new dependencies, so this will take some time anyway.

if you could send me the Green-Marl grammar with the syntax tests you have, I can have a look and see if I find the same problems you are finding.

What Jeff said. My changes are in the feature/mdwars_parse branch. This contains the migration to Spoofax 2.2, fixes for the ambiguities, and a couple of tests (see GM-test/parsing/disambiguation) that fail on Spoofax 2.2.0.

[removed]