With Guido I discussed what the pretty printer should be capable of: it should be able to pretty print starting at any node => thus it should know by constructor name what pretty print rule to choose. This is the reason for the error warning: “Missing Constructor”.

However having constructor names does not satisfy the above requirement, for example:

RHS = NodeLine
RHS = EdgeLine

NodeLine.PpHelp = <<Node>.>
EdgeLine.PpHelp = <<Edge>.>

The pretty printer will now always get in the NodeLine pretty print rule, causing a with failure on EdgeLines.
I suppose duplicate constructor names + arities in general (even in different sorts) cause the problem of not knowing how to pretty print from a certain AST node, causing pretty-print-example to generate with-failures.

I guess these are the same problems I started with in the following snippet

RHS = NodeLine
RHS = EdgeLine

NodeLine = <<Node>.>
EdgeLine = <<Edge>.>

Possible solutions:

• generate PP where clauses instead of with clauses: automatically finds the correct one + allow missing constructor names again, but then the user has to make sure there are no overlapping pp rules causing the pretty printer to work but print wrong stuff
• disallow duplicate constructor names and arity all together, but this might be too restrictive for practical use
• … ?

Submitted by Daco Harkes on 8 December 2014 at 11:57

Possible solutions (continued):

• drop support for pretty printing from something else than the top AST-node, and leave pretty printing from a sub AST to the responsibility of the programmer, this is not preferred
• put the sort name in an annotation on the constructor and use that for distinguishing constructors of the same name and arity in the pretty printer (this would also work for rules without constructors I suppose if one put the annotation on the parent), but adding annotations is also not really preferred

I think this issue has at least two dimensions:

1. Imprecise analysis.

   In your example, there is an overloaded constructor of sort RHS. This is not detected by the analysis. Importing constructors for injections could fix this. It would also help to detect cyclic injections, which might lead to non-terminating pretty-printers.

2. prettyprint-example is handy, but too generic.

   In most cases, it is just handy. But if things go wrong, they go wrong by calling this strategy.

There is a strategy prettyprint-SDF-start-symbols that can be used to pretty print only from start symbols of the grammar.
As Guido said, prettyprint-example is still handy if you want to pretty print from any AST node.

I tried to think about considering injections when generating warnings for duplicate constructors but I didn’t know how to implement it. Maybe I could work together with someone and have this fixed.

So the rationale is: support prettyprint-SDF-start-symbols 100% but don’t support prettyprint-example 100%?

If only prettyprint-SDF-start-symbols is supported then omitted constructors are also fine in some cases:

• If a sort has just a single rule
• If a sort has a single rule w/o constructor, and the pretty printer takes this rule as last (and the children are not the same constructors)
• All omitted constructors are fine iff the pretty printer generated for rules without constructors is generated with where clauses instead of with clauses

@Eduardo: I think I can help you with name binding / static checks for injections with duplicate constructors.

This should be an SDF issue, not a Spoofax issue, I guess.

@Eduardo: The fix would first require imports of constructor names for injection rules. Next, we need to fix the checks. Many cases should be covered by minimal changes to the existing checks, but the initial example in this issue is more complicated. You basically need to check for an injection rule, if the current sort imports any constructor twice from two different sorts. Finally, prettyprint-SDF-start-symbols needs to be fixed, including its name. It will give the same trouble as prettyprint-example for overloaded constructors for different start symbols. There seems to be an implicit constraint, that start symbols cannot overload constructors.

@Daco: prettyprint-example will always have problems with overloaded constructor names, even for completely separated sorts. The fix would be either to forbid constructor overloading completely only for prettyprint-example, or to not support prettyprint-example anymore. Both would be extreme. In the current solution, you can either use prettyprint-example or, if that gives you trouble, define your own prettyprint-my-example by carefully composing strategies for the sorts you are interested in.

(I dont see an sdf project on YellowGrass)

@Guido I’m fine with that.

@Eduardo, let me know if you need help with the checks. (Maybe we can do them with pair-programming when you are back.)