SDF3-symbolsorts: Duplicated definition for constructor
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
Issue Log
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.
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.
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