[Ecls-list] Re: merge with gcl

[Juan Jose Garcia-Ripoll]

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.

Regards

Juanjo