Hi,

back in February I had promised:

• Give me time to write that review about *macroexpand-hook

and augment-environment. Now that I said so much about it, I think I owe you all to write it up in detail.

I realize I've now forgotten most of my analysis about why the cltl2 augment-environment is limited and doesn't scale to the large.

The one thing I can remember was one concrete bug in Andreas Fuchs' code, independent on the weakness of the augment-environment design of CLtL2.

Andreas binds *macroexpand-hook* to some handler of his own. Obviously, he does so because he needs the functionality. Correct working of his code depends on this binding. But if his code doesn't recognize an interesting form, he calls #'FUNCALL on the expander.

That's bogus and won't work in the large. Consider another macro package of similar complexity, which also depends on rebinding *macroexpand-hook*. This package will fail mysteriouly because Andreas' code bypasses it. Or consider another Andreas' code expanding another macro that behave as badly: Andreas' handler will never get called, and Iterate will fail somehow.

The only correct way for a handler is, instead of #'funcall, to invoke the previous value of *macroexpand-hook*. It's only such a weak form of "declining" that's available to the handler.

BTW, CLHS says it as well: "Users who put their own function into *macroexpand-hook* should consider saving the previous value of the hook, and calling that value from their own."

So that was the bug, and I'm again sorry I forgot most of my reflection about the limits of the augment-environment and brothers design.

Regards, Jorg Hohle