Most of this mail has been responded to by other people, so I'll limit this response to the relevant bits to which no response has been made yet...
Date: Fri, 16 Sep 2005 13:14:07 +0200 From: Helmut Eller heller@common-lisp.net
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.
Is there more interest in maintaining a well-engineered & -specified protocol for general Lisp interaction, or in producing just an environment for Lisp development in Emacs, regardless of how messy the internals are, and without any provision for reuse & extension in other directions? For instance, the notion of utilizing Swank in the McCLIM tools has been considered, where those tools would serve as a Swank front end, if the protocol were sufficiently general and well- abstracted. (I'm not saying that SLIME should provide this, but rather that it may be a worthwhile direction to consider.)
For the most part, I think that, if the former goal is the one in mind, SLIME48 would require no harmful changes to slime.el: I am fairly certain that any changes I have in mind would only improve existing Common Lisp support in such a way as to also improve the ability to support Scheme48; that is, I expressly want to avoid anything very specific to Scheme48 in SLIME outside of the Scheme48 back end -- slime.el, the Swank protocol, &c.
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.
Accidental re-entrancy in Swank evaluations is pretty easily fixed; in fact, there's a comment ';++ prevent re-entrance?' in the relevant part of the code, SWANK-EVAL, which I've just modified to do so. If you try to use continuations as was done in your example, i.e. rely on certain ill-defined semantics of the re-entrancy of the REPL, you'll just get an error instead of the misleading result that you'd get in some REPLs.
I'll probably put it in a swank-scheme48 directory and I would also like to remove the -*- mode: scheme48; package: (exec) -*- lines because few people have a scheme48-mode and turning `package' into a buffer local variable isn't wise either.
I see the point about scheme48-mode, but I'm not sure I understand why having `package' as a buffer-local variable is unwise. Can you elaborate on that?
Still interested?
Maybe. I haven't been impressed by the attitude toward Scheme on this list, even though I've noted several times how non-invasive SLIME48's code is; most of the changes I'd like to make to slime.el either are minuscule (like the single change I've made so far, a two-character addition to the regular expression for definition finding) or would serve only to clarify the Swank protocol in ways beneficial overall that happen to allow better Scheme48 support.