Why Forth, was:Greetings

[Paul Dufresne]

On Thu, Aug 05, 1999 at 12:43:22PM -0700, Jason Marshall wrote:
> My current efforts revolve around developing a portable intermediate form (LLL,
> if you will) that looks a good deal like the intermediate output of an
> optimizing compiler, but with copious amounts of (optional) optimization
> metadata, so that load-time/runtime costs are lower.
Looks interesting, is this made public on a web page?


>This design is inspired
> in part by a book on continuation passing style that I'm currently reading
> (written by the authors of the New Jersey ML interpreter), in part by some
> literature I've read about the Oberon portable format,
One of the paper about Oberon, describes what was called, Guarded
Single-assignment form if I remember correctly. Basically transforming
the Abstract Syntax tree in such a way that a variable don't get
reassigned a new value, making optimizations easier. Well, I don't know
compiler construction enough to really give a good opinion, but it did
made a good impression on me. Do you want me to find back a URL to it?

> differently for much of that time).  I am hoping to leave the LLL as
> silicon-agnostic as is practically possible, while still being oriented toward
> supporting some of the newer chip architectures, such as the Merced (which
> supports compile-time flagging of code blocks that can run in parallel, for
> instance), small places (embedded or portable systems), or even for running at
Well, there is always someone here to hate what come from big commercial
companies, and I am sure Merced is no exception even if the subject did not
came here. But I personnally expect this chip to make some long-term change
by giving much more work on compiler writters, giving them the possibility
to do really impressive optimizations. Except that it will probably take
10 years before I switch to Merced (I am using a 486DX-33).

 
> So my biggest question at this point is why the decision was made to use an
> existing human-friendly language (Forth) as the LLL for the Tunes project, as
> opposed to some sort of more compiler-friendly format.
>
Because we are humans, not compilers. :-)
Well, you should first realize that Tunes is many peoples each with their
own sub-projects. Some just cares to high-level questions, some very
pragmatic people like Tom, decided to start their own low-level stuff 
like Retro. Sure Tom is in a better position than me to tell why he
choose to use Retro but I guess the answer would be because it was easy to
do, it give some good interactivity with the system. Defining a good
low-level representation takes time and I think some of us needed to get
some prototype because getting a group of people agree on a representation
is hard, Retro is some kind of let do it even if it is very imperfect,
will see what we can do to make it better, later.  

Forth is a first language supported, but some kind of reflective Scheme
is likely to follow.
Maybe even ML like language one day. But never Oberon because Oberon
is just a good simple proceduring language with good module system,
and well done small compilers. So it has nothing very new to offer.
Well, actually I am trying to convince them to integrate OberonD with
System3, because OberonD have a not too bad persistens store.

JAVA have the same problem as Oberon, that is not changing the way
the programmer see programming.

Paul