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

[Duane Rettig]

Kenny Tilton <ktilton at nyc.rr.com> writes:

> Peter Seibel wrote:
> > Joachim Durchholz <joachim.durchholz at web.de> writes:
> >
> 
> >>Peter Seibel wrote:
> >>
> >>
> >>>Joachim Durchholz <joachim.durchholz at web.de> 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).

Well, yes, but not for another release or so - I've got to get
environments access working right first (where do you think all
of this info and capability will be coming from? :-)

It is indeed true that macros tend to be opaque, and experience
with the best of C/C++ debuggers and those of other lanuages with
macro systems will simply reinforce this fact.  However, Common Lisp
macros tend not to be opaque (it is one of the more useful parts of
the fact that CL macros work on the same data that programs work on),
and one can see what a macro doing by simply macroexpanding it - for
example, try (pprint (macroexpand '(dotimes (i 10) (print i)))) in
a CL listener.  With this much openness, it doesn't seem unreasonable
to expect a debugger to be able to use such information to make macros
and the forms they expand into completely debuggable and steppable at
any desired level.

-- 
Duane Rettig    duane at franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182