Date: Fri, 16 Sep 2005 22:22:42 +0200 From: Helmut Eller heller@common-lisp.net
* Brian Mastenbrook [2005-09-16 13:55+0200] writes:
On Sep 16, 2005, at 6:14 AM, Helmut Eller wrote:
Sadly, the goals shifted a bit since then.
I don't think very many people would agree that this is "sadly". If this is the way you feel, however, I'm sure that there are enough people who prefer using SLIME on other Common Lisps to sustain a fork of the project.
Sure. That's why Taylor Campbell should at least consider making a fork.
I have considered a fork, and there would be, I think, some advantages to doing this, but there are also significant disadvantages, most notably in synchronizing work on CL-SLIME & SLIME48, which is a pain in any fork, and which I don't really want to deal with, particularly if I want to take advantage of the opportunities for SLIME48-specific changes, even if those would be advantageous at some level. However, if it is concluded that SLIME48 is unwelcome, I'd more seriously consider forking -- but I don't think, at the moment, that there are good reasons to make SLIME48 unwelcome.
Scheme48 is a Frankenstein Lisp by my definition. If SLIME doesn't need to support Scheme48, why does he even bother us/me then?
One could say the same thing about any Lisp system that SLIME supports. SLIME48 differs only in the language in which its Swank implementation is written.
Why does that need to be? Why can't Taylor just maintain the Scheme48 support to the best level possible, just as is done with the other backends?
Because he wrote his own server (swank) not only the implementation specific part (swank-backend). His server also uses a rather different approach to threading than we do.
Can you explain why you think it will be an impediment to maintenance that I wrote an entire Swank server versus just a Common Lisp Swank back end? I think it might actually be easier to maintain this, because there is a single approach to everything in SLIME48, whereas the Common Lisp implementation of Swank has to deal with four different communication styles, threads versus non-threads, and compatibility in swank.lisp with all of the N different CL back ends. But I'd like to hear why you think this is not the case.
The approach to threading is different, but more appropriate in the context of Scheme48, and it is also not incompatible with SLIME. It is of no consequence that SLIME48 ignores the thread argument in some Swank messages; the information is not lost, but rather recorded in a different (and, again, more appropriate) manner on the Scheme48 side, such that the thread argument is unnecessary. I have not yet implemented the thread browser, but I shall soon, and I already have a pretty good idea about how to do it without changing the Emacs side but with a different thread model running on the Lisp side.
On the technical side, Scheme has continuations but SLIME assumes that the Lisp is stack oriented. I haven't thought too much about it, but there will likely be problems if somebody calls a continuation multiple times. Also, interrupting doesn't seem to work with your backend, or not in the way I expected it.
I'm not sure what those problems would be. Can you clarify?
Try
(define k (call-with-current-continuation (lambda (c) c))) (k 1)
and type C-x C-e at the end of each line.
I have just fixed this. Now, instead of an obscure error in the Emacs process filter, you get a Scheme error about re-entering a SLIME evaluation; you can abort (with q or the ABORT restart) and return to normalcy, causing only a warning to be signalled on the Scheme48 side.