Staapl design choices

These are the 4 mostly orthogonal big choices that are at the core of
the structure of Staapl.
* [LIBRARY vs. LANGUAGE] Staapl is not a different language. It uses
existing ideas and implementations from Scheme and Forth, and is
structured as a library extension of PLT Scheme. This avoids all
problems with concrete syntax. Concrete syntax can be built on top
of the existing concrete syntax system (i.e. the Forth parsing
words) but the abstract syntax is kept as clean as possible: Scheme
syntax + purely concatenative for the intermediate representation
and low level machine model.
* [OOP vs. FP] Staapl is based on functional programming instead of
object orientation. The main advantage is that partial evaluation is
easier (almost trivial) in the absence of state.
* [STACK vs. REGISTER] 2-stack machines live at the intersection of FP
and imperative programming. This simplifies machine models:
register (RISC) machines have NON-LOCAL state (registers) at their
core, while stack machines are built around a LOCAL state mechanism.
This difference cannot be stressed enough!
* [UNTYPED vs. TYPED] Staapl is based on Scheme (untyped lambda
calculus) and not on ML/Haskell. The reason for this is largely
historical. Currently I see no reason why it cannot be implemented
in a language with ML-style type system. Such an approach would
make some corner cases (ad-hoc union types) more explicit. However,
Staapl's _implementation_ heavily uses macros for creating new
binding and composition structures, so it might need
re-implementation in a different style. It seems a better approach
to gradually introduce more static features into Staapl than to
rewrite the system in an all-static language.