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, -- Julian Stecklina (Of course SML does have its weaknesses, but by comparison, a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god.) -- Thant Tessman

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.)

* 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 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/

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.)

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'.

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 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?:))

...

...

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

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 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 [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.

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.

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)

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.

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.

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.

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. -- /|_ .-----------------------. ,' .\ / | Free Mumia Abu-Jamal! | ,--' _,' | Abolish the racist | / / | death penalty! | ( -. | `-----------------------' | ) | (`-. '--.) `. )----'