[<<][staapl-blog][>>][..]Fri Apr 1 12:33:44 EDT 2011
All over the place
( This probably deserves a whole article. Consider it as a seed. )
It has been interesting and challenging to map the requirements of
Staapl onto the Racket code organization abstractions. Most of the
organization in Staapl is guided by Racket's macro & module system. I
started out completely uninformed and made all the usual beginner
mistakes (including dynamic binding, of course).
- Modules and macros
This is the heart of Racket. It is what makes flexible language
extension possible, and Staapl uses it as its default code
- Alternative interpreter/compilers (syntax certificates)
A more advanced form of low-level syntax manipulation. This is used
to implement the RPN code compiler/interpreter. Currently the way
this is done in Staapl needs some rework as I've not 100% figured out
- Units, and the way they mesh with the above.
Units are used to implement the compiler internals in a modular way.
Unit signatures are used to implement Staapl "word sets".
- Namespaces & eval, and how they differe from modules
For interactive code upload a namespace approach is used. This does
away with all static guarantees in places where it's useful. More
deeply, the tension between static code dependencies and dyanamic
"patching" is central to Forth, and the tension it creates is
- Partial continuations
While not strictly in the same class as the above, partial
continuations are and interesting abstraction for turning code into
data and vice versa. Together with a "mostly functional" style of
programming they are a powerful tool.