[Ecls-list] Patch: FTYPE proclamations with DEFTYPE'd types.

[Gabriel Dos Reis]

On Sat, Sep 13, 2008 at 7:09 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Sat, Sep 13, 2008 at 2:23 AM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>>
>> However, I realize that ECL reports 8.9.0 as version, when previously
>> it said 0.9l.  I was under the impression that you did not want to
>> release 1.0 before the compiler is stable.  How should I interpret
>> the new version?
>
>
> Well, I have become a bit fed up with the old compiler. It does the job
> pretty well, but it is a mess to maintain, it is not very flexible and it
> duplicates the effort that I want to put into the bytecodes compiler, which
> currently, together with the library, is the most stable component in ECL.

So, what kind of `reports' are you interested in receiving?
For AXIOM  -- and now OpenAxiom -- I've advocated ECL because it did
not suffer from all the `save image stuff'' all other free Lisp implementations
display.  Said differently, it is more portable than other implementations
even if it is sometimes less efficient,  I suspect Sage's move to rely replace
CLisp with ECL is based on similar considerations.  So, for me it is important
to know what I should expect for the future of the `old compiler'.

>
> Besides that, one sometimes needs an additional motivation to keep working,
> so I have decided to put the old compiler in pure maintainance mode and find
> me a more interesting task, which is to write a compiler from scratch.

:-)

> As I have it in mind, this is going to be an incremental task. First born as
> a new frontend to the bytecodes system, it should coexist with it. It is
> going to be developed solely in lisp, though I do not discard a translation
> to C for stability and self-bootstrapping. The design should be based on two
> layers: a lisp -> SSA translation and two SSA -> anything backends, one for
> bytecodes and one for C. All in all, the library should remain the same and
> that is already more than 90% of the code.

SSA is a technology that was invented almost two decades ago, but it took
time to propagate to non-commercial compilers. GCC only recently moved to
SSA starting with 4.0, but was able to incorporate `modern' optimizations
(even though they have been in commercial compilers for a long time).  It is
a form that make some analysis and optimizations very simple.  I'm glad
to hear that ECL is moving in that direction.

[...]

> Anyway, this is currently my pet project. I guess it is going to take 10
> times the time that it would take if I did not have a real life, a job and a
> mortgage to pay,

in order words, a life :-)
those are concrete considerations that do not resonate well in some corners
of free software community.  :-(
I very much appreciate your dedication to improve ECL.

> but as I said before, one needs more than just polishing
> corners of something that already works pretty well (the interpreter and
> library) or trying to stretch something which is too limited by design (the
> current lisp->C translator)
>
> And this is also the reason why I stopped thinking about 1.0 versions this
> week.

OK.

Do you have a design document for the new compiler, or is it
still in its `brain storming' stage?

-- Gaby