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

[Taylor Campbell]

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 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.