GCL: make error
Neil Zanella
Hello,
I am somewhat new to LISP.
I have just downloaded GNU Common Lisp 2.4.0 on a PIII running Red Hat
Linux 7.1 and came across the following make error after doing a configure
and a make:
make[1]: Entering directory `/tmp/gcl-2.4.0/unixport'
cc -c -I../h -c -o ../mp/mpi.o ../mp/mpi.c
cc -c -I../h -c -o ../mp/mp2.o ../mp/mp2.c
make[1]: *** No rule to make target `../mp/libmport.a', needed by
`raw_gcl'. Stop.
make[1]: Leaving directory `/tmp/gcl-2.4.0/unixport'
make: *** [all] Error 2
Apparently GCL is the new name for the Austin Kyoto Common Lisp (AKCL)
which in turn is derived from the Kyoto Common Lisp (KCL). There seem
to be other GNU implementations of ANSI Common Lisp such as GNU CLISP.
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
clisp.sourceforge.net. There are other GNU versions of
LISP as well such as ILISP, CLX, and maybe more.
There seem to be other freely available versions
of LISP as well. The CLISP package compiled fine
on my system (clisp 2.27). Besides this I am
somewhat surprised that there are so many
different versions of lisp out there.
After all I didn't think LISP was
that popular. But it has been
around for a long time.
Which implementation of ANSI Common LISP would you recommend?
Thanks,
Neil
Peter Wood
> Hello,
>
> I am somewhat new to LISP.
> I have just downloaded GNU Common Lisp 2.4.0 on a PIII running Red Hat
> Linux 7.1 and came across the following make error after doing a configure
> and a make:
>
> make[1]: Entering directory `/tmp/gcl-2.4.0/unixport'
> cc -c -I../h -c -o ../mp/mpi.o ../mp/mpi.c
> cc -c -I../h -c -o ../mp/mp2.o ../mp/mp2.c
> make[1]: *** No rule to make target `../mp/libmport.a', needed by
> `raw_gcl'. Stop.
> make[1]: Leaving directory `/tmp/gcl-2.4.0/unixport'
> make: *** [all] Error 2
>
> Apparently GCL is the new name for the Austin Kyoto Common Lisp (AKCL)
> which in turn is derived from the Kyoto Common Lisp (KCL).
GNU is looking for a new maintainer for GCL and MAXIMA, as William
Schelter recently passed away.
> There seem
> to be other GNU implementations of ANSI Common Lisp such as GNU CLISP.
> 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
> clisp.sourceforge.net. There are other GNU versions of
> LISP as well such as ILISP, CLX, and maybe more.
ILISP is an Emacs package which provides a convenient interface to
many Lisp and Scheme implementations. It's not itself a Lisp. CLX
provides Lisp access to X, so you can do gui programming with Lisp,
but it's quite low-level.
> There seem to be other freely available versions
> of LISP as well. The CLISP package compiled fine
> on my system (clisp 2.27). Besides this I am
> somewhat surprised that there are so many
> different versions of lisp out there.
> After all I didn't think LISP was
> that popular. But it has been
> around for a long time.
>
> Which implementation of ANSI Common LISP would you recommend?
>
I recommend Clisp. It's mostly ANSI compliant. It's GPL'd so you get
full access to the sources, and can modify them to suit yourself. You
can run it conveniently on a console or xterm, since it uses the GNU
Readline library. It's fast, compared to Python, light, and responsive.
Very few functions have documentation strings, but it provides a
convenient interface to accessing the Hyperspec, which is the
definitive reference for Common Lisp.
Regards,
Peter
Neil Zanella
> 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
Tim Moore
> > 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
Thomas F. Burdick
> 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.
Daniel Barlow
> 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
Kent M Pitman
> 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.)