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

[Helmut Eller]

* Taylor Campbell [2005-09-16 04:58+0200] writes:

> I think my question might have been lost in the traffic of the mailing
> list, so I'll ask once more: several people, including Marco Baringer,
> have suggested that it might be a good idea to add the Scheme48 back
> end to the main SLIME CVS source repository.  I could fork SLIME to
> support the small changes needed for SLIME48 myself, but that would
> really be a pain to maintain, and I'd like SLIME48 to work pretty much
> out of the box.  What do the SLIME developers/maintainers think about
> this?

When Luke announced SLIME, the bit I liked most about it was this:

   The goal is to make Emacs support CMU Common Lisp as well as it
   supports Emacs Lisp. The strategy is to take maximum advantage of
   all CMUCL features and hooks, portability be damned to hades.
   
   Compatibility with other Common Lisps is not a goal.

Sadly, the goals shifted a bit since then.

I'm not that excited about supporting every Frankenstein Lisp on the
planet, just because we can.  And frankly, who wants to use a Lisp
which doesn't even have docstrings?

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.

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.

If you still want to add your code to SLIME and nobody (hi Luke :-)
has objections, I'll do the initial check-in and ask the cl.net admins
to give CVS permissions.

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.

Still interested?