About a month ago, as I was thinking about building a comprehensive development environment for Scheme (& Scheme48 in particular), akin to SLIME, the notion occurred to me that Scheme48 might actually provide the necessary facilities for a realistic Swank back end (as compared to the mostly toy back end Helmut Eller sent here a while ago). So I started working on it a bit in small increments, and pretty soon Emacs was successfully talking to it over TCP to evaluate simple REPL expressions. Last week I implemented SLDB support, after rewriting it from scratch once my initial prototype worked; I spent the whole weekend fixing a really obscure bug involving threads, continuations, & DYNAMIC-WIND; and just today I've gotten it into an almost usable state for REPL work (though not file & module loading & such yet).
Currently, I'm not using any source control yet, and I haven't released the code anywhere, but Marco Baringer and several others recommended that I simply add the Scheme48 back end to the main SLIME CVS source repository. If everyone relevant would be OK with this, I'd like to do it, but I see one potential problem with it, assuming that no one would object to including Scheme code in SLIME: I've organized my Scheme48 back end into about a dozen different files, which is pretty different from the existing organization of SLIME code (one monolithic file for the Emacs side; one monolithic file for the bulk of the CL side; one monolithic file for each back end). Would this bother anyone?
(I intend, by the way, not to change the Emacs side of SLIME to add anything Scheme-specific; if anything, I'd want only to make slime.el work better with both Scheme & CL -- e.g., Marco Baringer just kindly committed a change I suggested that makes the definition locator code look for definitions where a sequence of parentheses might precede the name being defined, such as in (DEFINE (FOO X) ...) to define FOO in Scheme, or (DEFSTRUCT (BAR ...) ...) to define a BAR structure in CL. There are a few other minor changes like these that would be convenient for Scheme48's back end, but which would not get in the way of the CL back ends, too.)
Obligatorily, here's some SLIME48 porn, by the way:
http://www.bloodandcoffee.net/campbell/slime48-sldb-porn.png
(The CL-USER prompt and the mention of a COMMON-LISP-USER package are due to slime.el's hard-coded initial package of COMMON-LISP-USER -- another small change I'd like to make is to allow customization of the initial package. (The temporary solution was for me just to define a COMMON-LISP-USER package in Scheme48, of course.))
* Taylor Campbell [2005-08-23 20:47+0200] writes:
About a month ago, as I was thinking about building a comprehensive development environment for Scheme (& Scheme48 in particular), akin to SLIME, the notion occurred to me that Scheme48 might actually provide the necessary facilities for a realistic Swank back end (as compared to the mostly toy back end Helmut Eller sent here a while ago). So I started working on it a bit in small increments, and pretty soon Emacs was successfully talking to it over TCP to evaluate simple REPL expressions. Last week I implemented SLDB support, after rewriting it from scratch once my initial prototype worked; I spent the whole weekend fixing a really obscure bug involving threads, continuations, & DYNAMIC-WIND; and just today I've gotten it into an almost usable state for REPL work (though not file & module loading & such yet).
Would you mind to post the code for the "realistic" backend? With what version of scheme48 does it work?
On Tue, 23 Aug 2005, Helmut Eller wrote:
Would you mind to post the code for the "realistic" backend?
Sure -- I'm just cleaning it up a bit now, and I'll put the source up on the web for others to see and (minimally) use in a day or two.
With what version of scheme48 does it work?
It will run in Scheme48 1.3. It could be modified to run in slightly earlier versions, but there would need to be somewhat more major changes for it to run in 0.57 or earlier.
Taylor Campbell campbell@bloodandcoffee.net writes:
On Tue, 23 Aug 2005, Helmut Eller wrote:
Would you mind to post the code for the "realistic" backend?
Sure -- I'm just cleaning it up a bit now, and I'll put the source up on the web for others to see and (minimally) use in a day or two.
Very cool. :) The lack of an useable interface always kept me from writing more Scheme code.
With what version of scheme48 does it work?
It will run in Scheme48 1.3. It could be modified to run in slightly earlier versions, but there would need to be somewhat more major changes for it to run in 0.57 or earlier.
Do you think it will work with scsh (the SCheme SHell)? It is Scheme48-based.
Regards,
On Wed, 24 Aug 2005, Julian Stecklina wrote:
Taylor Campbell campbell@bloodandcoffee.net writes:
With what version of scheme48 does it work?
It will run in Scheme48 1.3. It could be modified to run in slightly earlier versions, but there would need to be somewhat more major changes for it to run in 0.57 or earlier.
Do you think it will work with scsh (the SCheme SHell)? It is Scheme48-based.
No. Scsh is based on a very old version of Scheme48 -- 0.53, which is about four or five years old --, and many system internals have changed since then, most notably in the multithreading libraries. SLIME48 could probably be modified to run in scsh, but it won't do so out of the box. An endeavour to make scsh run in Scheme48 1.3 would be much more worthwhile, though considerably more difficult; I hear that there has been some work on that at Tuebingen, where most Scheme48 development is happening these days, but I don't know many details of this effort. (Much of the work would involve restructuring scsh to probe less deeply into Scheme48's internals and modularizing it much more cleanly.)
OK, I've cleaned up the Scheme48 back end a bit and put it up on the web; it's browsable in
http://www.bloodandcoffee.net/campbell/slime48/
and there's a tarball slime48.tar.gz in the parent directory. All of the code is in the public domain. (Yes, there are a lot of features yet to be implemented, such as, most notably, name completion and the inspector. I'll be working on them this weekend.)
I've just put up a new and considerably improved tarball of the current status of Scheme48; since the last one, I've also moved hosts (and therefore email addresses & URLs), so it's now up at
http://mumble.net/~campbell/scheme/slime48.tar.gz
(and web-browsable in the slime48/ subdirectory of the same directory as slime48.tar.gz is in). Many features are still missing, but I've added important ones like evaluation in SLDB frames, an inspector, & I/O, and it's approaching actual usability now, I think, though there is a bit that would need more support on the Emacs side before I can continue and make it really usable in Scheme48 hacking. (For example, module control commands would be necessary for that -- commands which, for the most part, I believe, could be equally applicable to Common Lisp packages or ASDF systems.)
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?
* 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?
On Fri, 16 Sep 2005 13:14:07 +0200, Helmut Eller heller@common-lisp.net wrote:
If you still want to add your code to SLIME and nobody (hi Luke :-) has objections
I'm not Luke but I (at least partly) agree with what you've written. I think it's a good thing that SLIME aims to support only Common Lisps. We shouldn't try to turn SLIME into a second ILISP.
As for whether it's a good thing or not that other CL implementations than CMUCL are supported I beg to differ... :)
My EUR 0.02.
Cheers, Edi.
On Sep 16, 2005, at 6:14 AM, Helmut Eller wrote:
- 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 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.
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?
Taylor's goal in this project was to make a good Emacs IDE for Scheme48, not to make SLIME support "every Frankenstein Lisp". SLIME was just the tool he chose to make this happen.
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.
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?
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?
SLDB works just fine: the current continuation can be presented as a "stack", and this is exactly how it's done in the Scheme48 REPL too.
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.
-- Brian Mastenbrook brian@mastenbrook.net http://brian.mastenbrook.net/
On Fri, 16 Sep 2005, Brian Mastenbrook wrote:
On Sep 16, 2005, at 6:14 AM, Helmut Eller wrote:
[...]
Compatibility with other Common Lisps is not a goal.
Sadly, the goals shifted a bit since then.
I don't think very many people would agree that this is "sadly". If
That's right and I'm not one of them (I've used slime with five CL implementations so far). But then it's mainly Helmut (and Luke, and a select few, of course) who has had to worry about the idiosyncracies of the various implementations.
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.
Would _you_ be willing to put as much thought and care into maintaining SLIME as Helmut has for the past two years? I think SLIME without Helmut would be rather slim.
OTOH it'd be great if schemers created a fork of SLIME.
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?
Taylor's goal in this project was to make a good Emacs IDE for Scheme48, not to make SLIME support "every Frankenstein Lisp". SLIME was just the tool he chose to make this happen.
The problem with Scheme is that there's so many of it. At least the number of CL implementations is bounded.
My 0.02 HUF (that's 8.0e-5 EUR, if you want to know).
Andras
Date: Sat, 17 Sep 2005 01:33:44 +0200 (MEST) From: Andras Simon andras@renyi.hu
On Fri, 16 Sep 2005, Brian Mastenbrook wrote:
On Sep 16, 2005, at 6:14 AM, Helmut Eller wrote:
[...]
Compatibility with other Common Lisps is not a goal.
Sadly, the goals shifted a bit since then.
I don't think very many people would agree that this is "sadly". If
That's right and I'm not one of them (I've used slime with five CL implementations so far). But then it's mainly Helmut (and Luke, and a select few, of course) who has had to worry about the idiosyncracies of the various implementations.
I don't think that they would have to worry about the Scheme48 Swank implementation. Once SLIME48 is fairly stable with respect to existing SLIME features, I think I could probably maintain its continual development in the context of SLIME's pretty easily.
OTOH it'd be great if schemers created a fork of SLIME.
Can you explain why you think this would be better than (very non-invasively) adding Scheme support to the regular SLIME?
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?
Taylor's goal in this project was to make a good Emacs IDE for Scheme48, not to make SLIME support "every Frankenstein Lisp". SLIME was just the tool he chose to make this happen.
The problem with Scheme is that there's so many of it. At least the number of CL implementations is bounded.
So many of it? SLIME48 is just Scheme48, nothing else. I have considered an MIT Scheme Swank implementation, too, which would be somewhat closer to CL, actually, at least in threading; however, this is just two Schemes, not the whole Scheme world. (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.)
Just a note of support for the general idea of incorporating Taylor's extension.
1) Selfish: I'd probably write more scheme code if there was a decent (= slime :) development environment 2) It seems like it is only gently touching the existing code 3) My opinion: More implementations have, in this project, led to better abstraction, which in turn has benefited all the implementations. I don't see why the the scheme backend won't lead to the same type of improvements.
Caveat: I don't understand the full implications as deeply as Helmut does - e.g. I wouldn't have picked up the cc/repl issue (until it happened to me). However it seems like a good start that his issue has already been addressed with a patch. I'm interested in seeing more substantive criticism.
-Alan
Alan Ruttenberg alanr-l@mumble.net writes:
Just a note of support for the general idea of incorporating Taylor's extension.
I like the idea too. I fired up SLIME48 and was impressed that it did so much stuff without even one line of change in slime.el. Very good! (Didn't handle my ~/.slime-secret though :-)
I sympathise with Helmut too. He is the main one who has been making fixes across lots of different backends instead of just living in one.
From my lazy point of view it's just to use the CMUCL backend and
benefit from the portable features that are being added by everybody.
I have one idea about cutting down noise in CVS if it becomes a problem: We could move the Scheme code into a new top-level swank48/ directory and add an entry in CVSROOT/modules called 'slime48' to checkout slime/ and swank48/. Just if the CL people tire of seeing scheme files in 'cvs update'.
Luke Gorrie writes:
Alan Ruttenberg alanr-l@mumble.net writes:
Just a note of support for the general idea of incorporating Taylor's extension.
I like the idea too. I fired up SLIME48 and was impressed that it did so much stuff without even one line of change in slime.el. Very good! (Didn't handle my ~/.slime-secret though :-)
I sympathise with Helmut too. He is the main one who has been making fixes across lots of different backends instead of just living in one.
From my lazy point of view it's just to use the CMUCL backend and
benefit from the portable features that are being added by everybody.
I have one idea about cutting down noise in CVS if it becomes a problem: We could move the Scheme code into a new top-level swank48/ directory and add an entry in CVSROOT/modules called 'slime48' to checkout slime/ and swank48/. Just if the CL people tire of seeing scheme files in 'cvs update'.
This sounds a lot like the proposal I had for an amicable fork: why can't "slime48" be swank48, and share the emacs front-end with slime? It sounds like slime48 is a terrible misnomer, which is good news to my ears. If Scheme48 integration is really as painless as it's been pitched to be, I don't see any reason why it can't exist as an amicable swank fork, with any new-feature enabling changes being propogated back and forth. Swank and swank/scheme aren't objectively competing, and given the very positive history of cmucl and sbcl (which are objectively competing, even if they try to cooperate where possible), I'd think cooperation between the forks would go well.
On Sat, 17 Sep 2005, Taylor Campbell wrote:
Date: Sat, 17 Sep 2005 01:33:44 +0200 (MEST) From: Andras Simon andras@renyi.hu
On Fri, 16 Sep 2005, Brian Mastenbrook wrote:
On Sep 16, 2005, at 6:14 AM, Helmut Eller wrote:
[...]
Compatibility with other Common Lisps is not a goal.
Sadly, the goals shifted a bit since then.
I don't think very many people would agree that this is "sadly". If
That's right and I'm not one of them (I've used slime with five CL implementations so far). But then it's mainly Helmut (and Luke, and a select few, of course) who has had to worry about the idiosyncracies of the various implementations.
I don't think that they would have to worry about the Scheme48 Swank
I think they have to worry about everything that goes below common-lisp.net:/project/slime/cvsroot :)
implementation. Once SLIME48 is fairly stable with respect to existing SLIME features, I think I could probably maintain its continual development in the context of SLIME's pretty easily.
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?:))
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?
Taylor's goal in this project was to make a good Emacs IDE for Scheme48, not to make SLIME support "every Frankenstein Lisp". SLIME was just the tool he chose to make this happen.
The problem with Scheme is that there's so many of it. At least the number of CL implementations is bounded.
So many of it? SLIME48 is just Scheme48, nothing else. I have considered an MIT Scheme Swank implementation, too, which would be somewhat closer to CL, actually, at least in threading; however, this is just two Schemes, not the whole Scheme world. (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.)
See above. Plus, I think Scheme (or at least its major variants) deserve(s) a SLIME of its (their) own (SSLIME? SSIME? S2IME? SLIME/S? SLIMES?). I'd say go for it!
Andras
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.
Brian Mastenbrook brian@mastenbrook.net writes:
I'm sure that there are enough people who prefer using SLIME on other Common Lisps to sustain a fork of the project.
Yes! I see no reason why forking wouldn't work every bit as well for SLIME as it did for Emacs itself.
I may have spoken too soon when I said that I was still interested in hosting SLIME48 in the official SLIME repository, since it seems that there may be interest all around in forking SLIME for SLIME48. I'd therefore like to poll this list's subscribers to see who would prefer this option, which I'm now ambivalent about. In order not to clutter the list, though, please send responses privately via mail, or contact me on IRC (in #lisp or #scheme as Riastradh on irc.freenode.net).
To clarify briefly: by a fork of SLIME for SLIME48, I don't mean to make a fork that is completely oriented toward Scheme48 (or Scheme48 & MIT Scheme, or whatever), but rather to make a more clearly specified network protocol for communicating between a user interface and a Lisp system, less particular to Common Lisp or Emacs than the current Swank protocol is, and to hack the existing SLIME & Swank code to implement this protocol (which would not be very different from Swank).
I was almost convinced earlier today not to fork SLIME, as everyone who responded to my poll (about five or six people) was opposed to it, and I didn't want the maintenance burden of a SLIME fork; I was about to send mail to this regard a few minutes ago, until I received the ChangeLog diff showing numerous changes to the SLIME48 code that were made without my knowledge, that I was not sent or even contacted about before they were committed, that were inconsiderate of Scheme & Scheme48's style & design, that were committed even before I got CVS access, and that were made without regard to the separate Darcs repository that I was maintaining. I was under the impression, too, that the general attitude was that burden of SLIME48's maintenance should *not* be placed on the existing SLIME maintainers.
I am sorry to those who would have preferred no fork, and I apologize for the bother taken to put SLIME48 in SLIME's CVS, but under the circumstances and in consideration of the possible advantages that more freedom from the current SLIME development might allow, I'd rather fork SLIME.
(I have been a bit busy these past couple weeks, which is why I haven't been very quick to respond, and which is why I haven't made many changes on my end to SLIME48 during this time. This is not a permanent status, however; I shall work on it more in the next few days.)
Taylor Campbell campbell@mumble.net writes:
I am sorry to those who would have preferred no fork, and I apologize for the bother taken to put SLIME48 in SLIME's CVS, but under the circumstances and in consideration of the possible advantages that more freedom from the current SLIME development might allow, I'd rather fork SLIME.
SLIME developers are obviously allowed to hack the code in SLIME CVS. They do not need your permission.
Good luck with your fork.
* Taylor Campbell [2005-09-29 05:39+0200] writes:
I was almost convinced earlier today not to fork SLIME, as everyone who responded to my poll (about five or six people) was opposed to it, and I didn't want the maintenance burden of a SLIME fork; I was about to send mail to this regard a few minutes ago, until I received the ChangeLog diff showing numerous changes to the SLIME48 code that were made without my knowledge, that I was not sent or even contacted about before they were committed, that were inconsiderate of Scheme & Scheme48's style & design, that were committed even before I got CVS access, and that were made without regard to the separate Darcs repository that I was maintaining. I was under the impression, too, that the general attitude was that burden of SLIME48's maintenance should *not* be placed on the existing SLIME maintainers.
First, I asked the cl.net guys to give you permissions a week ago. Maybe you should have said a word to me that you still haven't received your password.
Second, if you don't like my changes, feel free to fix them.
I am sorry to those who would have preferred no fork, and I apologize for the bother taken to put SLIME48 in SLIME's CVS, but under the circumstances and in consideration of the possible advantages that more freedom from the current SLIME development might allow, I'd rather fork SLIME.
Well, it's your decision.
Helmut Eller heller@common-lisp.net writes:
Second, if you don't like my changes, feel free to fix them.
I removed the swank48 backend from CVS so as not to "fork the fork".
Argh.
I've been away for the past several days, so I didn't see what was going on until now...
I apologize for my previous message, which I wrote in haste very soon after noticing the changes which had irked me. It was quite silly of me, I see now, to whine as I did, and I hope that it won't permanently damage cordiality of development between SLIME and my Swank back end for Scheme48: I now think that it may be better to keep SLIME48 in its own Darcs repository anyway, for several reasons, but I do still have some changes to SLIME in mind that I hope may still be considered later (when I formulate them specifically). I have no intention of actually forking SLIME any time soon; I'll try to maintain a working status between SLIME48's development & SLIME CVS, and periodically put out tarballs containing combinations of my Scheme48 back end and slime.el known to work.
Taylor Campbell campbell@mumble.net writes:
I apologize for my previous message, which I wrote in haste very soon after noticing the changes which had irked me.
I also pressed Send in haste. Hard to resist doing that sometimes even when we know better :-). No hard feelings!
Cheers, Luke
Helmut Eller heller@common-lisp.net writes:
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've downloaded Scheme48 and will try to take a look and throw in my $0.02 this weekend. I don't have any objection in principle and think it's great if it will fit together fairly well (not too much impact on the shared code). I have been pretty surprised at how little impact the other Lisp backends have had when done carefully (compared with the #+hell in ilisp). Scheme is of course a bigger step :-)
Cheerio, Luke (hacking Erlang this past year and a bit out of touch)
On 9234 day of my life Luke Gorrie wrote:
Cheerio, Luke (hacking Erlang this past year and a bit out of touch)
Next will be Erlang backend, I presume? :)
Date: 16 Sep 2005 16:01:45 +0200 From: Luke Gorrie luke@synap.se
I've downloaded Scheme48 and will try to take a look and throw in my $0.02 this weekend.
Just to be clear, by the way: SLIME48 is currently in an experimental development state, not really ready for serious use; I'm sure there are a lot of bugs (like the ones Helmut Eller pointed out regarding interrupts and continuation re-entrancy), and there are many as yet unimplemented features as well still, but that Swank can support Scheme48 (or vice versa, perhaps) is the important element, and bugs & missing features can be fixed.
I don't have any objection in principle and think it's great if it will fit together fairly well (not too much impact on the shared code). I have been pretty surprised at how little impact the other Lisp backends have had when done carefully (compared with the #+hell in ilisp). Scheme is of course a bigger step :-)
Actually, I was very surprised to find how easily Scheme48 supported the ostensibly pretty CL-oriented Swank. There are a few parts that expose too much of CL (such as some internal symbol references sent by the elisp side of Swank, and the #. read syntax used in one place for presentations), but these are very small and inconsequential. I think a useful Scheme48 environment (which SLIME48 is not quite yet, but which it will be soon) requires very few additions on the SLIME Emacs side, too; most ASDF or CL package system commands translate directly to Scheme48's module system, which is one of the most important parts of any environment for Scheme48.
On Fri, 16 Sep 2005 13:14:07 +0200, heller@common-lisp.net wrote:
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.
It's mere presence in the CVS will upgrade it.
People will join this mailing list asking for support, then object to "second-class" publically. It's already starting...
Lots of code has had secondary repositories for special features in the past. Is Scheme so poor that it has no where else to go?
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@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.
* Taylor Campbell [2005-09-17 04:47+0200] writes:
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.)
I for one, am not interested in "general Lisp interaction". Emacs is the only front-end I want to use anyway. I'm however interested in interaction of Emacs with external (possibly non-lisp) interpreters/debuggers. Most of the talk about using SLIME for other things I have heard has not been more than that: talk. And I think it would be a bit silly to provide for reuse and extension if there's no actual application which uses it.
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?
It's pretty common to write things like
(defun foo (package buffer) (with-current-buffer buffer (frob package)))
and this might not do what you think it does when package is a buffer-local variable. Symbols like `package', `module', `buffer', `string', `list' are problematic names for buffer-local variables. Let's reserve them for ordinary local variables.
Still interested?
Maybe.
Would you please make up your mind, Sir? Yes or no?
Date: Sat, 17 Sep 2005 12:18:37 +0200 From: Helmut Eller heller@common-lisp.net
* Taylor Campbell [2005-09-17 04:47+0200] writes:
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.)
I for one, am not interested in "general Lisp interaction". Emacs is the only front-end I want to use anyway. I'm however interested in interaction of Emacs with external (possibly non-lisp) interpreters/debuggers. Most of the talk about using SLIME for other things I have heard has not been more than that: talk. And I think it would be a bit silly to provide for reuse and extension if there's no actual application which uses it.
Actually, there has been a bit of real code written for the McCLIM tools that uses Swank. I don't know many details about it, though.
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?
It's pretty common to write things like
(defun foo (package buffer) (with-current-buffer buffer (frob package)))
and this might not do what you think it does when package is a buffer-local variable. Symbols like `package', `module', `buffer', `string', `list' are problematic names for buffer-local variables. Let's reserve them for ordinary local variables.
That makes sense. Would it be OK if the lines were changed to something like -*- mode: scheme; scheme48-package: ... -*-? (The package local variable is very useful in Scheme48 development -- in the absence of IN-PACKAGE forms, which are nonsensical with Scheme48's module system, the information provided greatly speeds development.)
Still interested?
Maybe.
Would you please make up your mind, Sir? Yes or no?
I'm still interested. I'll maintain a separate Darcs repository just in case, though, it should ever become apparent that migration away from SLIME's source control be necessary.
* Taylor Campbell [2005-09-17 19:45+0200] writes:
That makes sense. Would it be OK if the lines were changed to something like -*- mode: scheme; scheme48-package: ... -*-? (The package local variable is very useful in Scheme48 development -- in the absence of IN-PACKAGE forms, which are nonsensical with Scheme48's module system, the information provided greatly speeds development.)
Done so.
I'm still interested. I'll maintain a separate Darcs repository just in case, though, it should ever become apparent that migration away from SLIME's source control be necessary.
OK, everything is now in CVS.
Helmut.
Helmut Eller writes:
- Taylor Campbell [2005-09-17 04:47+0200] writes:
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.)
I for one, am not interested in "general Lisp interaction". Emacs is the only front-end I want to use anyway. I'm however interested in interaction of Emacs with external (possibly non-lisp) interpreters/debuggers. Most of the talk about using SLIME for other things I have heard has not been more than that: talk. And I think it would be a bit silly to provide for reuse and extension if there's no actual application which uses it.
I have both an Ltk debugger and an Ltk Smalltalk-style-browser that use swank. They use swank not just for portability, but also to be add-on tools to slime (eg, it's no fun when you're looking at an Ltk window, and a debugger pops up in an emacs somewhere -- and at the same time, I want to be able to use SLIME for 95% of my Lisp interaction). Before releasing them, I'll have to clear them past my own personal QA (they shouldn't be patches against 4-month old releases), and clear them by my employer ... but, I can certainly vouch for other tools existing atop swank.
I like the slime/swank assumption that everything is ANSI and AMOP compliant as far as makes sense. And it definately makes my life easier as a swank-frontend implementor.
-
Alan Ruttenberg -
Andras Simon -
Brian Mastenbrook -
Edi Weitz -
GP lisper -
Helmut Eller -
Ivan Boldyrev -
Julian Stecklina -
Luke Gorrie -
Taylor Campbell -
Taylor Campbell -
Thomas F. Burdick