I have actually read a lot about hygienic vs non-hygienic macros. I just cannot recall what blogs and sites I read them.
You might try smuglispweeny and lambda-the-ultimate blogs, though. And wikipedia.
The thing is, gensyms handles some of the stuff hygienic macros handle, but not all of the stuff. There are some complex cases which would require heroic efforts in LISP, and very prone to errors at that.
On the other hand, hygienic macros can access the runtime context, in a more verbose way.
So, really, they each can be used for the same things, with varied levels of complexity depending on the task. But let me advocate hygienic macros a bit here.
There once was a language called Forth. Forth was interesting in that not only it was written in itself, but all the internals were available to any programs written in it, and, furthermore, it could be changed at will. You could change the parser, for instance, or you could change how it performed compilation.
Needless to say, it was powerful in the way such languages are. The thing is… Forth lacked abstraction. Yes, you could change the compiler. But, of course, you’d have to know how the specific compiler you were changing worked—and I don’t mean simply dialect differences. The most famous Forth generated indirectly threaded code, quite a few generated directly threaded code, some generated subrouting threaded code, others generated bytecode, and others compiled directly to machine code.
So it was very powerful stuff, which had very little portability. Well, let’s be honest. It had no portability at all.
And here is the thing with non-hygienic macros… the programmers using someone’s macro also have to know how that macro works. Either that, or you add stuff to your macro until it is, effectively, hygienic.
So, by using hygienic macros, you guarantee a level of portability to them similar to library functions.
