[Ecls-list] merge with gcl

[worm]

Remitente: "malwin pilak" <kamilmikazal at wp.pl>
Fecha: Viernes, Noviembre 28, 2003 11:50 pm
Asunto: [Ecls-list] merge with gcl

> I know that ECL(S) and GCL are part of KCL family. I was
> wondering : is it possible to merge GCL and ECLS?. This could
> improve development of both (?) GCL and ECLS - there would be
> only one code to look at, but more developers to improve it. Is
> it possible to happen?

It is unlikely for several reasons:

1) The have completely different interpreters. ECL works with 
bytecodes and a separate lisp stack, GCL works with lists.

2) They produce completely different compiled code. For instance, ECL 
uses the C stack to pass arguments, GCL (I believe) manages its own 
stack via some global pointer. This leads to substantial differences 
in the way of coding the C part of ECL and of GCL (The latter being to 
my taste more obscure :-)

At some point I was asked about a merge by the current maintainer of 
GCL. The way it was proposed was that GCL should absorb ECL. However, 
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!). 
Devoting a few months integrating all what is good in ECL into GCL 
would mean simply reimplementing ECL!!! However it seems that in the 
end, this is what will happen.

I do not see the point of GCL, except for two facts. First, there are 
still applications that require a lisp which is not ANSI compliant, 
but follows "Common Lisp the Language" (However, would it not be 
preferable to port these applications to an ANSI implementation? This 
has already happened to Maxima). However, even the old EcoLisp in 
which ECL is based was a better Cltl than GCL.

The second reason is that the FSF wants a GNU Common lisp. Regarding 
this point, once it was discussed about the use of the readline 
library and what were the implications for GCL. May feeling was that 
the maintainers of GCL were very willing to turn the license to GPL. 
The fact that ECL has a LGPL license is a strong point, since it can 
be embedded in commercial applications. I would not like to see this 
possibility be ended in the future.

I agree that having more developers would be wonderful, and I do not 
stop calling for people to contribute. But it seems a call in the 
dessert, if you compare this mailing list and the GCL one: there are a 
lot of people spending (I would have said "wasting") into things like 
ELF loaders, and fighting against the latest security measures in 
Linux, which make data pages non executable.

Regards

Juanjo