Remitente: "malwin pilak" <kamilmikazal@...>
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
|