Paging Mr. Rettig [ws Re: Explanation of macros; Haskell macros]

Kenny Tilton ktilton at
Sun Nov 2 05:40:55 CET 2003

Peter Seibel wrote:
> Joachim Durchholz <joachim.durchholz at> writes:
>>Peter Seibel wrote:
>>>Joachim Durchholz <joachim.durchholz at> writes:
>>and I not just suspect but know that macros have some very serious
>>disadvantages (such as bad debugger interaction, a potential for
>>really ugly hairballs, and a constant temptation for stopgap
>>solutions that "work well enough").
> Well, of those the debugger interaction is perhaps the most serious.
> Yet in practice (Hey Pascal, I almost said "in 99% of cases"!) it
> doesn't seem to be that much of a problem. Maybe that's because we've
> just learned to deal with the pain; maybe MACROEXPAND is all you
> really need to get your bearings. At any rate, there's no in principle
> that a Lisp implementation couldn't keep track of macro information
> along with the compiled code just the way most compiler keep track of
> line number information in order to show you the code as written in
> the debugger. (And if it was really slick to let you step through the
> macro expansion, etc.)

Cue Duane of Franz. He mentioned over lunch at ILC2003 where John 
McCarthy used my laptop for ten minutes that their Allegro Common Lisp 
product was going to exactly that, including the expansion thing. I 
think he also said something about expanding in steps, but I did not 
quite follow. I suppose it is like stepping into a function or not, 
except the question here is whether nested macros get expanded (and you 
then get to step through those).



Why Lisp?

Your Project Here!

More information about the Python-list mailing list