I feel like having an implicit variable for the namespace is a bit of a low-level approach, since the core Racket namespace tools default to the dynamic (current-namespace) already. That's also an intuitive default for them to have, so I don't see anything wrong with Arc code doing it the same way. Whether or not it's beneficial in an in-the-large way, at least it's concise.
Anyway, how about this for "multiple layers of function calls": If you call 'load, that calls 'eval. Two whole layers! ^_^
---
"I think "namespace" may be too narrow a description since a runtime may have other configuration settings (such as how it handles optimizations) besides just which global variables it has."
I agree. I think "runtime" is a pretty good name for what you're headed for. :)
"I feel like having an implicit variable for the namespace is a bit of a low-level approach, since the core Racket namespace tools default to the dynamic (current-namespace) already."
Yeah, I have nothing against making macros or functions that handle namespaces in other ways, but I'd rather have a simple and concise low-level way too.
---
"I agree. I think "runtime" is a pretty good name for what you're headed for. :)"
Yeah, but I think the word "namespace" makes perfect sense for my library, especially considering that a namespace is a simple mapping between names and values. You can even pass in tables, so I think "namespace" is just fine.
Of course, in ar itself, using "runtime" is also perfectly fine, because ar namespaces might contain things other than a simple mapping, so I don't see a problem with ar using "runtime" and my library using "namespace".
