In WebDSL I sometimes have two different syntaxes or sorts for the same constructor.

ForExp.ForExp = <[<Exp> for (<ID> : <Type> in <Exp>)]>
ForExp.ForExp = <[<Exp> | <ID> : <Type> in <Exp>]>

AjaxStatement.AjaxReplace = [replace([ID], [TemplateCall])] {prefer}
AjaxStatement.AjaxReplace = [replace([Exp], [TemplateCall])]

This was fine in SDF2. In the new SDF3 this gives an error:

Duplicated definition for constructor ForExp

but parsing still works as expected, and pretty-printing simply takes the first definition.

I think it saves some desugaring and makes the AST cleaner if this is allowed.

Submitted by D. Pelsmaeker on 22 July 2014 at 12:17

On 22 July 2014 at 14:35 Danny Groenewegen commented:

I prefer the SDF3 duplicate check. That way your parser and pretty printer can be tested in a round-trip, because there are no implicit conversions from one syntactic variant to another.

On a side note, you can drop the first ForExp option for WebDSL.


On 22 July 2014 at 14:42 D. Pelsmaeker commented:

Perhaps the duplicate check should then be a warning? As in: you won’t be able to round-trip test the compiler, but it isn’t really an error as nothing breaks.


On 22 July 2014 at 15:53 Danny Groenewegen commented:

If you expect the pretty printer to produce the same program text from the parsed AST, then it actually is an error if it just takes the first definition. Besides, the desugarings are trivial in Stratego code. I also consider the overloaded AjaxReplace constructor a bad style, because unique constructor names are the best way to find related rules and strategies in a large Stratego project like WebDSL.

Log in to post comments