Mon Aug 18 16:41:36 CEST 2008
Does Forth need improvement? Forth already has metaprogramming
capabilities, so why add another layer? The short answer is that
Staapl REPLACES the metaprogramming mechanism with a different one.
I use the name ``Forth'' in texts about Staapl because the machine
model used is close enough to Forth for the resulting language to be
called a Forth dialect. But to understand the idea behind Staapl, the
Forth language needs to be split up into two parts:
(1) the 2-stack machine model that supports the language
(2) the low-level reflective self-hosted language structure
My claim is that (1) is an idea powerful enough to exist outside of
(2), and that in a cross compiled, non-self-hosted language setup, the
standard (2) can be replaced by something more powerful. In a
minimalist self-hosted environment, there is little room for improving
(2). Apart from small changes found in a myriad of incompatible Forth
dialects, the core design seems to be quite optimal.
The problem with Forth is that when you DO want to use some standard
compiler techniques factored out in different steps, instead of the
usual highly reflective ultra-minimalist no-datastructures-necessary
Forth approach, using a low level language like Forth to implement the
compiler just makes things more difficult.
So I have this to say:
* Staapl doesn't use Forth, the reflective language, as you know it.
It is mostly inspired by the Forth machine model. It stays close to
the Forth language legacy, but is significantly different in key
points, where it replaces reflection by explicit staging.
* Staapl uses the Joy model, a functional language related to Forth,
to implement metaprogramming. For practical reasons, the Joy model
is slightly adapted to be embedded in Scheme. PLT Scheme is used
for its advanced module system that simplifies programming with
macros, and its overall coherance as a well-documented Scheme based