It appears that Spoofax (1.4.1) supports direct mutual dependence between SDF3 modules, but not indirect dependence (in contrast to SDF2). For example, consider:

module AM
  imports BM
  context-free syntax
    A.A = "a" B

module BM
  imports AM
  context-free syntax
    B.B = "b" A

The direct inter-module sort references above resolve OK. But if the imports are moved to a module CM imported by AM and BM, the sort references in AM and BM no longer resolve:

module CM
  imports AM BM

The build reports:

call-onsave:
        [java] Calling on-save handler for: /Users/pdm/Workspaces/CBS-1.4.1/New/syntax/AM.sdf3
        [java] generating for CM.sdf3
        [java] generating for Common.sdf3
        [java] generating for New.sdf3
        [java] generating for AM.sdf3
        [java] Signature files could not be generated. Try Reset and Reanalyze or check for unresolved references.
        [java] rewriting failed, trace:
        [java] 	editor_save_0_0
        [java] 	generate_all_0_0
        [java] Calling on-save handler for: /Users/pdm/Workspaces/CBS-1.4.1/New/syntax/BM.sdf3
        [java] generating for BM.sdf3
        [java] Signature files could not be generated. Try Reset and Reanalyze or check for unresolved references.
        [java] rewriting failed, trace:
        [java] 	editor_save_0_0
        [java] 	generate_all_0_0
        [java] Calling on-save handler for: /Users/pdm/Workspaces/CBS-1.4.1/New/syntax/CM.sdf3
        [java] Calling on-save handler for: /Users/pdm/Workspaces/CBS-1.4.1/New/syntax/Common.sdf3

Reset and reanalyze doesn’t help. In this simple test project, the build completed OK, but I have a more complicated project (involving generated SDF3) that won’t build unless I add direct imports.

This limitation on indirect cyclic imports isn’t mentioned in the current online SDF3 documentation and the only reference to it that I’ve found is in an assignment: “For a successfull build, it is important to avoid any cyclic import in your syntax definition” :)

Submitted by Peter Mosses on 6 October 2015 at 13:25

I think I understood the issue but I don’t see a way to fix it.

Module AM without imports BM would contain an error as it cannot find the definition for the sort B (therefore it would fail to build at some point). Even though, B was imported by CM through imports BM.
In SDF2 it works because every module is put into a definition file that contains everything, then the definition of B can be found somewhere in this definition file.

I think it’s the same in Stratego. You would get an error in the editor if a strategy is not defined directly in one of your imported files, but if you build, the “feature” of concatenating all imported files when compiling would still make it work.

However, as SDF3 signature generation needs to have these local dependencies fixed (as in, you should import or define what you use) your project will fail to build.

Let me know if my explanation is clear enough, though.

Peter: is the problem solved if you import CM in AM and BM?

Eelco: I was indeed importing CM in both AM and BM, e.g.:

module AM
imports CM
context-free syntax
  A.A = "a" B

and that gave rise to the build failure.

Eduardo: Thanks for the explanations. Regarding “you should import or define what you use’”, the question is whether “import” is supposed to be transitive or not. In SDF2 it was; in SDF3, it seems it isn’t. Perhaps that was a deliberate design decision in SDF3?

Regarding signature generation, I tried manually constructing the expected SDF2 and signature files AM-sig.str:

module src-gen/signatures/AM-sig

imports
  src-gen/signatures/CM-sig


signature
  constructors
    A : B -> A

BM-sig.str similarly, and CM-sig.str:

module src-gen/signatures/CM-sig

imports
  src-gen/signatures/AM-sig
  src-gen/signatures/BM-sig


signature

The project then built OK (without overwriting the above files) and the only unresolved references in src-gen are in pp. So it seems signatures with cyclic indirect imports are OK, and could be generated straightforwardly from SDF3 if the reference resolution allowed it?

@Peter: I got it, and I found the issue. Well, if we want to preserve the behavior we had in SDF2 then I think we should allow transitive imports.
It was indeed missing in the NaBL rules for SDF3.

Transitive imports with cycles can cause huge performance hits, beware.