David Rush,

The point of DrScheme language levels is that the PLT group have implemented several different compilers that target the PLT run-time. IIRC, this also includes Java and JavaScript compilers. While I am unaware of any a priori reasons why a gambit-compatible set of libraries couldn't be implemented using the PLT run-time, I'd be very sceptical about the marginal utility of such a package. I mean, we already *have* Gambit, and for IDEs, well gambit-mode in emacs works very well, and ISTR the Gambit team itself developing its own IDE (someone correct me here).

david rush

Thank you, David. Actually, I tried to grok emacs several times, but ...ugh :-) That's because I began to look towards different IDEs with more conventional user interface for windows users such as Visual Studio, Intellij IDEA, DrScheme... Do you think Emacs is superior?

Best regards, Nick

Hallo,

William Cook wrote:

I've asked here if anybody wants to help, but nobody has expressed any interest. I think that Eclipse+Scheme could bring scheme to a much wider audience. Its a shame that Scheme, despite (because of?) its long history, has not kept up with modern development environments now available for Python, Ruby, and Perl.

I am sincerely curious. Why does Eclipse+Plugin bring to you that Emacs does not? What's in these "modern development environments"?

Cheers, -alex http://www.ventonegro.org/

Hallo,

William Cook wrote:

Eclipse has built-in support for all these features. Here are some pictures

http://www.ibm.com/developerworks/library/os-ecbug http://www.fsl.cs.sunysb.edu/~dquigley/cse219/index.php?it=eclipse&tt=de...

Emacs has not stopped in time:

http://www.inet.net.nz/~nickrob/ http://www.emacswiki.org/cgi-bin/wiki/GrandUnifiedDebugger

Of course you are entitled to prefer Eclipse, but claiming that modern development environments do not exist for Scheme is only meaningful if by "modern" you mean "fancy". But it'd be really cool if you did your plugin, the more IDEs the better.

Cheers, -alex http://www.ventonegro.org/

Do you distribute your plugin somewhere?

Brad

Hallo,

William Cook wrote:

Yes, as i said in my email, I know that Emacs can do anything.

If fancy means taking advantage of ubiquitous bit-mapped displays, then I guess I do mean fancy.

So we can agree that Emacs is fancy too.

Neither of your links mention Scheme, as far as I can tell. And searching for Schema and GDB didn't bring up much of use either. Is there a connection between Emacs debugging and Gambit Scheme? If so, I'd like to know about it, because some of my students would like to use it.

Those are screenshots of the GDB mode, which I think is pretty neat. For Scheme one can use gambit.el (that comes with Gambit-C) or quack.el[1]. They may be not as fancy or beautiful as the GDB mode (or Eclipse), buy they do work. Besides, one can add as much fanciness as he wants.

[1] - http://www.neilvandyke.org/quack/

Cheers, -alex http://www.ventonegro.org/

Hallo,

William Cook wrote:

The page you gave about quack didn't mention debugging, and gambit.el has very minimal support, as far as I can tell. My point is that these are not acceptable solutions, yet the fact that people think they count as a solution seems to prevent the creation of real solutions. Telling me that "I can create my own" is also not very helpful. I think that a language implementation is not complete without a good out-of-the-box development environment, which includes a good debugger. I stand by my assertion that there are no complete implementations of Scheme. And this is very unfortunate. I also admit being annoyed by this situation, but I'm not just complaining; I am trying to do something about it.

First of all, by all means, finish your plug-in. I never said "stop this project!" or hinted in this direction. That will be a nice addition to the Schemer toolbox, and I guess lots of Schemers would switch to it once it's available. My reply was prompted by the whining "It is sad that the Scheme community... blah, blah, blah... Python, Ruby have it... blah blah." You say that nor quack neither gambit.el have a debugger, but the REPL *is* the debugger! You have backtraces, you can resume from an exception, you can see the environment of any frame etc. It's all there, it's not just behind shiny icons, it's in the REPL. If this does not suit you, fine, you are doing something about it. My comment "add your own" was not about writing a debugger, was about adding the desired fanciness to what is already there. But I do not feel any less equipped than the developers of any other language nor I think I should be sad.

Cheers, -alex http://www.ventonegro.org/

On Tue, Sep 02, 2008 at 10:00:16AM -0400, Joel J. Adamson adamsonj@email.unc.edu wrote:

they got the idea? Lisp machines had source debuggers for the entire operating system, and Emacs works on the same principle, with interactive debuggers available.

If you're talking about the MIT designs for LISP machines, the debugger (that is, the thing that gets control after most runtime errors) is not a source debugger. Yes, the whole system is written in LISP. Yes, you can edit the definition of a function and recompile it at any time, including from the debugger. But the debugger only knows about compiled code. That never changed through the life of the LISP machine. There is a stepper for interpreted code though. I'm using the present tense because you can run your own CADR:

http://www.unlambda.com/cadr/index.html

I don't know the details of Xerox or any other types of LISP machine.

-- Derek

I know this is veering away from Gambit. Maybe the URLs are useful though.

On Thu, Sep 04, 2008 at 11:17:37AM -0400, Joel J. Adamson adamsonj@email.unc.edu wrote:

Interesting: my comment was based on an account of using a Lisp Machine in the UNIX-HATERS Handbook, although the author didn't mention whether it was Symbolics, LispM, Xerox, TI...he just said he preferred it Unix ;)

