[<<][staapl-blog][>>][..]
Fri Aug 22 10:45:43 CEST 2008

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.






[Reply][About]
[<<][staapl-blog][>>][..]