Re: [epsilon-devel] You missed my later work

[Jeremiah]

> That could open up new possibilities.  However, there are so many
> choices, is this going to help us get forward right now?
You are right, it might not be an ideal step

> Thanks for the pointers!  I just released Mes 0.5, which is now fully
> self hosting.  We would need to investigate.  However, if we restrict
> the boostrapping path to either Mes or stage0+Mes, how could this help?

The idea is to make a sub-C compiler that supports only enough of the C
language required to bootstrap your MES, which I then could hand convert
to assembly and thus solve your lower bootstrapping problem.

> Compiling tcc is near the top of my priority list -- just below
> releasing Mes 0.5 (done) and discussing the next step (doing that now).
> So if nothing changes, I'll be working to compile tcc, any help or
> insights to make that easier are much appreciated.

Use the tests included in tcc, as once you can compile all of them your
compiler should support everything required to compile tcc.

> Posibly.  Christopher Webber mentioned PreScheme to me so I guess he's
> a fan.  Mes is currently prototyped in C, if we could move that to
> [Pre]Scheme that would be great!
>
> However, my first priority is to close the bootstrap loop, i.e. get
> either GCC or Guile compiled from what's Mes now. 

Absolutely agreed. And in the mean time, I'll be making tools to help
your bootstrap become ever easier. I'm looking at following the C
evolutionary path and implementing the META II compiler compiler and a
couple similiar tools.

> The one thing holding me back to attempt glueing your stage-N LISP to
> Mes is performance (and well, being terribly busy working to release Mes
> :-).  Currently mescc takes 2h30' to compile itself.  Compiling tcc is
> still a lot of work and is 10x as big...
>
> I fear that running mes on stage-N's LISP adds another 2 factors of
> perfomance penalty...

How about an easier problem? If your mes was written in lisp, why not
write a lisp compiler capable of compiling the lisp and thus solving the
performance problem.

As once an interpreter is made, you are already 30% done writing a
working compiler.

> It seems you're asking all the right questions...THANK!  However,
> although this full source bootstrapping endeavor has been a lot of fun
> until now, one of the biggest difficulties has been to reduce the number
> of open questions...almost anything seems possible.  So I was hoping to
> get more answers and all I get is more questions ;-)

How is this for some answers.
We are not smarter than all of the great minds of computer science that
have used teams of hundreds to create the foundation of tools upon which
we now stand.

But we have something they didn't... The answers of what worked well.

>From that I assert that the correct course of action for us is the
following:
Build simple, easy and fun tools that simplify the task of solving the
problem.

Your lisp interpreter, actually is closer to becoming a lisp compiler
than mine is. Should that interest you, it would solve your performance
problems.

Thank you as always,
-Jeremiah