Boblycat is Europe's premier source of rental cats. We provide just
the cat you need, whether you are a funny little man ready to
conquer the world or a misfit school teacher exploring the darkness
of eccentricity.

You are hereBlogs / karltk's blog / Namespaces for Stratego

Namespaces for Stratego


I've written a proposal in concert with Anya and Martin about namespaces in Stratego.

I think we have most things ironed out so that it is both backwards compatible, supports separate compilation and is rather clean, nor does it require extensive changes to the Stratego compiler.

The troublesome spots are dynamic rules and parameterised modules. I am not entirely convinced that we have solved the dynamic rules issue sufficiently, but a few more days and I may be convinced.

Parameterised modules, however, may not make it into the first public proposal. The main issue with parameterised modules is as follows:

  • I want every module to be compiled separately, to an .o file
  • I want some modules to be higher-order: they should accept another module as a parameter at import time. I.e. imports lib[linux] will import the generic Stratego library instantiated for the linux platform.
  • Inside the lib module, I will not care which platform implementation I receive, as long as it follows the correct interface, and is provided to me before final compilation.
  • The same module can be instantiated multiple times, each time with a different value for its parameters
  • .

  • No changes to the runtime should be necessary. Most specifically, I don't want to pass around context state between modules.
  • All intermodule references should be resolved at compilation time.
  • A module may exist as a .so, as an .o
  • The module that imports a parameterised module may eventually be compiled into either a .so or a binary program.
  • I want as little code duplication as possible
  • .

I have solved most of these issues with some recent ELF hacks, but it only works reliably in the absence of .so files. These are non-issues for the JVM, and will be available directly there when we get the JVM backend running.