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

[Taylor Campbell]

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