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. 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
* 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.
 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