Why Forth, was:Greetings

[Jason Marshall]

Paul Dufresne wrote:

> Looks interesting, is this made public on a web page?

I'm still working on it.  Right now, I have a few notes scattered here and there, a
lot of bits in my head, but not a whole lot written down or compiled.  It'll probably
take me another month to get to that point.

> >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?

It was a way to think of the code more like mathematical equations, was it not?
For instance, in math, x = x + 4; is not a legal statement.

> 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.

Let me just say that I am of the opinion that 'better language' is a lazy excuse for
slow execution speed.  If tunes intends to take away some of the details from the
user, I should hope it doesn't fail to appreciate that the details are still there,
and make the best use of them that it can, not the least of which is to improve
runtime productivity in addition to design time.

And the Merced will indeed make compilers have to work harder.

> Except that it will probably take
> 10 years before I switch to Merced (I am using a 486DX-33).

We shall see :)


> > 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. :-)

I would tend to believe that a LLL isn't intended for human consumption.
Alternately, to avoid argument, my particular vision would roughly map to a
three-level system (HLL, MLL, LLL), where as the current system tries to map to two.

> 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.

I didn't mean to imply that Oberon was a good interchange format.  In fact, I know
very little about Oberon, one way or the other.  It was simply a description of the
architecture-neutral code format that helped push me firmly away from thinking a
Virtual Machine architecture was an even remotely good idea (I contend that it is
not, as it at once keeps too much of certain types of information, while loosing
other types irretrievably).

Jason Marshall