MCL 3.0 wishes

[kieras@eecs.umich.edu (kieras)]

I second the opinion of joe@genome.wi.mit.edu :

>MCL 3.0 ... ooh, aah ... I wonder if it has my main wish:
>A debugger comparable to Un*x lisps (for ex. CMU).  At least let's see
>some variable names on those stack frame entries and let's have some way to
>see roughly which line in the source code we have broken in...

Some time ago, I queried about this, and was told that apparently the
break/backtrace facility and the interpreter really don't know about each
other at all.  This seems to be a result of CCL/MCL's original
compile-everything-immediately philosophy, which contrasts to traditional
lisps' philosophy that  everything is interpreted until explicitly
compiled. 

Trying to debug interpretively, standard practice on other lisps since the
beginning, isn't worthwhile in MCL because the backtrace is so
unintelligible that you can't tell which user-coded expression failed, and
the local symbol names are gibberish as well.  What clues there are lie
past the right-hand edge of the backtrace window and might in fact be
unaccessible unless you have a really big display to blow the window up in.
 Hence your best and only usable debugging option is to run compiled code
with SAVE LOCAL SYMBOLS so you can see what values your symbols have, and
use lots of old-timey FORTRAN-era debugging printouts to narrow down which
expression failed.  Hardly modern, and not as good as we had a decade ago!

Fixing this would make MCL my favorite LISP; at this time, its main virtues
are only that it is a very complete Common LISP that also runs on my
favorite platform. 
-----------------
David Kieras
Artificial Intelligence Laboratory
Electrical Engineering and Computer Science Department
University of Michigan
Advanced Technology Laboratory Building
1101 Beal Avenue
Ann Arbor, MI 48109-2110
Phone: (313) 763-6739; Fax: (313) 763-1260
Email: kieras@eecs.umich.edu