Date: Mon, 17 Mar 2008 20:33:15 +0000 From: "David Rush" kumoyuki@gmail.com
On Fri, Mar 14, 2008 at 1:57 PM, Joel Borggr�n-Franck < joel.borggren.franck@gmail.com> wrote:
"and have discussed why hygienic macro systems rename symbols and that when using namespaces in the symbols, this might be enough as "rename" means, thus providing nice integration with preexisting namespace-using Gambit code."
Well, that's what I'd call a viable engineering solution, but I doubt that it truly solves the problem.
With a suitable definition of `rename' it does.
Macros can capture names even within a single namespace, can't they? However, by reducing the number of symbols in the namespace (since core Scheme has only one), you reduce the probability of capture - assuming that names are randomly distributed in the space of all possible identifiers.
Which of course they're not. But that doesn't mean that ny controlling the boundaries of the problem that it doesn't become easier to write real code. I think that long experience is showing that hygienic macros are great, but they don't really serve as a practical substitute for the ability to break hygiene when necessary. And frankly, good old define-macro is hard to beat for that, no matter how groovy syntax-case appears to everyone.
This is absurd. The ability to break hygiene when necessary is offered by every reasonable programmatic macro system out there, not merely SYNTAX-CASE, yet long experience has shown that this is almost always a mistake; and DEFINE-MACRO is at best an excellent source of insanely obscure bugs that will turn up when you least expect, because a macro's description failed to include a subtle detail about what names it expects not to be rebound. Such obtrusive implementation detail is a necessary part of an unhygienic macro's interface, just like the names of local variables are in a dynamically scoped language; this is a very real problem in engineering large systems.