Announcement of ECL v0.9j-p1
============================
ECL stands for Embeddable Common-Lisp. The ECL project aims to produce
an implementation of the Common-Lisp language which complies to the
ANSI
X3J13 definition of the language.
The term embeddable refers to the fact that ECL includes a lisp to C
compiler, which produces libraries (static or dynamic) that can be
called from C programs. Furthermore, ECL can produce standalone
executables from your lisp code and can itself be linked to your
programs as a shared library.
ECL supports the operating systems Linux, FreeBSD, NetBSD, OpenBSD,
Solaris (at least v. 9), Microsoft Windows and OSX, running on top of
the Intel, Sparc, Alpha and PowerPC processors. Porting to other
architectures should be rather easy.
ECL is currently hosted at Common-Lisp.net and SourceForge. The home
page of the project is http://ecls.sourceforge.net, and in it you will
find source code releases, a CVS tree and some useful documentation.
Notes for this release
======================
This is mostly a bugfix release, but it includes several interesting
new features, such as the SERVE-EVENT package, ported from SBCL by
Steve Smith, finalization of lisp objects and installation of ECL
on standard unix paths.
For those who downloaded the 0.9j release, this file contains
additional fixes.
Changes since 0.9i
==================
See file src/CHANGELOG or browse it online
http://common-lisp.net/cgi-bin/viewcvs.cgi/ecl/src/CHANGELOG?root=ecl&view=markup
I think ECL is an important implementation that deserves more
attention from the community. Here's why.
It would help the growth of the Lisp community if Common Lisp were
more widely perceived as a viable alternative to Perl and Python, for
the kinds of programming tasks those languages are commonly used for:
relatively small and non-performance-sensitive programs, one-offs, and
rapid prototyping. When I think about what would be necessary for me
to introduce a CL implementation for this purpose at the company I
work for, I come up with the following list of requirements:
(0) Open source. Must have at least a little ongoing maintenance
activity.
(1) Portability. Must run on Windows and all reasonably popular and
current Un*x variants.
(2) Licensing. License must be no more restrictive than the LGPL.
(3) Compatibility. While absolute ANSI CL conformance is perhaps not
necessary, any deviations must be minor. Also, in areas not specified
in the standard (e.g. pathnames), the implementation should usually
behave in the way that the CL community has generally come to prefer.
(4) Debugger. Must be reasonably usable at minimum. A fully-featured
debugger, with stuff like local variable access, a reinvoke-frame
command, and a break-on-frame-exit feature would be nice.
(5) Stability. A solid, well-debugged implementation is much more
important than having the latest features.
(6) Delivery. Ideally, the implementation makes it easy to deliver
standalone executables.
Non-requirements:
(0) High performance. A native code compiler is admittedly very
desirable, but it doesn't have to be a good one. A byte-code compiler/
interpreter might even suffice if it were well designed.
(1) Multithreading. While it would be nice, I don't think it's
necessary. Kernel threads are definitely not necessary.
Now let's have a look at the various open source implementations to
see how they fare. CMUCL and Clozure CL (formerly OpenMCL) have no
Windows releases at all. SBCL describes theirs as "in progress". (As
I understand, SBCL can't always start up on Windows, depending on what
DLLs are in use on the system. If that's correct, then even though
SBCL may work reliably for most users, it won't work at all for some,
which is a fatal problem for someone trying to deliver a product on
the platform.) And, the SBCL development team doesn't emphasize
stability nearly as much as I think is needed for this class of
applications.
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
attorney nervous.
ABCL is a very interesting candidate. Building on Java solves the
portability problem, and its performance, while not great as I recall,
is probably adequate. The license is again a modified GPL (why not
the LGPL?) but in this case it might be acceptable, as I'm not aware
of any reason to doubt the author's right to offer the modification.
The big downside here is the weak CLOS implementation. Also, I don't
recall what debugging facilities are available, if any. Still, this
may be a good choice in some cases.
GCL hasn't released an update in over two years, and has a reputation
for not quite being ANSI compatible.
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.
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
talking about.
Comments solicited, of course.
-- Scott
In article
<····································@e25g2000prg.googlegroups.com>,
Scott Burson <········@gmail.com> 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
> attorney nervous.
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
> talking about.
>
> Comments solicited, of course.
>
> -- Scott
--
http://lispm.dyndns.org/
On Wed, 02 Jan 2008 12:13:58 +0100, Rainer Joswig <······@lisp.de> wrote:
> 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.
If you want to know more about ECL and bomb its key maintainer with
questions, come to Amsterdam in April. See signature.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Wed, 02 Jan 2008 12:13:58 +0100, Rainer Joswig <······@lisp.de> wrote:
>
> > 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.
>
> If you want to know more about ECL and bomb its key maintainer with
> questions, come to Amsterdam in April. See signature.
>
> Edi.
Edi, you've learned your marketing lesson well! ;-)
--
http://lispm.dyndns.org/
On Wed, 02 Jan 2008 15:53:42 +0100, Rainer Joswig <······@lisp.de> wrote:
> Edi, you've learned your marketing lesson well! ;-)
I'm working on it... :)
And thanks for blogging about the ECLM.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
P� Wed, 02 Jan 2008 12:13:58 +0100, skrev Rainer Joswig <······@lisp.de>:
>
>> 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.
>
The fact that hardly any ANSI-CL libraries work out of the box is a
serious problem if you ask me.
You are basically stuck with either implementing everything from scratch
or spending weeks or months porting code. In fact ANSI CL discrepancies is
one of the main reasons I changed from Corman to LispWorks..
--------------
John Thingstad
On Jan 2, 3:13 am, Rainer Joswig <······@lisp.de> wrote:
> Sure you can sell even GPL software. You have to open up the source code
> for that, though.
Well, yes. That would be the problem. :-) Perhaps there might be
cases where a company wouldn't mind doing this -- say, if the Lisp
code represented a small and relatively unimportant part of a large
system -- but by that very token, in such a case it's hard to argue
for using Lisp instead of, say, Python.
This is an important point. I'm not talking about cases where the
engineering management of a company has made a strategic decision to
use Lisp for a large and critical subsystem (though the GPL would be
an issue in that situation also). I'm talking about situations in
which Python and Perl (I should probably add Ruby) are not just viable
competitors but the market leaders, with Lisp a distant also-ran. To
compete in such a situation, Lisp must remove as many objections as
possible. Even the suggestion of a possibility that a company might
be forced to open some source code that it doesn't otherwise want to
open will make it a non-starter.
I can't say this too strongly. If we want the Lisp community to grow,
we need to understand the reasons people have for not using it, and
eliminate as many of them as we can. Granted, the parentheses are not
going away; that's one we just have to live with. Other objections we
should try to deal with. (To digress a bit, I'm glad to see people
developing non-Emacs-based IDEs for Lisp, even though I doubt I'll
ever use them myself.)
> 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.
I think John Thingstad has nailed this point. For the code you're
writing yourself it may not matter, but if you want to use library X,
and library X uses CLOS, you need CLOS.
> A debugger is very important, unless you develop with some other
> environment and deliver with ECL.
Agreed. I just haven't evaluated ECL's debugger yet.
-- Scott