If you use the builders for SDF3 to convert an SDF2 grammar to SDF3, and that SDF2 grammar uses alternatives, new sorts are generated for those alternatives in the SDF3 grammar. For example, take this line from the java-front package:

    (Anno | ClassMod)* "class" Id TypeParams? Super? Interfaces? -> ClassDecHead {cons("ClassDecHead")}

What gets generated is:

  ClassDecHead.ClassDecHead = Alt1* "class" Id TypeParams? Super? Interfaces? 
  Alt1 = Anno 
  Alt1 = ClassMod 

Which would be fine, but in every file with alternatives, the counter for the number after Alt is reset. So the new SDF3 grammar has all these overlapping Alt1 (and sometimes Alt2) sorts in different files that shouldn’t overlap.

(I converted the grammar to SDF3 to get the generated AST checking strategies)

Submitted by Jeff Smits on 25 June 2015 at 23:36

You mean when converting it by applying the builder on the .def file, right? Because if you do it manually on each file, I don’t know how to fix it. It would have to be some sort of global counter, but then you would get a different sort every time you apply the builder, even for the same file. I am fixing it for the .def file, so you get a different sort even for different modules, but in the same transformation.

I called the builder manually on each file. I understand that that behaviour is hard to fix, but it is a stumbling block. This is where you start to feel the pain of not having proper scoping in SDF :(
If you can’t fix it nicely (e.g. use a path-based unique name for these new sorts?), maybe you can print a warning in the console when a builder is called on an SDF2 with alternatives.

Oh! You could name them using the sorts of the alternative! Like:

    (Anno | ClassMod)* "class" Id TypeParams? Super? Interfaces? -> ClassDecHead {cons("ClassDecHead")}

⇒

  ClassDecHead.ClassDecHead = AnnoOrClassMod* "class" Id TypeParams? Super? Interfaces? 
  AnnoOrClassMod = Anno 
  AnnoOrClassMod = ClassMod 

Whenever such a name would overlap, it would have been produced from exactly the same alternative pattern anyway :)

Of course if the old grammar already defined such a sort, or has sorts with Or in it, you may be generating new conflicting sort names. But that’s always going to be a potential issue when you generate new names to a language without scoping.