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

[Fergus Henderson]

prunesquallor at comcast.net writes:

>Duane Rettig <duane at franz.com> writes:
>
>> Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> 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 cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.