Not sure if using an implicit variable for specifying the namespace is the right choice here... I find implicit variables most useful when there's a single value that needs to passed through multiple layers of function calls. For example, in the Arc web server, I'm only responding to a single request at a time, so I find it useful for the request to be an implicit value.
When I have more than one value that I'm working with at a time, then I find implicit variables often become awkward, and I'd prefer to just specify the value explicitly.
It seems like namespaces may fall into this latter category, since I'll be working with my namespace and the other namespace, and perhaps more than one other namespace.
I could be wrong of course, and there's a good example of when passing the namespace implicitly is simpler than the alternative.
By the way, I've been calling the value holding the global variables and other attributes of a language instance a "runtime", which happens to be implemented with a Racket "namespace". 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. Thus I'd name things "new-runtime", "w/runtime" etc.
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".
"I find implicit variables most useful when there's a single value that needs to passed through multiple layers of function calls."
I'm finding a lot of uses for implicit variables. I've come to like them a lot. :P I'll note that there can only be one namespace active per executing code, so it made a lot of sense for me to use implicit variables.
---
"When I have more than one value that I'm working with at a time, then I find implicit variables often become awkward, and I'd prefer to just specify the value explicitly."
