[<<][staapl][>>][..]
Sat Mar 29 09:39:50 EDT 2008

hindsight

Making BROOD more static is a way to bring the early exploratory phase
into a more fixed structure. It seems the overall design is good
enough to be stabilized. from that perspective it makes sense to cast
it in stone.

What did actually change over the last couple of weeks? Basicly,
symbols are disappearing. The only place where they are still left is
in the assembler, but that's easily changed. Symbols are replaced with
identifiers, and are a (scheme) compile time object. The Forth
compiler is now implemented using Scheme's exposed compiler API (the
macro system).

What this change did for the structure of the program is to point out
places where reflection was used without justification. It's now using
PLT Scheme's approach of 'unrolled reflection'. As a result, more
things can be checked at compile time + name handling is completely
handed off to scheme.

This is the natural extension of 'lamb / brood 3'. The step through
brood 4 was necessary to get familiar with the language layer
approach. Giving up the NS hash table and run time evaluation hacks is
the final step in trusting this layered module system: when names are
identifiers, scheme can do the management.

   so to restate one of the goals of brood: to do Forth the PLT Scheme
   way: built on top of its hierarchical macro/module system.

things i'm adding:
   - RPN: rpn syntax for scheme
   - SCAT: an embedded rpn language with scheme semantics
   - PAT: a typed concatenative pattern subsitution language
   - MACRO: a language for expressing postponed forth semantics
   - FORTH: building forth syntax on top of scat
   - PURRR: macro language with forth syntax

MACRO has postponed semantics because the output of brood is assembly
language. If there were a simulator, it would make sense to bring the
static implementation down to that level. Instead, that part is still
interpreted. This also allows easier integration with external
assemblers.

Central to brood is the structure of the MACRO language. It's a
concatenative language that operates on 2 stacks: the SCAT data stack
which is used as the MACRO compilations state stack, and the 2nd
stack, which contains the assembly code, is interpreted by the PAT
language as a typed concatenative language: the one which implements
partial evaluation in PURRR.

PAT's matching can be translated to compile time if at one point it is
decided to give up on the symbolic asm representation, but instead use
a (typed) abstract one. This probably needs some cleanup in the
assembler first.




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