Lambda (was: Refactoring in Tunes)

[btanksley@hifn.com]

This topic is so cool.

From: John Carter [mailto:cyent@mweb.co.za]

> Forth and Postscript have similar properties.

> The Bottom Line
> ===============

> The problem I foresee is that any HLL built on the LLL risks
> destroying these properties and hence something precious. ie. I would
> predict that for Tunes to succeed in its stated aims the HLL _will_ be
> exactly the LLL, but with a excellent suite of library routines.

I would say you're almost right.  I was doing some thinking on this, though,
and pondering what Forth could borrow from Joy to make Forth better (and
vice versa).  I came to the conclusion that a Joy-ified Forth would make the
perfect LLL to go together with a more sophisticated Joy as a HLL.

The LLL would not have GC, nor would it have many of the useful things we
were expecting in an LLL; it would simply define a powerful VM and a
reflection system, and everything else (including the GC for the HLL) would
be written in it.

The LLL would be designed at the same time as the HLL, so that the two would
have some similarities.  The VM would be designed on the basis of Machine
Forth, to be similar to modern processors but based on a stack system (at
least two stacks).

> The main area of thought I think is needed is how do you 
> create a good type system and genericity on top of the 
> Joy basis.

A very good question.  Static type safety errors are VERY useful, even if
they're not required for correctness.  I'm thinking that annotated stack
comments would be useful here.

: someWord (STACK x:int y:int z -- )
    DROP * DROP ;

This will _require_ a stack optimizer.  I believe there's an open source one
in development as part of the RAFTS project.

> John Carter

-Billy