Pascal Bourguignon <email@example.com> wrote:
| iu2 <firstname.lastname@example.org> writes:
| > Besides, I find the fact that there are no line numbers in the debug
| > information quite annoying, (although the place of the problem can be
| > pin-pointed by the stack trace). Is there a solution for that?
| Not really. The problem is that lisp sources are not text files, they
| are symbolic expressions.
| One could imagine keeping track of an association between a
| line/column and lisp tokens (symbols, literals, conses, etc) making
| the sexps, but since these sexps can be manipulated in any way at read
| time and at macroexpansion time (and some of them even generated from
| thin air then), it would hardly be meaningful anyways.
Actually, the PLT Scheme guys did a pretty good job with their
Zodiac source-correlating reader & macro-expander, used in the
MrSpidey debugger front-end [now merged into DrScheme, IIUIC],
which replaced the normal Scheme reader with a "Scheme DOM reader"
[to coin a phrase] which read s-exprs and annotated each node
with file/line/charpos [and other info]. Then the evaluation
pre-pass did further annotation, e.g., putting in back-links
from lexical variable uses to their binding points, which the
IDE [in DrScheme] could display with cute little arrows.
It would certainly be *possible* for a CL implementation to do
something like that as well, but AFAIK none do. They just use
the normal READ defined in the CLHS.
 Shriram Krishnamurthi, "Zodiac: A Framework for Building
Interactive Programming Tools. Tech. Rep. 95-262, Rice Univ.,
Houston, TX, USA, 1995.
 For some pictures of how this looks in action, see
"PLT MrSpidey: Static Debugger Manual".
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607