Sun Mar 23 09:38:32 EDT 2008

syntax: going further

what i'd like to save is not only this structure, but a means to
transform it into something that
  * has addresses bound
  * can be extended

made the 'lambda' part parametric.. is this necessary?

so.. maybe move away from storing the delayed computation to something
more concrete? like the rest of the syntax stream? kept it, but
cleaned up the access a bit.

so.. it's essential to have 2 functions:
  * the syntax transformer
  * the asm graph evaluator

now, when the assembly step has finished, the original syntax needs to
be updated (words replaced with address refs) and saved such that it
can be reused later to build new syntax expression.

so what is what?

a dictionary is a collection of frames from 'compilation units'. (a CU
is a single level in the final nested letrec expression.) composition
of CUs is composition of syntax transformers.

ok.. separated out the core form: code->reps

made an extra macro called 'dictionary' which enables a slightly
lighter concrete s-expression representation, so it is easier to edit
when replacing words with macros compiling addresses.

maybe add another called 'word' which transforms the names so expanded
names don't have the prefix? this will probably clash with
macros.. nope: there's a way between: i need this only in the
representation, which is after macro expansion.

EDIT: had to update rpn-tx.ss to expand forms returned by
rpn-map-identifier before determining if the resulting identifier is a

so.. we get this:

box-macro> (forth-rep dictionary (: foo 123 : bar 4) (: baz foo bar))
(lambda (forth macro collect)
    ((foo forth (lambda (x) ((lit 123) x)))
     (bar forth (lambda (x) ((lit 4) x))))
      ((baz forth (lambda (x) ((word bar) ((word foo) x)))))

where 'dictionary' and 'word' are macros that make this code a bit
more readable. updating a dictionary to replace words with references
goes like this:

      (baz forth (lambda (x) ((word bar) ((word foo) x))))
      (baz macro (base: #x0123 compile))

maybe this deserves a little macro of itself to turn it into

      (baz macro (address #x0123))

the next step is to turn this dead representation into a live function
that can be composed to generate new syntax transformers.

so why a raw lambda, and not some form that has concatenative code?
the problem is that this requires uncompiling: the lambda is the
result of all syntax that might be defined in forth code, which can
contain arbitrary scheme forms: there might be no 'simple'
concatenative form.

on to extension transformation.
  rep + name.address -> rep