Yes and yes. But there's supposed to be a clean separation between modules. If you assign to a variable, it assigns it in your module. If you want to assign to a different module, you need to be explicit, like so:
(import foo "foo.arc")
(= foo!bar 'qux)
So in order to assign to the core module, you would need something like built-ins* to access it:
"then I'm interested to know how you're shallowly copying arbitrary environment types. :-p"
Environments are just wrappers around Python's dict type, so I can use the copy() method to make a shallow copy. I might need to make my own custom copy function later, though. Arc tables are just annotated dicts, by the way. But Python lets me modify how classes behave, so for instance I should be able to get cons cells to work in a dict, even though they're mutable (and thus not normally allowed).
"If you want to assign to a different module, you need to be explicit, like so:"
Ah, I don't know why I didn't see that. ^_^
---
"Environments are just wrappers around Python's dict type, so I can use the copy() method to make a shallow copy. I might need to make my own custom copy function later, though."
I was harking back to "What is an environment? Anything that supports get/set on key/value pairs." Would it also need to support a copy function?
Hm... it shouldn't, no. Only global_env is copied, so Arc types wouldn't need to worry about copying. In the hypothetical case that I would need to copy them, I could coerce them into a table and then do a copy on that. This could all be done transparently, so Arc code wouldn't need to do anything.
global_env is treated specially because it's the base for all other modules: it contains the built-in functions that modules cannot create (at least not in Arc), and also the core functions in arc.arc for convenience.
There are other strategies I could use as well, like special-casing (assign) or similar, but I figured a shallow copy would be easiest.
