Paging Mr. Rettig [ws Re: Explanation of macros; Haskellmacros]
fjh at cs.mu.oz.au
Mon Nov 3 05:13:31 CET 2003
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.
More information about the Python-list