Fri May 22 08:48:06 CEST 2009
So what should usb-cdc.ss produce? It generates a number of Forth
procedures, but it does so on top of the flat Forth syntax. It's
probably easier to have it define s-expressions.
I need a form that abstracts these: register! wrap compile. It
probably is in fact easier to build it on top of the Forth syntax..
It has a more direct interface to the control flow graph compilation
process (the fallthrough feature).
The usb code should eventually become a unit, but now i only have the
PIC18F2550 to work with, so let's stick with a module that requires
Since this is to be used as an abstraction around generated names,
it's probably also best to only provide access to the final table
Ok. separated parsing and code generation.
Now, I need to think a bit more about how to abstract generation of
Forth code to scheme. Most flexible is the generation of flat Forth
code, since it has full access to all control flow features.
I think I found a nice hack: Generate flat Forth code, but do it as a
nested s-expression. This keeps the intended substructure intact but
can be easily flattened down. Think of this as using the
associativity of function composition to annotate code that belongs
Though, for bootstrapping the purely functional concatenative language
on top of the imperative Forth core, it might be interesting to
provide some means of escape. In the case of the usb code generator,
it doesn't make sense since it already uses lower-level language
constructs like jump/value tables.
TODO: name hygiene for usb.ss
OK. Looks like it's working now. usb-cdc.ss now defines 3 names.