With power comes responsibility. Java sees programmers as irresponsible, so it gives them no power. Arc/Lisp gives us power, including unhygienic macros, and leaves it to us to use them responsibly. /Can/ you contrive an example that breaks things? Yes, but that is no surprise, PG said Arc would do that. What would be more compelling is an example of real-world coding that ran afoul of capture. In CL, btw, I do not think it is the extra namespaces that help us, I think it is that ghastly warning we get when we try to redefine a bit of the language.
Hygiene does not diminish power. Various hygienic macro systems exist that are at least as powerful as defmacro. An extremely simple one is explicit renaming, which allows simple controlled capture. Syntax-case (see R6RS) is strictly more powerful than MAC (in the sense that MAC can be expressed in terms of syntax-case but not vice versa). Explicit renmaing and syntax-case have the power to respect lexical scoping, while no amount of tricks can stop MAC from breaking lexical scoping. Syntax-case also allows controlled capture, indeed much finer control over capture than MAC does. So an argument based on power would in fact favor hygienic macro systems over MAC.
But variable capture is just a hobgoblin to frighten the kiddies, nothing that ever Actually Happens(tm) to those using unhygienic macros in anger. Meanwhile, syntax-case may theoretically be able to express MAC, but the reality is that it is a PITA to program with. The power of syntax-case is theoretical, the power of MAC is in practice. When I have to write some code, I'll take the latter.
I can never be sure that this is correct unless I go and read the definitions of (some-macro-use) and all the macros that it may in turn depend on, to make sure that they do not depend on, say, the standard binding of < and perhaps some toplevel binding of "sequence". And I have to do this for /every/ local variable binding surrounding every macro use in the whole program. Also, I had better be sure that no-one will go and change the definition of some-macro-use, or any of the macros on which it depends, at any time to depend on the toplevel <, a toplevel "sequence", or /any/ other lcoal variable that may surround /any/ use of some-macro-call anywhere in the code.
The fact that you have not run into this problem shows amazing discipline, and may have something to do with CL not being a Lisp-1. I have no such discipline, and prefer having the language take care of lexical scoping for me. But then, I don't plan on using Arc, so feel free to ignore this.
It is not clear that the nightmare outlined above applies to actual programming. I am a little weak on my Lisp-1, but IIUC the above changes < to be whatever comparison operator got passed to sort, so the author of the above sort should be fired for breaking <. As Arc matures it might not hurt for the compiler to issue a warning over such sabotage, which is really what it is so I am not sure why we are discussing it as a Real World Problem.
As for "sequence" and someone depending on some /other/ higher level binding, ie, it is capturing the variable sequence by design, (a) intentional variable capture is as rare as it is powerful and the premise is that one has a suite of cooperating macros that work together to bind and then use the rare variable designated for capture, so one is not invoking one of these macros in isolation unaware of how it works or what it captures. A good example from my code at one time was the binding and capture of SELF, being used in some OO wizardry to stand for the "instance at hand" a la smalltalk. If I was rebinding self outside the cooperating suite of macros (which I did, rarely) it was because I had coded myself into a corner, but I knew damn well what I was doing and why I was doing it and I still crossed my fingers.
btw, a trick the CL crowd uses for lexical vs dynamic binding (the latter being an opportunity for a similar kind of confusion as the one you fear) is simply to name dynamic variables +like-this+. (not really, we use asterisks, but this forum would just show like-this if I bracket it with asterisks.) That simple convention solves the whole problem, as long as we fire anyone naming a scratch variable that way. :)
