Hi Luke,
I've been following "SLIME" with some interest.
Historically, the three main Emacs modes that people have used for CL development were Inferior Lisp Mode (ILM), ILISP and ELI (developed by Franz). ILM & ILISP worked with most CL implementations but were constrained by having been built on top of comint mode (This sometimes results in lock-ups. Also, since comint mode has a single line of communication between Emacs and the CL implementation, it is not possible to take advantage of multiprocessing if the CL implementation supports MP). ELI doesn't have the comint heritage of ILM and ILISP. It (like SLIME) uses a TCP socket to talk to CL and you can have multiple threads of communication open to the CL implementation. Although ELI was developed by Franz, it was released under the GPL and some people have done some work towards porting it to CMUCL and SBCL. I think that the approach taken by ELI and SLIME is the preferable approach; however, ILISP and ILM are both widely used simply because they are the only option available with many CL implementations (for people who want to use Emacs) .
I think there are a number of different possible scenarios that might develop:
1. Status quo: ILM, ILISP, ELI and SLIME all coexist. Having multiple Emacs CL modes is in some ways a benefit as it gives people choice; however, it also means that multiple people are all working on divergent efforts to achieve a similar result. 2. Effort is put into creating more complete LEP implementations for different CL's so that ELI can be used effectively on multiple CL implementations. The benefit of this option is that ELI is very full-featured as it is and just the port of the underlying communication layer would need to be done. Also, since the largest commercial CL vendor supports ELI and actively enhances it, we can take advantage of both commercial and open source development efforts. 3. Flesh out SLIME with the functionality that is available today in ILISP and ELI. This is the "clean slate" option. It would allow for a new Emacs CL mode to be developed utilizing the best ideas from ILISP & ELI. It also requires the greatest amount of effort. 4. Integrate SLIME and ILISP. This would add multiprocessing support to ILISP and would allow SLIME to take advantage of the rich functionality already built into ILISP. Perhaps comint mode support could be retained and the SLIME TCP socket communication protocol is provided as just another option (not all CL's support multiprocessing and ILISP also supports a lot of Scheme implementations that don't support multiprocessing so not everyone would benefit from ILISP moving away from comint mode). This might be a win-win option. It might also be a "Frankenstein" approach that could hurt both.
I would be interested in hearing what others think about these different scenarios. In all probability, scenario #1 will prevail; however, I would like to hear what others think about the different options (as well as options that I haven't thought of).
Bill Clementson
"Luke Gorrie" luke@bluetail.com To: ilisp-devel@lists.sourceforge.net Sent by: cc: slime-devel@common-lisp.net ilisp-devel-admin@lists.sour Subject: [Ilisp-devel] SLIME ceforge.net
11/26/2003 05:55 PM
G'day ILISP hackers,
I should've written earlier to introduce our project called "SLIME" to you guys. It's similar to ILISP, the main differences are that we use a TCP socket to talk to Lisp and we generally try to imitate the Emacs Lisp programming interface.
It started out a few months ago as a hack by Eric Marsden for highlighting CMUCL's compiler warnings in Emacs buffers, but other people started playing with it and now it's snowballed. The main page is on Cliki at http://www.cliki.net/SLIME if you want to know more.
I'm not sure how all this relates to ILISP exactly, but I just wanted to shoot you a note to say hello and invite you to play around with it!
Cheers, Luke
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Ilisp-devel mailing list Ilisp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ilisp-devel
Bill_Clementson@peoplesoft.com writes:
I would be interested in hearing what others think about these different scenarios. In all probability, scenario #1 will prevail; however, I would like to hear what others think about the different options (as well as options that I haven't thought of).
One question: is the license status of ILISP now completely clear? If not, there might be an advantage from building things anew as SLIME does.
I would have preferred the option of LEP being supported by the free Lisp implementations (CMUCL, SBCL, CLISP, GCL). Is LEP too complicated or otherwise bad, so that SLIME became necessary?
Nicolas.
Nicolas Neuss Nicolas.Neuss@iwr.uni-heidelberg.de writes:
I would have preferred the option of LEP being supported by the free Lisp implementations (CMUCL, SBCL, CLISP, GCL).
David Lichteblau is working on this for SBCL. He shares code with SLIME, since Dan is factoring all the SBCL-deep-magic code into the SB-INTROSPECT library that we both use.
His LEP-for-SBCL is at http://www.lichteblau.com/src.html
Is LEP too complicated or otherwise bad, so that SLIME became necessary?
Absolutely not.
Bill_Clementson@peoplesoft.com writes:
- Flesh out SLIME with the functionality that is available today in ILISP
and ELI. This is the "clean slate" option. It would allow for a new Emacs CL mode to be developed utilizing the best ideas from ILISP & ELI. It also requires the greatest amount of effort.
s/effort/fun/ :-)
This is firmly the path we've taken, except that we're primarily stealing ideas from Emacs Lisp's development environment.
- Integrate SLIME and ILISP. This would add multiprocessing support to
ILISP and would allow SLIME to take advantage of the rich functionality already built into ILISP.
As Dan mentioned, we don't do any multiprocessing yet, though we hope our infrastructure will permit it with minimal rewriting.
If you guys are interested in using TCP for your connection, the socket code is pretty easy. I don't think merging with SLIME would be a practical way to do it though.
BTW, the interesting aspect of SLIME is the depth of our Emacs/Lisp integration. For example, we have rewritten parts of the Common Lisp top-level and debugger in Elisp, and made Emacs understand Lisp compiler messages very well. The socket stuff is just a boring implementation detail.
Cheers, Luke
On Nov 27, 2003, at 1:31 AM, Bill_Clementson@peoplesoft.com wrote:
- Effort is put into creating more complete LEP implementations for
different CL's so that ELI can be used effectively on multiple CL implementations. The benefit of this option is that ELI is very full-featured as it is and just the port of the underlying communication layer would need to be done. Also, since the largest commercial CL vendor supports ELI and actively enhances it, we can take advantage of both commercial and open source development efforts.
As far as I understand it, LEP won't work on non-threaded lisps, which means there will always be room for a solution that doesn't require threading. Of course taking advantage of it where present is great, but right now SBCL lacks threads on anything but x86. If you want to help out, I'm sure that we'd take any code patches towards getting gencgc working on PowerPC - it's not a trivial matter though, and in the meantime I enjoy having a development environment that works on SBCL/OS X.
-- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
-
Bill_Clementsonï¼ peoplesoft.com -
Brian Mastenbrook -
Luke Gorrie -
Nicolas Neuss