Sun Jun 1 14:12:34 CEST 2008
forth syntax / code instantiation
split the forth macros in 2 parts: those that create new names, and
those that do not. (the latter contains locals, quote and code
quotation). note that quoting doesn't need forth syntax: there is a
corresponding s-exp syntax. if the same is done for locals, then forth
syntax can be exclusively used in .f files or a forth: macro where it
so: the '(forth-toplevel form compile (defs ...)' does:
* expands to a special form (i.e. begin or #%module-begin)
* binds 'compile' to a function that generates words
* has preferrably no side-effects
the idea is that those forms can be composed (i.e. using 'load') and
that the toplevel module namespace initiates all code compilation.
the problem is not the expansion to definitions (either 'define' for
macros or 'define-syntax' for parsers): it uses the toplevel 'begin'
the problem is registeration of the forth words / instantiated
macro. binding it to a given name is not necessarily a good thing. i
really need to think a bit about how this is used in toplevel project
namespaces, both for one-shot and incremental code compilation.
maybe it is best to put all word instances in the toplevel namespace
AND allow for a mechanism to collect them (maybe from the namespace
using reflective operations?) this could be an algorithm akin to
garbage collection: only compile the code reachable from the roots =
exported (forth) namespace names.
it only needs a way to take care of the recursive definitions: the
word instances are defined in terms of macro names, and can only be
evaluated AFTER all macro bindings are evaluated. because of the level
split (forth macros are scheme functions) this has to be done
manually. it's easiest by just making all forth code into promises
the only problem remaining is fallthrough: how to guarantee the
correct order of compilation? this is one of the main reasons why
simple mapping from name -> datum isn't really possible: the order is
so, the problems:
* forth code is ordered (supports multiple entry points)
* evaluation of forth code requires all macros to be bound, so has
to be done after evaluation of macro body expressions.
this is solved atm once per module, but due to 'load' this operation
needs to be composable:
-> compose the definition of macros
-> compose the forth instantiation macros
it's probably ok to bind the labels to names so they can be accessed
through reflective operations later, but it's essential to also
somehow orchestrate the compilation of the code.
the remaining question: when does the code need to be compiled? also,
answer this in light of incremental compilation (keep the namespace
active, just add in more code/macros). is it ok to assume some