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

Taylor Campbell campbell at mumble.net
Sat Sep 17 17:38:12 UTC 2005


   Date: Sat, 17 Sep 2005 14:04:51 +0200 (MEST)
   From: Andras Simon <andras at renyi.hu>

   On Sat, 17 Sep 2005, Taylor Campbell wrote:

   >    OTOH it'd be great if schemers created a fork of SLIME.
   >
   > Can you explain why you think this would be better than (very

   Because Schemers would then be free to modify it so that it becomes more
   scheme-friendly, to experiment with features that are important to them (doing
   cool stuff with continuations, whatever), etc without having to worry about CL
   compatibility. You say later that

   >                                              (I don't think there
   > are many other Schemes that could support or be supported by Swank
   > anyway in the same way that Scheme48 & MIT Scheme can, by the way.

   Wouldn't it be better to (at least be free to) redesign, or experiment with
   extensions, to Swank, so that other Schemes can be supported? And as long as
   there's no significant divergence, you could easily track developments in
   SLIME proper. Of course, even this means more work for you (as opposed to work
   for Helmut & co.). But you'll probably get more Schemers joining the effort so
   it's probably worth it.

   > non-invasively) adding Scheme support to the regular SLIME?

   I'd leave judging the level of invasiveness to the maintainers. Besides, what
   starts out as a non-invasive change may end up as a mess, especially if other
   schemes come along. Where do you draw the line?  Maybe I'm just a little
   paranoid. (But isn't everyone who have seen Ilisp?:))

As Alan Ruttenberg pointed out, most additional implementations of
Swank resulted in improvements to the whole system, which I think is
probably due primarily to the way that Swank is designed: a specified
protocol over TCP for communicating between a front end and a Lisp
back end.  ILISP, which I'd never really investigated before but which
I just took a look at the source of, seems to be more a collection of
ad-hoc elisp hacks for interacting with a miscellany of Lisps.

I'm not interested in adding new flashy bells & whistles to SLIME that
make sense in Scheme but not in Common Lisp; I think that Scheme48
(and maybe one or two more specific Scheme systems with some similar
designs) can mesh directly with the existing Common Lisp framework
with few visible seams.  Certainly, some of the operation might be
slightly different (such as the thread browser) in two Lisp systems,
but one will always be able to find two Lisp systems such that there
exist two SLIME features whose operation differs in the two Lisps,
whether those Lisps be both CL, both Scheme, or a cross.

(I was originally planning on developing a wholly new protocol, Emacs
front end (with help from people not averse to approaching elisp), and
Scheme back ends, but I came to a realization some time in late July
how much of it was ending up as equivalent to SLIME & Swank.  That's
when I started working on SLIME48, and I have yet to find a barrier at
any fundamental level to integrating SLIME with Scheme48.)

Quite frankly, I don't care about Schemes with module systems and
introspective facilities so limited or absent that they can't mesh
with SLIME.  It would be folly to bend the official SLIME to match
them, and it would therefore make sense for those Scheme systems to
fork SLIME or to use an entirely different basis (if they can support
a useful development environment at all).  But Scheme48 is not such a
limited Scheme.



More information about the slime-devel mailing list