[gambit-list] DrScheme and GambitC
dpeschel at eskimo.com
Mon Sep 8 14:23:23 EDT 2008
This is a long message because I'm interested in this topic and have been
thinking about it. I wish I had more answers and not just questions!
On Fri, Sep 05, 2008 at 09:26:50AM -0500, William Cook wrote:
> Resting on laurels!
LISP or you? :)
> My question is why Lisp/Scheme seems to be behind *now*, when it should be even
> farther ahead given the long head-start it had. It may have been true when Peter said
> it, but that was just at the start of the rise of the scripting languages (Python,
> etc). Note that Microsoft has had a very reasonable JScript debugger since the late 90's.
I know what you mean, but I want to ask some preliminary questions and then
rephrase your original question.
First, can we really compare LISP and Scheme systems to JScript, Ruby,
Python, etc.? Ruby and Python are interpreters, with the debugger written
partly in Ruby or Python but also using debugging support functions built
into the interpreter. For MS's JScript, I would be surprised if the
debugger is written in JScript at all. I assume it's written in C, as a
separate process that communicates with the JScript interpreter. I don't
but some are native code compilers. That makes the problem of writing a
debugger very different than for an interpreter.
Second, should we really combine LISP and Scheme? How do LISP and Scheme
differ in their support for debuggers? The Common LISP standard includes an
error handling feature but says nothing about interactively watching or
controlling another computation (which may be stopped because of an error,
or may not). The Scheme standard and SRFIs don't say much about error
handling or debugging either. Common LISP includes the idea of restarts,
which Scheme doesn't have, as part of the error handling feature. Scheme
includes first-class continuations and tail call elimination and other things
LISP doesn't have. Is it easier to write a debugger for one language or the
other? Is it easier to write a debugger _in_ one languge or the other?
Now... To me debugging is a problem that each implementation solves or ignores
on its own. LISP's head start may give new authors ideas, but I don't expect
it to guarantee anything. I've seen many LISPs/Schemes whose authors aren't
experienced enough to know that a debugger is important, or are experienced
but don't believe in interactive debuggers, or seem to have emphasized other
features instead of debugging.
Also I don't see how other languages' examples have made LISP worse. LISP
is still there, same as before. The other languages have highlighted LISP's
stagnation though. So: What can LISP and Scheme authors do to make LISP and
Scheme implementations with great debuggers, building on the experience of
all previous authors, including the implementors of other langauges?
Although we have many old LISPs to learn from, I haven't seen very much
documentation of the underlying principles, algorithms, or design decisions
used in those LISPs or their debuggers. I've seen plenty of papers about
related topics -- recursion theory, metacircular or reflective interpreters,
self-virtualizing CPUs, virtual-machine monitors, machine language or C source
debuggers. So I've been eagerly looking for the last step, describing going
from theory to application. The lack of papers is definitely part of the
problem. Without documentation, implementors tend to copy what they know
(what they can see) or reinvent it from scratch.
Maybe you can tell I'm not looking for fancy features and a flashy
interface. Instead I would like a solid foundation of support functions
and a productive interface. (TTY windows aren't productive but I don't like
Emacs either. I haven't found anything I really like, actually.) Also the
ability to find and fix bugs, the ability to debug as much of the LISP
system as possible, extensibility, speed, good documentation, no bugs in the
debugger, and all those other wishes that are hard to get right.
More information about the Gambit-list