On Sunday 07 December 2003 03:17, Paul F. Dietz wrote:
> worm wrote:
> > I am convinced that ECL is above GCL in all respects: ANSI
> > compatibility, speed (the bytecodes compiler is a must for a decent
> > lisp interpreter), maintainability (it is becoming easier to add new
> > features), features (take, for instance, multithreading) and
> > portability (it took me one day to finish the port to Alpha!).
> GCL's compiler is currently much more reliable than ECL's.(*)
> This may be due to workout the compiler has received from the
> packages that use gcl has the delivery platform, as well as due
> to Camm's attention to compiler bugs revealed by recent
> testing activities.
Well, the GCL team has 12 developers, according to the web page, and I have to
share my free time among several other activities.
Porting ECL to other platforms is one of my highest priorities, and work on
multithreaded ECL was actually born from the need to encapsulate ECL's data
into an environment structure. I normally leave the testing phase (using your
nice test suite) to just before I decide to make a release.
Finally, another important reason for GCL's compiler stability is that GCL's
compiler is far simpler than ECL's.
Take for instance FLET (which was one of the sources of errors lately). Under
GCL these forms cause one closure object to be generated for each function.
ECL makes a more aggressive analysis of the functions, and it only builds
lisp objects for those which are used inside closures or returned by
functions. All other cases are converted to plain C functions with static
declarations. Such an analysis is complicated, and I am still in the process
of clearing the code, which is not very well written and uses obscure names
for many things.