Separate Compilation

Stratego -- Strategies for Program Transformation
A pragmatic approach to separate compilation has been introduced in StrategoRelease094. A module can be compiled as a library which results in a single C program containing all definitions of that module and imported modules together with a Stratego module providing the 'signatures' of the strategies in the library. Programs can then import the external definitions instead of the implementation. Concerning the problem of extending definitions (see below): it is illegal to extend external definitions. Thus, strategies imported from a library cannot be extended, which is usually what is desired anyway.

-- EelcoVisser - 24 Dec 2003

The expected advantage of separate compilation is increased compilation speed. This is especially desirable for the Stratego standard library?, which now gets compiled over and over again for every application.

The fundamental problem for a separate compilation scheme is the extensibility of strategy definitions and rules. This can be solved by introducing a notion of a final module, which forbids extension of definitions by importing modules.

A disadvantage is that it is no longer possible to do global optimizations, or that information should still be exported from modules.


A make-like system is needed for finding out whether a compiled module is up to date. This requires dependency analysis and version comparisons between source and compiled objects. The compilation of individual modules can also be delegated to the user, as it is in the case of C programs, but that is not good for usability of the compiler.

When packing collections of modules into (object) libraries, the import system should avoid importing modules twice. This can be solved by first computing the entire import graph before doing any actual imports.

Non Problems

The following problems have been solved in the new ImplementationScheme that was introduced in StrategoRelease06:

  • requires procedure call implementation

  • calling convention for procedures (also needed for ForeignFunctions?)

  • dealing with variable scope

Related issues and ideas

  • FinalDefinitions
  • Header files at Stratego level
  • Encapsulation / hiding
  • Stratego badly needs a module system that is not susceptible to namespace pollution.
  • Namespaces in Stratego + private strategies.
  • Separate compilation and loadable modules.
  • Allow for overriding of rule/strategy

ToDo | CategoryToDo? | CompilerImprovements -- EelcoVisser - 09 Dec 2001

Stratego.SeparateCompilation moved from Stratego.SeparateSompilation on 09 Dec 2001 - 12:40 by EelcoVisser - put it back