A while back I posted The Obvious Truth, which described a philosophy I hold over reifying language level implementation details in truly General Purpose Languages. While Domain Specific Languages may have no requirement, since they will never be used to implement another programming language (on their own), or really anything, for that matter, beyond their domain.
The language implementation detail of choice I discussed was environments. Well, it turns out there are some languages that take my philosophy a little more seriously than I thought. PLT Scheme does in-fact provide programmer level interfaces for its environments and even its module system. Presumably the compiler or possibly other features use whenever working with program code directly.
For those who have found this problem to be a tricky one to work around, using those nefarious eval hacks, the keyword here is namespace. A common trend in language design is to combine the features of both namespaces and modules, since whenever one is needed the other generally is as well… or at least in the case of namespaces, a module system rarely makes it harder to work with, when the two are unified. Obviously the implementers behind PLT don’t believe agree (or didn’t).
Once you lookup the namespace libraries, all your crazy namespace mutation and inspection features are suddenly cast into view. I’m not sure yet if they will be enough to implement all of the features that I require, but they sure should make one hell of a lot of noise in the process.
For those who are wondering why the hell I’d want to incorporate so many side-effects into what is generally a much more powerful language in its functional style, the parser generator either must generate genuinely new functions and side-effect them into the namespace, or it must produce a static source file, and load/require that as a module.
Ironically, to load it as a module automatically the same interfaces are required. This is because a module cannot realistically be imported into a non-top-level namespace, or more practically it is almost always an error to do so, and there really are workarounds for the one or two times you’ll ever do it.
– Lorenz