I'd like to point out that this problem happens even when you don't redefine primitives or core functions. I read somewhere (maybe even one of PG's books, can't remember) that this is one of the reasons why Common Lisp is a LISP-2: because of unhygienic macros.
This is especially relevant when you use many libraries: it's not possible to remember all of their exported symbols and sooner or later you are going to shadow one of them. It only takes one macro call, then, to trigger a possibly very tricky bug.
This is made even worse by Arc's special syntax: if a variable contains a string or a hash instead of a unary function, this won't be detected until much later. So this problem seem to be more relevant to larger programs.
Is there a more elegant workaround? Does the devteam has something in mind?
I agree. macro transformers would need to refer to the lexical context in which they were defined. strangely, a number of threads in this forum seem to indicate substantial resistance against implementing Arc macros any way other than as simple list manipulations. now granted that 1) straightforward list transformations are easy to understand, 2) there are limitations with _some_ macro systems that provide for lexical references to identifiers in the definition context, 3) inadvertently shadowing identifiers appearing in macroexpansions is unlikely in _other_ Lisps thanks to multiple namespaces, package systems and restrictions on shadowing certain identifiers, and 4) it is a lot more difficult to correctly implement a macro system that solves this problem. however, let's all agree that a hypothetical macro system that _could_ solve this problem would be vastly preferable. arguing against this on the grounds that accidentally shadowing identifiers is a problem you're willing to deal with manually (in a single-namespace Lisp with no module system and no shadowing restrictions) is analogous to arguing in favor of dynamic scoping over lexical scoping as a sensible default.
