* 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 Sadly, the goals shifted a bit since then. of the project.
Sure. That's why Taylor Campbell should at least consider making a fork.
I'm not that excited about supporting every Frankenstein Lisp on the planet, just because we can. And frankly, who wants to use a Lisp which doesn't even have docstrings?
Taylor's goal in this project was to make a good Emacs IDE for Scheme48, not to make SLIME support "every Frankenstein Lisp". SLIME was just the tool he chose to make this happen.
Scheme48 is a Frankenstein Lisp by my definition. If SLIME doesn't need to support Scheme48, why does he even bother us/me then?
If you want to add your code to our CVS repo, it should be clear that Scheme is only a second class citizen here, and that we have limited motivation to make/keep the protocol working with the Scheme server.
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.
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.
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.
* Taylor Campbell [2005-09-17 05:03+0200] writes:
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.
It's clearly more work to maintain a Scheme Swank server than not to. With the Scheme server, if we change the protocol, we have to change it in two servers. There is also quite a bit of code for completion, apropos, the REPL, etc. which can be written reasonably well in ANSI CL without implementation specific hooks. For Scheme it has to be maintained a second time.
-
Helmut Eller -
Taylor Campbell