Re: ECL 0.9j-p1

In article
<fe37faa5-b49f-470b-b3de-973880d24e27@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
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
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/
.

Relevant Pages

  • Re: Equality of foreign objects
    ... Does this mean that no conforming Common Lisp implementation can ... extend EQUAL to meaningfully compare implementation-specific objects ... There is no generic equivalence predicate in Common Lisp that can be extended for user-defined types, and there are good reasons for that. ... Other languages that pretend to provide such generic equivalence predicates get them wrong most of the time. ...
    (comp.lang.lisp)
  • Re: Smalltalk-like Tools
    ... They all, almost without exception, started as libraries that depended on implementation-dependent details of a single Common Lisp implementation, sometimes even heavily. ... I'm not arguing it doesn't exist at all, I'm only arguing that you shouldn't be led by fear when choosing a Common Lisp implementation. ...
    (comp.lang.lisp)
  • Re: The ANSI JAPI version of the GNU Common LISP (the 2008 release)
    ... get a GNU Common LISP system with the CLOS. ... ANSI version) version of GNU CL, which seems to be a very good ... and does have the CLOS! ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... I don't think that's what you want for Common Lisp. ... Python, with one canonical, free implementation which get the vast ... Common Lisp implementation as the canonical one.' ... tools work with Python, and a relative few need JPython or Stackless ...
    (comp.lang.lisp)
  • Re: The ANSI JAPI version of the GNU Common LISP (the 2008 release)
    ... get a GNU Common LISP system with the CLOS. ... and does have the CLOS! ... and load the ANSI JAPI ...
    (comp.lang.lisp)