[slime-devel] SLIME48: a Swank back end in Scheme48

Taylor Campbell campbell at mumble.net
Sat Sep 17 02:47:42 UTC 2005

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

   Date: Fri, 16 Sep 2005 13:14:07 +0200
   From: Helmut Eller <heller at 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.

More information about the slime-devel mailing list