Wed May 21 16:20:45 CEST 2008

The new Staapl (Brood-5)

The main motivation for the 5th Staapl refactoring iteration was
name scope management.

The objective was to turn all names that occur in .f files into
(Scheme) compile-time identifiers, and no longer use (Scheme) run-time
hash tables indexed by symbolic names.  This is quite an important
change, since it allows to treat all names hygienically.

Relying more on PLT Scheme's scoping mechanism (lambda + modules)
instead of ad-hoc hash table based namespaces makes Staapl behave
better as a PLT Scheme extension[1].  Scope is everything!

So, what does Staapl 5 look like?  The Coma language is defined as a
collection of code transformers, which are (pure) Scat functions that
operate on a stack of machine code (Scat's parameter stack).

Staapl is implemented as a classical layered bottom-up Scheme
application written in functional programming style, where Scheme
macros are used extensively to construct binding forms and
specification minilanguages.

   * Scat layer.  A language layer on top of Scheme that implements a
     concatenative language with threaded state.

   * Coma layer. A collection of _primitive_ Scat functions that
     implement (local) machine code transformations, specified in
     terms of target machine code pattern matching.  Coma inherits
     Scat's _composition_ model.

   * Structured programming layer.  Forth-style control flow words
     implemented using a 2nd compile time stack.

   * Instantiation layer.  Create target code by evaluating generator
     functions.  This produces code arranged in a control flow graph.

   * Forth-style syntax: in addition to the s-expression syntax, some
     frontends are provided for: prefix parsers, a forth-style lexer,
     combined macro/word definition in a single .f file

   * Interaction and name management code.  Independent of the
     compiler, this layer provides target machine console interaction
     for interactive debugging and (automated) testing.

[1] What I realized, is that thinking about code _graph structure_ is
    a whole lot more revealing than thinking about names in a flat
    space!  This is where Scheme differs significantly from Lisp and
    other dynamically typed languages.

    For more information about the PLT Scheme declarative module
    system, have a look at:

    This also finally made me see how to unify and represent both
    dynamic interactive ``toplevel'' development and static
    hierarchical modules.