Tue Jul 21 09:14:30 CEST 2009


The rewrite in march-april this year solved some problems.  The parser
is now static and composes better.  However, there is still
duplication at several points.  The idea of dictionary and prefix
parsing is so central to forth that it shows up everywhere -
especially when you unroll some reflection - so maybe this deserves a
better abstraction?

Also, current parser seems too verbose to me: it should be written in
Forth sooner than CPS Scheme.

Another point is that it might be better to perform control flow
analysis in a second step.  Doing everything at once complicates
matters, and for targets that do it themselves (later: LLVM) it's
completely unnecessary.

Should i just remove it, and go back to a more straightforward
low-level semantics?

The way compilation works atm, it needs to solve the following

   - implement `org-begin' .. `org-end'
   - macro local exit

The former allows you to place blocks of code at fixed addresses.

I could try this pretty much in isolation, since the compiler is a

Looking at it, the current implementation is certainly not too
complicated.  The `state-update' function helps a lot to make it more
readable.  The trouble is however that the control macros do things
behind the scences.  Another problem is that conditional branches are
not counted, making the resulting data structure not a proper CFG.

Maybe finding a proper naming scheme and a better central data type
would help?  Maybe it's just too lowlevel..

Another problem is the use of assignment later to build a
"non-standard" graph structure (as opposed to a flat tree).  A flat
structure can be turned into a tree using names to be bound, i.e. a
lambda expression.  Can this be used to represent the data structure