I think it has to do with tag being a macro. Since arc doesn't have first-class macros [1], the compiler expands macro calls (i.e. instances where defined macro names occur in functional position) before run-time. In your example,
arc> (let tag (obj bb 10) (prn tag!bb))
after the tag!bb ssyntax expands to (tag 'bb), tag is now in functional position, and it will be macroexpanded away before the semantics of let can come into play.
Here were wrote a function which took an argument named 'tag, and yet the interpreter still thinks tag is a macro, when clearly it's not a macro in this scope.
If we were to wipe it first, then it would work as expected:
If this is not a bug, then it's a design flaw. It means you have to be super careful when choosing names for function arguments, specially if you write a function taking a function or hashtable argument.
(let name (some-function-generator)
(name arg1 arg2 arg3))
What if name is defined as a macro by someone, somewhere?
You just defined it as a function, but the interpreter still thinks it's a macro. How can this not be a bug?
> Here were wrote a function which took an argument named 'tag, and yet the interpreter still thinks tag is a macro, when clearly it's not a macro in this scope.
Another way to think about it is that arc does have scope, but it doesn't apply to macros. Macros can only be defined globally (you can't write a local macro), and they're expanded before any of the normal scoping rules come into play.
> What if name is defined as a macro by someone, somewhere?
Yes: it is something you have to worry about and it is arguably kludgy. But again, it's only for macros. If you're overriding globally defined functions or variables of any other type, it works.
> You just defined it as a function, but the interpreter still thinks it's a macro. How can this not be a bug?
It's a thoroughly-discussed design choice that some people don't like. You already linked elsewhere in this thread to aw's proposal of how to change it if you want to give it a try. [1]
