Actually on closer examination I'm going to leave the w/stdouts in the op definitions. It's reasonable to have ops take a stream argument, and if they do they have to handle it correctly.
If it's for debugging, wouldn't it be easier if you just left it going to standard out? That way you could run it on the repl and see the output, and still wrap it in 'tostring or w/outfile if you wanted it to go to a string or file instead.
Maybe the stream argument could be made optional, and default do stdout? The redundancy would still exist, but it would allow us to use it both ways.
Macros are something that happens at compile time, not runtime. A macro call looks like a function call, but it's really something completely different.
This... isn't really an explanation. Lexical bindings of things are also determined at compile time - just not the values they'll be bound to. So you can't have a locally-bound macro, but you can let locally-bound symbols shadow macros, and there's no real reason not to.
(If that first sentence doesn't seem to make any sense to other readers: What variable or relative stack position a variable will be stored in in C is determined at compile time, but the value is not. Obviously the backend isn't the same here, but the same concept holds, at least the way arc is currently implemented; in particular, there is a parameter to 'ac that indicates what symbols are lexically and locally bound. In Python, on the other hand, the local environment is accessible at runtime, so lexical bindings are not always determinable at byte-compilation-time.)