In my few serious computer-history investigations, I've found that the primary sources are detailed and correct in a way the secondary sources aren't. (In the case of the MIT Lisp Machines, Dan Weinreb -- who founded Symbolics and wrote a lot of the software -- told me in e-mail that they never got source debugging.)

Sweet, I'm working on getting it to run right now ;)

You'll need to hunt around for the manuals. The TI directrories below are pretty complete, though they describe newer software than the CADR runs. And you may want to check that all the key mappings work.

http://www.bitsavers.org/pdf/mit/cons/ http://www.bitsavers.org/pdf/mit/cadr/ http://www.bitsavers.org/pdf/lmi/ http://www.bitsavers.org/pdf/symbolics/ http://www.bitsavers.org/pdf/ti/explorer/ http://www.bitsavers.org/pdf/ti/microexplorer/

http://www.bitsavers.org/pdf/xerox/interlisp/

http://www.bitsavers.org/ has a list of mirror sites for the directories above.

http://www.softwarepreservation.org/projects/LISP has links to documents about many old LISPs.

-- Derek

On Thu, Sep 04, 2008 at 03:14:59PM -0400, Joel J. Adamson adamsonj@email.unc.edu wrote:

Interesting and good to know; my point still stands that Lisp had debuggers before Ruby and Python ever existed ;) Peter Norvig even said (circa 1997) that Lisp still has best interactive system of any language[1].

I'm not disagreeing with those points. I also looked at various (mostly free) Schemes and I agree with William Cook's comment that "Gambit's underlying capabilities for debugging are better than most". But knowing the details behind "best" is important too, so I just wanted to clear up the one sub-point about LispMs.

-- Derek

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 know about other JScripts/JavaScripts. Some LISPs/Schemes are interpreters 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.

-- Derek

Alex and Joel,

I have been using the text-based debugger in Gambit for about 6 months. I know about ",s", ",e", ",b" and friends. I have dug into the Gambit code and am using the underlying functions to connect these facilities to the Eclipse debugger GUI. Gambit is reasonable in this respect, although the lack of breakpoints is annoying. I looked into other versions of Scheme, and as far as I can tell Gambit's underlying capabilities for debugging are better than most. But I'm tired of typing commands, and I'm tired of copying variable names so that I can execute them. I'm tired of writing my own inspectors to get views of my objects. This is all much harder than it should be, and in the long run it reduces my debugging productivity significantly, over using a good graphical debugger. To me, a REPL is not a debugger. Maybe 20 years ago it would be acceptable, but not now. I'm willing to put up with it because I need to use Scheme. I'm specifically talking about debugging here, not other aspects of the development environment.

I can see that there is a culture clash here. I know I'm representing a view that is a minority on this list. But I'm looking at Scheme from the outside, and this is how it seems to me.

William

On Tue, Sep 2, 2008 at 1:46 PM, William Cook wcook@cs.utexas.edu wrote:

I stand by my assertion that there are no complete implementations of Scheme.

Smile when you say that. Them's fighting words :)

'Complete' generally means RnRS-conformant for whatever values of N you happen to like.

And this is very unfortunate. I also admit being annoyed by this situation, but I'm not just complaining; I am trying to do something about it.

And most everybody else is trying to get stuff done using Scheme. But I'm definitely *not* installing eclipse for debugging support when I've already got Emacs. OTOH, I'd love to see even a good command line debugger in a Scheme system and none of them are very good.

david

...

...

...

...

"William" == William Cook wcook@cs.utexas.edu writes:

William> I don't know emacs so I cannot comment on how it interfaces William> with the Gambit text-based debugger.

First of all, no one knows Emacs, it is unknowable ;)

As to the debugger, look at this: ,---- | (let loop ((lis (list 'monkey (+ 1 2) "I love Gambit!"))) | ;; step through this ridiculous loop | (step) | (if (null? lis) | (error "No more funny messages") | (display (car lis)))) | *** STOPPED IN loop, (console)@214.10 | 1> ,s | | > null? | | #<procedure #16 null?> | *** STOPPED IN loop, (console)@214.16 | 1> ,s | | > lis | | (monkey 3 "I love Gambit!") | *** STOPPED IN loop, (console)@214.9 | 1> ,s | | > (null? lis) | | #f | *** STOPPED IN loop, (console)@216.10 | 1> ,s | | > display | | #<procedure #17 display> | *** STOPPED IN loop, (console)@216.19 | 1> ,s | | > car | | #<procedure #11 car> | *** STOPPED IN loop, (console)@216.23 | 1> ,s | | > lis | | (monkey 3 "I love Gambit!") | *** STOPPED IN loop, (console)@216.18 | 1> ,s | | > (car lis) | | monkey | *** STOPPED IN loop, (console)@216.9 | 1> ,s | | > (display (car lis)) | monkey| #!void | > `----

At each calculation it stops, and you can step through with ,s. At each "step", a new window opens and highlights the current position in the source code. This works on the console (listener) and from a source file. That's just the tip of the iceberg. At each step, you can get a backtrace, print the environment and all that crap. Gambit-mode also links into cmuscheme mode so that the same compile-and-load commands from MIT Scheme work with Gambit (using compile-file).

Yes, there is no completion or reminder-completion, like there is with Slime, and that would be pretty cool, but I don't find it too irritating. For someone who just loves to use Emacs, it's pretty cool. Quack is really cool too for the documentation links it provides (you can look up any SRFI you want with a few keystrokes, but I"m unaware of a debugger (if someone knows of one in Quack, please let me know).

Joel