Separate Compilation

The expected advantage of separate compilation is increased compilation speed. This is especially desirable for the StrategoLibrary^?, 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.

Pragmatics

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