CLISP, CMUCL, SBCL, does it matter which one I use?
Are they all essentially the same considering they're all
implementation of common list?
What other open source implementations of list I may have missed here
that are worth looking at?
············@gmail.com wrote:
> CLISP, CMUCL, SBCL, does it matter which one I use?
>
> Are they all essentially the same considering they're all
> implementation of common list?
>
> What other open source implementations of list I may have missed here
> that are worth looking at?
Nevermind, I found this page
http://www.cliki.net/Common%20Lisp%20implementation
Please let us know which one you choose, and why. I oscilating myself
between CMUCL and SBCL.
BTW, could somebody share opinion, idealy based on actual use, about
the relative merits of these two? I tend to think that CMUCL is more
robust. It's just an impression, these fine folks chose it
(http://www.itasoftware.com) and they could have chosen anything. And
these too http://reddit.com, and I'm guessing they had Paul Graham's
advise.
Jaime
jbar wrote:
> Please let us know which one you choose, and why. I oscilating myself
> between CMUCL and SBCL.
>
I'm a newbie, so my opinion may not matter much. But I got the gnu
clisp because it comes with cygwin and being a gnu project I suspected
it'll be there when I transition to linux, and I also got LispBox for
windows which has a common lisp implementation though not sure which.
I don't know why gnu clisp doesn't seem get as much mention as CMUCL
and SBCL. Would any please inform me?
> BTW, could somebody share opinion, idealy based on actual use, about
> the relative merits of these two? I tend to think that CMUCL is more
> robust. It's just an impression, these fine folks chose it
> (http://www.itasoftware.com) and they could have chosen anything. And
> these too http://reddit.com, and I'm guessing they had Paul Graham's
> advise.
>
> Jaime
············@gmail.com writes:
> jbar wrote:
>> Please let us know which one you choose, and why. I oscilating myself
>> between CMUCL and SBCL.
>
> I'm a newbie, so my opinion may not matter much. But I got the gnu
> clisp because it comes with cygwin and being a gnu project I suspected
> it'll be there when I transition to linux, and I also got LispBox for
> windows which has a common lisp implementation though not sure which.
>
> I don't know why gnu clisp doesn't seem get as much mention as CMUCL
> and SBCL. Would any please inform me?
I think there are two reasons:
1- it's developed mainly by Europeans.
2- it compiles to bytecode executed by a virtual machine, therefore
people think it's slow. (It is not as slow as they think, given
the speed differential of current processors vs. RAM).
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal Bourguignon <····@mouse-potato.com> writes:
> ············@gmail.com writes:
>
> > I don't know why gnu clisp doesn't seem get as much mention as CMUCL
> > and SBCL. Would any please inform me?
>
> I think there are two reasons:
>
> 1- it's developed mainly by Europeans.
This is supposed to be a contrast with SBCL?!?!
> 2- it compiles to bytecode executed by a virtual machine, therefore
> people think it's slow. (It is not as slow as they think, given
> the speed differential of current processors vs. RAM).
This is the real reason. Along with 3 and 4:
3. It historically had a crippled object system, and gratuitous ANSI
non-compliance. As far as I can tell, this is now completely
historical: CLISP is now essentially ANSI compliant and conformant
with the AMOP, and its maintainers consider non-compliance to be
bugs.
4. It's GPL'd. It's not as bad as it sounds ... but still, ouch.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
"jbar" <·········@gmail.com> writes:
> Please let us know which one you choose, and why. I oscilating myself
> between CMUCL and SBCL.
>
> BTW, could somebody share opinion, idealy based on actual use, about
> the relative merits of these two? I tend to think that CMUCL is more
> robust. It's just an impression, these fine folks chose it
> (http://www.itasoftware.com) and they could have chosen anything. And
> these too http://reddit.com, and I'm guessing they had Paul Graham's
> advise.
It probably doesn't matter. If you think there's any chance you'll
want to hack on the implementation yourself, or rebuild it yourself,
run, don't walk to SBCL. CMUCL has more backwards-compatability over
a longer timespan; SBCL is more actively developed now. SBCL comes in
8-bit-character and Unicode variants; CMUCL ships with an Emacs-like
editor, and systems for using remote objects, rpc, and a slave lisp
eval-server. SBCL has more thorough POSIX bindings, and native
threads (on Linux/x86); CMUCL has Motif bindings and userland threads
(on x86). Like I said, it probably doesn't matter, at least at the
moment, not the least since porting between the two is usually really
easy.
That said, I use and hack on SBCL.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> It probably doesn't matter. If you think there's any chance you'll
> want to hack on the implementation yourself, or rebuild it yourself,
> run, don't walk to SBCL.
Rebuilding CMUCL is easy and I do it all the time. Re-compiles, cross
compiles, whatever. When I had to pick a Lisp for a project that
required making changes to internals I started with SBCL, naively
believing all of the hype that CMUCL was so difficult to rebuild.
After skimming the directions and actually trying it, I discovered
that there was really nothing difficult about rebuilding CMUCL. I
have been using it ever since.
From: Christophe Rhodes
Subject: Re: CLISP, CMUCL, SBCL, does it matter?
Date:
Message-ID: <sq3blu14or.fsf@cam.ac.uk>
Carl Shapiro <········@panix.com> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>> It probably doesn't matter. If you think there's any chance you'll
>> want to hack on the implementation yourself, or rebuild it yourself,
>> run, don't walk to SBCL.
>
> Rebuilding CMUCL is easy and I do it all the time. Re-compiles, cross
> compiles, whatever. When I had to pick a Lisp for a project that
> required making changes to internals I started with SBCL, naively
> believing all of the hype that CMUCL was so difficult to rebuild.
There are internals and there are internals. For instance,
"internals" viewed from one perspective might be changing the
Operating System interface, for instance to assist in a hypothetical
port to a non-Unix OS. This is likely to cause approximately equal
difficulties in rebuilding in both platforms: once you have source
code which works, there is likely to be nothing particularly special,
and following the respective instructions will work.
Another view of the internals might be low-level details such as the
tagging scheme; it's possible to renumber tags for microefficiency in
typechecking, by arranging for common combinations of low-level types
(STRING, ARRAY, NUMBER and so on) to have contiguous ranges of type
tags or else tags which differ only in a small number of bits, so that
only one mask and compare, rather than a number of compares, is
needed. To compile this, the same build procedure in SBCL simply
works; for CMUCL, a moment's thought (perhaps not much more than a
moment) will tell you that you need to cross-compile even if you're
compiling for the same architecture; a "regular" compile will fail
because the new type tests are wrong for the old tags, and vice versa.
To emphasize, in the case above, the regular compile will fail even if
the sources are completely correct and consistent, when building from
an older version. A regular compile from the newly-built CMUCL will
of course work fine, but this dependency on the identity of the host
compiler is an additional source of complexity: manageable, but I hope
that it's clear that there is an issue there.
But there's a third kind of "internals" which causes more pain than
the above, and that is that caused by the punning that CMUCL performs
even in a cross-compile. This has caused the CMUCL sources to have
odd remnants, such as an unrenamable KERNEL::CLASS structure distinct
from CL:CLASS; it also limits maintenance actions such as reordering
slots in fundamental structures such as defstruct-description. These
things are of course solvable given sufficient effort using bootstrap
files or their equivalent, but they are there, and CMUCL maintainers
in the past have failed to solve them.
Relatedly, there is the issue that portions of the host compiler can
"leak" into the target; again, this can cause maintenance problems,
such as finding where exactly a bug was introduced and ensuring that
it is fixed. (This is not hypothetical: as Carl undoubtedly knows,
current maintainers of CMUCL are having to re-bootstrap from ancient
versions to see if the current source contains a bug or not, as
described in mail messages to the CMUCL development mailing list.)
> After skimming the directions and actually trying it, I discovered
> that there was really nothing difficult about rebuilding CMUCL. I
> have been using it ever since.
I don't dispute that you are happy with rebuilding CMUCL, but "nothing
difficult"?
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> I don't dispute that you are happy with rebuilding CMUCL, but "nothing
> difficult"?
Yes, that's what I said. I'm sorry you find the rebuild process for
CMUCL to be so contemptuous, but truth be told it has never been an
impediment to making changes I needed, including those in your "more
pain than the above" class. I think your enumeration of grievances
was at times sensational, but since they are essential to the creation
myth of certain CMUCL spin-off, I see no value in trying to convince
you otherwise.
On Thu, 17 Nov 2005 15:49:07 -0500, Carl Shapiro wrote:
Hey dude.
Sometime last Spring you said that CMUCL for Windows was almost done
but that you were organising a conference and were to busy to finish.
So what's up now?
I usually oscillate between SBCL and CMUCL.
I do lots of large-scale numerial floating-point computations. For
this, CMUCL seems to produce faster code than SBCL. On the other
hand, SBCL has native level threads, which is sometimes very useful.
rif