....
>
> The paramount reason to attempt to go with ecl instead of gcl
> or clisp
> [only self-hosted, build from source, Open Source lisps need
> apply :)]
As I've mentioned previously, this seems to me an arbitrary requirement;
as far as I'm concerned, I do not see as an essential requirement that
I only run software that I can build ON MY OWN MACHINE. I only
require that the software can be built on SOME machine, and I prefer
that it be built by someone else, somewhere else.
For example, I have not had a copy of GCL on any computer for many years,
except one that was a Maxima-system-build.
> was that it has compiler support for all our current and
> intended port
> targets. gcl has build issues galore [2.6.8cvs as well as
> 2.7cvs], clisp
> has problems with gcc 4.2 and 4.3, but that was discussed at great
> length in the recent "Project" thread in sage-devel.
>
.. snip..>
> > RJF: The benchmark section says the competitive CLISP is
> astonishingly fast in
> > comparison with ECL.
>
> Those numbers seem to be outdated. The above linked presentation has
> some comparisons IIRC of more current code.
I looked at that. It shows ECL slower than CLISP slower than GCL, but
this is pretty much irrelevant because the test being timed is an ANSI CL
standards compliance test, not a runtime efficiency test. Programs are
run only enough to see they compute the right thing.
A couple months
> back Waldek
> Herbish started building FriCAS on top of ecl and over the
> course of a
> couple weeks ecl's performance for pretty printing code and
> some other
> things was improved dramatically.
A test to see how fast a program formats texts for printing does not
seem that useful a test in the context of a computer algebra system.
Dunno about "some other things".
> So I am convinced that the ecl
> maintainer [Juan, whom I CCed] is more than interested in solving any
> performance issue and while he might be busy with his own work other
> people have supplied patches to solve performance problems. So IMHO
> there is much more life in the ecl community than the other
> open source
> lisp communities.
Seems dubious to me, but I can't say first hand if the GCL and SBCL
communities
are down to less than 1-person equivalent or whatever Juan's time
allocation is.
> snip...
> last time I looked], so I consider a well working lisp on Windows
> important.
Me too. That's probably why GCL is important. And why I would prefer
that GCL be improved. If ECL can be perfected without diverting resources
from GCL or other Lisps for which Maxima already works well, that is
fine.
<snip>
>
> The garbage collector in the current ecl release is pluggable
> and boehm
> is used per default [IIRC it is the only choice at the moment]. I am
> fairly clueless about the different garbage collection libraries out
> there, so I do not know how boehm compares to what you would
> expect.
Well, I expect that it is unsatisfactory. You have a choice for long-running
programs. You can spend 30% of your time in GC, increasing memory access
time as you go, as your memory becomes fragmented, and have your system
grind
to a halt, or you can have a real garbage collector. ECL's experience
may be different, but probably not.
> It
> was my impression that boehm is widely used, but that
> obviously wouldn't
> make it a good implementation ;).
It wouldn't even make it a good idea (for Lisp). It might be ok for
short-running
C programs, or hacked-together demos.
Think about the widely-used OTHER software you might encounter.
ECL may be just fine for what it is, an experiment in building a Lisp with a
slightly
different design. If it runs Maxima and SAGE uses it, that is your decision;
I
hope it does not divert Maxima resources though.