> Note: GCL is *not* (and doesn't even attempt to be) a compliant Common
> Lisp implementation (i.e., compliant to the ANSI standard; it's a
> CLtL1 Lisp (an obsolete pre-ANSI standard)).
Fair enough. I guess there is no point in using an implementation which
is not standard. I would expect a standard implementation to be somewhat
more portable and perhaps even better in some respects. Are there any
particular weaknesses in the ANSI standard which would make it worth
sticking to pre-ANSI lisp or is the ANSI standard an improvement
in all respects?
> > There is a README file for GNU CLIPS on ftp.gnu.org but strangely the
> > sources do not appear there and must be downloaded from
>
> AFAIK, CLISP is not a GNU thing (it's released under the GNU General
> Public Licence, but that's not at all the same thing), so it's not too
> strange. [Though I see they're calling it "GNU CLISP" lately, so
> maybe it is now...]
Perhaps the good parts of GCL can be merged into CLISP and all development
efforts can be consolidated in one place. Right now I don't see much point
in having two separate implementations of LISP. Are there many differences
between GCL and CLISP?
> ILISP is an Emacs extension for interfacing to many different Lisp
> (and some Scheme) implementations; it's not a Lisp implementation
> itself. Neither is CLX, which is a Lisp interface to X Window System
> protocol. Neither of them have anything to do with GNU.
>
> > Which implementation of ANSI Common LISP would you recommend?
>
> Undoubtedly the best implementation (once you get past some recent
> weirdness; i.e., "modern mode") is Allegro CL from Franz, Inc. (which
> is commercial)
What does Allegro have that CLISP does not have?
> The best _compiler_ is Python, the compiler in CMU Common Lisp (which
> is public domain), which is a very good implementation all around, but
> has some minor ANSI compliance issues and other minor problems.
Besides the fact that python is compiled and not interpreted, is the
syntax and semantics of the language close enough to ANSI LISP?
What are the differences? Should I be learning Python instead,
given that AFAIK Python is more popular than LISP?
> CLISP is also a reasonably good free Lisp (not as standard as CMUCL,
> but it's getting better; not very long ago it was variously broken --
> I think it still defaults to a non-ANSI mode, though)
>
> If you care about writing GUIs, etc., the best choice is probably
> Xanalys LispWorks.
>
> Overall, CMUCL is my pick.
Thanks for your feedback (so much to choose from!!!)
Have a nice day,
Neil
Neil Zanella <········@garfield.cs.mun.ca> writes:
> Perhaps the good parts of GCL can be merged into CLISP and all development
> efforts can be consolidated in one place. Right now I don't see much point
> in having two separate implementations of LISP. Are there many differences
> between GCL and CLISP?
Actually, there are 5 free implementations of Common Lisp:
* CMUCL - compiles directly to native code, tries to be feature rich
* SBCL - a fork off of CMUCL, tries to be more ANSI compliant and
easier to port to new architectures
* CLISP - compiles to bytecodes, which it interprets. It's very portable.
* GCL - Derived from Kyoto CL, it's a CLtL1 Lisp. It compiles to C,
then uses the system C compiler to produce native code. This
makes for less optimal assembly output, but it's easier to
port. This implementation is the native home for MAXIMA, an
algebra system.
* ECLS - Also derived from Kyoto CL, it is able to be used as an
extension language from C (it makes C<-->Lisp calling easy),
and is moving to become ANSI compliant.
So, yes, there are (very) many differences between CLISP and GCL, to
the extent that merging them wouldn't make sense. There are also good
reasons for each of these Lisps to exist, as they all have quite
different goals.
On Sun, 16 Sep 2001, Neil Zanella wrote:
> > The best _compiler_ is Python, the compiler in CMU Common Lisp (which
> > is public domain), which is a very good implementation all around, but
> > has some minor ANSI compliance issues and other minor problems.
>
> Besides the fact that python is compiled and not interpreted, is the
> syntax and semantics of the language close enough to ANSI LISP?
> What are the differences? Should I be learning Python instead,
> given that AFAIK Python is more popular than LISP?
>
I think you're a bit confused; not too surprising, given the confusing
names. The CMU *Common Lisp* compiler is called Python, but the name
predates the scripting language Python and has nothing at all to do with
it.
No, you should be learning Lisp, not Python :)
Tim
Neil Zanella <········@garfield.cs.mun.ca> writes:
> Fair enough. I guess there is no point in using an implementation which
> is not standard. I would expect a standard implementation to be somewhat
> more portable and perhaps even better in some respects. Are there any
> particular weaknesses in the ANSI standard which would make it worth
> sticking to pre-ANSI lisp or is the ANSI standard an improvement
> in all respects?
I don't think there's anything in GCL that makes it more useful than
an ANSI-conforming implementation would be. Conversely, I expect
there's a fair amount in ANSI that's not in GCL. Also by using an
implementation that "purports to conform" (standards-speak for "makes
best efforts to conform, and considers non-compliances to be bugs")
you stand a much better chance of your code and experience being
portable to other implementations, and of being able to draw on the
wider expertise in the CL community.
> Perhaps the good parts of GCL can be merged into CLISP and all development
> efforts can be consolidated in one place. Right now I don't see much point
> in having two separate implementations of LISP. Are there many differences
> between GCL and CLISP?
I don't believe there's a lot of development effort going into GCL
right now anyway (please, if anyone knows different, correct me) so I
don't think that would make a great deal of difference ...
> What does Allegro have that CLISP does not have?
Depends which package you pay for, but in general a native compiler
(as opposed to CLISP, which is byte-compiled) and a whole slew of
other stuff. And commercial support, which by all accounts is very
good. You can download a no-cost evaluation version from the Franz
web site.
> > The best _compiler_ is Python, the compiler in CMU Common Lisp (which
> > is public domain), which is a very good implementation all around, but
> > has some minor ANSI compliance issues and other minor problems.
>
> Besides the fact that python is compiled and not interpreted, is the
> syntax and semantics of the language close enough to ANSI LISP?
> What are the differences? Should I be learning Python instead,
> given that AFAIK Python is more popular than LISP?
OK, this is a common point of confusion. The compiler which forms
part of CMUCL (and SBCL) is called Python. It's a Common Lisp
compiler, it's nothing to do with the Python language, and it's had
that name since before the Python language was created. CMUCL is free
(mostly Public Domain, some components have MIT-style licenses) and
well worth investigating if it runs on whatever platform you're using.
Ditto SBCL, for that matter.
You might want to look at
http://ww.telent.net/cliki/Common%20Lisp%20implementation
if you haven't already.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Neil Zanella <········@garfield.cs.mun.ca> writes:
> Fair enough. I guess there is no point in using an implementation which
> is not standard. I would expect a standard implementation to be somewhat
> more portable and perhaps even better in some respects. Are there any
> particular weaknesses in the ANSI standard which would make it worth
> sticking to pre-ANSI lisp or is the ANSI standard an improvement
> in all respects?
In all respects? Hmm. That's a tall order there.
I think there was a lot of fussing about whether it was worth it for
those vendors who'd gone to CLTL2 as a stopgap measure to bother
abandoning it for incompatible changes needed to unify the community
under ANSI CL. In the end, I think the community spoke clearly and
everyone is happy that vendors made the shift to ANSI.
There was some minor loss of functionality between CLTL2 and ANSI CL, if
you think that matters, though as I've commented on extensively before
(search the news archives for posts by me containing the word 'CLTL2'),
CLTL2 was not a committee product and was never intended to be implemented.
CLTL2 had some ideas in it that never made it to the standard. Some
because they were buggy. Some because they were reports of competing
ideas that never got into the standard, but that Steele just happened to
like. (And, in fairness, many others did, too.) Most vendors who had
implemented any of that stuff still have it available but as an extension.
But the question of CLTL (which WAS a committee product, just not an
ANSI committee) to ANSI CL transition seems, at least in my opinion,
to have been a fairly bloodless war. I don't recall any major
controversy at all other than those who didn't initially trust CLOS
(which has proven itself with time, I think) and thought perhaps it
should be optional, or didn't trust the condition system (which again
has proven itself) and thought it should be optional, or who didn't
want some of the other things like the pretty printer (because it was
work to implement or added space to images) or the extended LOOP
facility (about which some have religious feelings). But all in all,
we didn't make any blunders that I'm aware of such that the mere
implementing of the requirements of ANSI CL would make things bad;
that is, any problems we might have created are "ignorable" and will
not interefere with anything that was present in CLTL.
With the possible singular exception that we made the language bigger.
If you don't think languages should ever get bigger, then there is a
problem, but that problem stands regardless because we did make it bigger.
Then again, we didn't require you to have the extra stuff pre-loaded, so
that doesn't mean an implementation has to be bigger. Further, nothing
forbids you from claiming conformance to a subset if you really want to.
But all in all, I see no technical reason not to upgrade to full ANSI CL.
If anyone knows an actual design error that we made such that the semantics
of the ANSI CL spec actually break something in CLTL in a way that is
painful to cope with, I'd be curious to know.
There are some technical incompatibilities between CLTL and ANSI CL, such as
the incompatible changing of some method signatures, the incompatible changing
of the definition of FUNCTIONP, the renaming of some operators like
SPECIAL-FORM-P and GET-SETF-METHOD, etc. But other than the mere
nuissance value of making the change, I've heard no serious assertions
that those were bad design decisions.
Probably the biggest problem I've heard of is that the elimination of
COMPILER-LET, which does make for some problems in one or two systems.
I suspect some implementations continue to support COMPILER-LET, just in
another package. (That may be a slightly non-standard act, but I suspect
it's the sort of thing most reasonable people can cope with.)
(I'd be curious to hear if anyone substantially disagrees with the
above analysis.)