Bill Clementson bill_clementson@yahoo.com writes:

I found this comment curious as I thought that you used only a TCP socket to communicate between emacs and cl. I had a look at the source and you do require inferior lisp mode (ILM) and comint mode. What is the rationale for using both inferior lisp mode and a TCP socket? Is your intention to entirely replace ILM with socket communication or will you continue to use ILM for some things and sockets for others?

"Require" may be a bit of a strong word: it is possible to run SLIME with only the TCP connection (e.g. to a lisp on another machine) but you need to (swank:create-swank-server) on the CL by hand before running slime-connect.

That said, yes, if you run the default M-x slime it does use inferior-lisp to start up a lisp implementation. I think the plan is to make inferior-lisp largely unnecessary, but in the meantime for purposes of hacking slime itself it's damned handy to have an alternate route into Lisp when things get wedged.

(There's also the problem that although we can redirect all 'normal' lisp output, we don't currently trap anything in the lisp that bypasses the streams layer (e.g. foreign code printing to file descriptors) so that winds up in *inferior-lisp* as well. I'm sure we can solve this some other way, but thus far we haven't)

-dan

Bill Clementson bill_clementson@yahoo.com writes:

Thanks for the clarification. Incidentally, what was the rationale for using inferior lisp mode instead of ilisp to "boot-strap" development? ILISP has some of the same "negatives" as ILM (since both were built on comint mode) however it has a lot more functionality than ILM. It seems like (at least to me) it would have made more sense creating SLIME extensions on top of ILISP rather than ILM since there is so much more functionality in ILISP than there is in ILM. Even if the eventual goal is to replace all the functionality that is provided by ILM/ILISP, ILISP would provide more "short-term" benefits for the SLIME CL developer than ILM would.

I think the reason is that Eric Marsden, the author of SLIME's initial version (at that time called SLIM) uses inf-lisp and not ILISP. I don't know what Luke used before SLIME, but I too used inf-lisp.

SLIME is now good enough for developing SLIME and at this stage it simpler to add any missing functionality to SLIME itself than to make it work with ILISP. The advantage of inf-lisp over ILISP is that inf-lisp is simpler and more robust. Since we use inf-lisp primarily as fallback when everything else fails, inf-lisp seems to be preferable.

Helmut.

Bill Clementson bill_clementson@yahoo.com writes:

Fair enough. But, could you elaborate on where you feel inf-lisp is more robust than ILISP? I know that there were a lot of quality issues a while ago; however, I believe that most of those have been addressed in the last couple of releases. I would have thought that ILISP today would be no less robust than inf-lisp.

I haven't used ILISP for some time and things may have changed in the meantime, but I think ILISP needs a way to detect the prompt of the Lisp to work properly. I think ILISP hangs or breaks if the prompt regexp is not set correctly. AFAIK inf-lisp also uses a such a regexp, but doesn't break if the regexp is wrong. So in this sense inf-lisp is more robust.

Helmut.

Bill Clementson bill_clementson@yahoo.com writes:

Even if the eventual goal is to replace all the functionality that is provided by ILM/ILISP, ILISP would provide more "short-term" benefits for the SLIME CL developer than ILM would.

That would have been one way, but we went the clean-room approach. We only use ILM to start Lisp and compile our server, and *inferior-lisp* as a debugging fallback. We've covered all the major features now, although there's plenty of hacking left to do to get all the details right and support everyone's favourite add-ons.

Starting from scratch means more work/fun, but it also gives us a fresh codebase. To an outsider, some of the code in ILISP is slightly terrifying :-), as in any program with such a long history. We also wanted to do most things differently and to have an environment more like the elisp one, so it would only give us a head-start in the short-term.

ELI really doesn't appeal to my hackstincts. From the web I can't even tell who wrote it, and most questions on groups.google.com seem to go without definitive answers. I downloaded my copy from Neil van Dyke's website, which says "Please do not pester Franz to support this packaging, lest they regret GPL'ing."

It looks like Franz did the least necessary to be allowed to link with Emacs under the GPL, and would be unlikely to let a dozen random hackers into their CVS tree :-) so that is a potential dead-end.

So I think our approach is pretty reasonable. We'll see how it goes. I'm even hoping we can tempt some of you fine hackers to have a play around on the dark side ;-)

And of course my views do not necessarily reflect those of the other SLIME hackers, but I hope this answers this thread's main question. Note however that this is almost entirely after-the-fact rationalization. Really, it was just too addictive to stop. ;-)

Cheers, Luke