I have the SDF file below (whose parts are copied from WebDSL’s syntax). Of the four Annotation productions, the signatures of two don’t show up in include/myproject.str when compiled: IdErrorAnno and IdEmptyErrorAnno. The other two, SimpleAnno and InverseAnno do show up.

module myproject
imports Common
exports
    context-free start-symbols Start
    context-free syntax
        "globals" "{" Property* "}"                        -> Definition {prefer,cons("GlobalsDefinition")}
        Definition -> Start
exports
    sorts Property Annotation
    context-free syntax
        Id "(" {Annotation ","}* ")" -> Property {cons("Property")}

    context-free syntax

        "iderror" "=" String         -> Annotation {cons("IdErrorAnno")}
        "idemptyerror" "=" String    -> Annotation {cons("IdEmptyErrorAnno")}
        Id                           -> Annotation {cons("SimpleAnno")}
        "inverse" "=" Id "." Id      -> Annotation {cons("InverseAnno")}

Here is the resulting include/myproject.str file. Note that IdErrorAnno and IdEmptyErrorAnno are missing:

module myproject

signature
  constructors
    InverseAnno       : Id * Id -> Annotation
    SimpleAnno        : Id -> Annotation
    Property          : Id * List(Annotation) -> Property
                      : Definition -> Start
    GlobalsDefinition : List(Property) -> Definition
                      : String -> Id
                      
signature
  constructors
    Some : a -> Option(a)
    None : Option(a)
    
signature
  constructors
    Cons : a * List(a) -> List(a)
    Nil  : List(a)
    Conc : List(a) * List(a) -> List(a)

This causes errors like the following when writing NaBL, TS rules or desugaring transformation for it.

[java] [ Main | error ] in rule nabl-constraint(0|1): constructor IdEmptyErrorAnno/1 not declared
[java]     IdEmptyErrorAnno(exp)

I’ve attached a minimal project that demonstrates the issue. This is on Spoofax 1.2.0.0-s41731.

Submitted by D. Pelsmaeker on 25 June 2014 at 15:46

This might be caused by a missing definition of String. Can you confirm this?

It might be. There is no constructor definition of String. This is a snippet of what’s in Common.sdf of the attached project (and in WebDSL-Lexical.sdf of the original project):

  %% Kernel syntax is required here since we do not want LAYOUT to be parsed between
  %% the first QMLex and StringLex
  syntax
    <QMLex-LEX> <StringLex-LEX> <QMLex-LEX>  -> <String-CF>  {ast("String(<2>)")}

  lexical syntax
      "\""                         -> QMLex
    StringChar*                  -> StringLex
    ~[\"\n]                      -> StringChar
    "\\\""                       -> StringChar

Signatures are generated taking into consideration reachable sorts.
In this case, as the sort String was not defined, the productions that use it do not generate signatures for their constructors.

Ok, this is a bit more complicated. There is a sort String defined in the kernel syntax, but it does not define a constructor for it, but an AST pattern. When the signature is generated, this leads to a missing entry for the sort String. As a consequence, all constructors which rely on this sort are dropped, since they are considered unreachable.

In general, the stripping is a common source of confusion. Eduardo’s signature generation for the new SDF3 does not strip unreachable constructors. Though, your case is special, since the ast pattern is the actual cause of the problem.

Yes, I have this same issue with the definition of Function:

"function" Id "(" {FormalArg ","}* ")" FunctionReturn Block -> Function {cons("Function")}
                                                            -> FunctionReturn {ast("SimpleSort(\"Void\")")}
":" Sort                                                    -> FunctionReturn {ast("<1>")}

Now I see it’s the same problem: FunctionReturn in this case is not defined with a constructor, but using an AST pattern. Because I copied the syntax files verbatim from the WebDSL project, I’d rather not change the syntax.

Also, Spoofax should display an error when it can’t find a definition for a term, not ignore it.

@Daniel: Well, we should discuss this. The given grammar fragment gives all kind of troubles when it comes to pretty-printing.

@Eduardo: You should discuss ast support with Eelco. It is a nice feature, but I assume you need to restrict it somehow to avoid trouble with pretty-printing.