Re: ECL 0.9j-p1
- From: Rainer Joswig <joswig@xxxxxxx>
- Date: Wed, 02 Jan 2008 12:13:58 +0100
Scott Burson <FSet.SLB@xxxxxxxxx> wrote:
I think ECL is an important implementation that deserves more
attention from the community. Here's why.
It is kind of interesting to see that ECL is actively maintained
and has releases (that latest just a few days ago).
It must be useful for some people. It is also a good
sign that the key maintainer is still working on it
after all those years.
CLISP might seem to be the top remaining contender. It is actively
maintained, portable, and stable. There are some questions about its
compatibility -- I noticed someone in another thread complaining about
its treatment of pathnames, and ANSI mode is not the default -- but
these issues may not be fatal. The big problem I have with CLISP is
the license: modified GPL. The modification attempts to make it
possible for commercial entities to sell software built on CLISP, but
I am not sure that it succeeds, and I am also not sure that Haible et
al. have the right to offer the modification in the first place given
that CLISP includes the GNU readline library. While all this can be
debated, I think there is enough uncertainty here to make a corporate
Sure you can sell even GPL software. You have to open up the source code
for that, though. There is nothing in the GPL that says you
can't sell GPL software. The various extensions to the GPL
relax the requirements a bit (what is part of 'the program'
and what not - this is where Lisp is a bit special).
GCL hasn't released an update in over two years, and has a reputation
for not quite being ANSI compatible.
There is a branch that is more ANSI compatible. But for many
purposes this is just a 'non-issue'. If you have to
write a program to solve a problem or provide a service,
then 'near 100% compatibility' of the Common Lisp implementation
would be low on my list of requirements. The most important
requirement would be that the Common Lisp implementation
enables me to write and run that program. The created value
comes from the running program, not from 'ANSI CL compatibility'.
I would see that it has most of CL capabilities, but for example
if the implementation would not offer CLOS (just an example)
and my program would not require CLOS, then I would not care
about that. If ten functions have a different signature or
have some different corner cases, I would also not care.
I see it like this: you can write useful Common Lisp programs with
GCL and people have done that.
True: I would also prefer an implementation to have regular releases.
That's what open source projects like SBCL and CMUCL get right.
SLIME (an important 'library' for many) for example fails here.
GCL fails here, too.
That leaves ECL. It's LGPL, can build both standalone executables and
libraries, has very good portability (caveat: it depends on the Boehm
GC), seems pretty stable, seems close enough to ANSI, and as a bonus,
has multithreading on "most platforms". Not sure about the debugger.
A debugger is very important, unless you develop with some other
environment and deliver with ECL.
All this said, I haven't tried to do much with ECL yet -- I haven't
had the time to do much of anything with Lisp in the last few months,
alas. There may be problems I'm unaware of, but part of the point of
this post is that if there are such problems, I would encourage people
to pitch in and help fix them. I think it would be good if we here on
c.l.l could recommend an implementation for the kinds of uses I am
Comments solicited, of course.
- Re: ECL 0.9j-p1
- From: Scott Burson
- Re: ECL 0.9j-p1
- Prev by Date: Re: changing text color
- Next by Date: Re: How do lispers do their GUI programming anyway?
- Previous by thread: Re: ECL 0.9j-p1
- Next by thread: Re: ECL 0.9j-p1