Date: Sat, 17 Sep 2005 14:04:51 +0200 (MEST) From: Andras Simon andras@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 thereare 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.