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

Fergus Henderson fjh at
Mon Nov 3 05:13:31 CET 2003

prunesquallor at writes:

>Duane Rettig <duane at> writes:
>> Marcin 'Qrczak' Kowalczyk <qrczak at> writes:
>>> On Sun, 02 Nov 2003 02:01:58 -0800, Duane Rettig wrote:
>>> > 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.
>>> Does any debugger do this?
>> Most Lisp debuggers will do this with compiled code.  I know of none which
>> do this to compiled code without recompilation.
>MIT Scheme (which we all know is not Common Lisp) keeps around enough
>debug information to determine the source code being executed at each
>step in the compiled code.  I don't recall if there is a compiled code
>stepper per se, but crawling down the stack in compiled code shows the
>source code that was being evaluated.

Including macros invocations?

When you say "source code", do you really mean source code, or do
you mean the results of macro-expansion?

If I have a function foo whose body invokes a macro bar which calls a
function baz, can I get a "stack trace" or equivalent which shows me the
line in the definition of bar which invokes baz, and the line in the
definition of foo which invokes bar?  Can I see the bindings of the
parameters of bar?

(It would be great if I could, and there's no serious practical obstacle
AFAIK, but I don't know of any debuggers that actually do that.)

Fergus Henderson <fjh at>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <>  |     -- the last words of T. S. Garp.

More information about the Python-list mailing list