"Things unique to the Arcueid implementation such as the marshalling mechanism (CIEL), the Limbo-inspired thread communication and synchronisation primitives, and so forth, must all go into their own modules to limit pollution of the global namespace with incompatible symbols as far as possible."
One of the first things I did in Arc was making a namespace system so I could pile on additional libraries (Lathe) without regret. :)
In my Lathe namespace system, I used prefix-like macros to rename variables into gensyms:
my.foo --> gs123-foo
my!foo --> 'gs123-foo
(my:foo:my:bar a b c) --> (gs123-foo (gs123-bar a b c))
Nothing but a global variable can expand as a macro in (typical) Arc, so these gensyms are the way I avoided conflict in the global namespace.
The approach currently present in Lathe has a few disadvantages as a "standard" module system for Arc:
- It's still a bit unhygienic since the prefix-like macros themselves (e.g. 'my) are kept as unmanaged global variables. I've often considered going back and standardizing on just two prefixes: my.foo and yr.foo.
- There are several features I built into the module system at the start and then never used. For instance, if you want to, you can remove a module from the module cache so that it's reloaded the next time someone requires it. If I went back to this system to start from scratch, I wouldn't bother with these features.
- I was never quite satisfied with a way to manage global tables like 'setter or uses of 'extend. In fact, I'm still pursuing a solution to these issues, but it's taking me far outside what's easy to do from within Arc (or any other language I know of).
"I was never quite satisfied with a way to manage global tables like 'setter or uses of 'extend. In fact, I'm still pursuing a solution to these issues, but it's taking me far outside what's easy to do from within Arc (or any other language I know of)."
For what it's worth, Nulan also has that problem with the "syntax-rules" object. The way I decided to solve it is to provide a macro called "w/dict!":
(var foo (obj a 1 b 2))
(w/dict! foo
(= foo!c 5))
foo!c -> nil
Basically, any changes made to the object inside the w/dict! are not seen outside the w/dict!
So in Nulan, if a file creates some new syntax, and you want to load the file but not the syntax, you can use `w/dict! syntax-rules ...`
But, knowing you, you probably meant having these kind of object dependencies automatically detected. I don't have any good ideas for that, sorry.
