Sun Dec 16 10:52:30 CET 2007
extensible interactive parsers
two conflicting views here:
* currently interactive parsers are isolated functions, which is
nice and clean.
* what is required is extensibility and re-use.
the solution seems to be to put the components in a global name space,
which is used as the unified extension mechanism, and replace the
function with a stateful one that refers to the name space.
key elements here are 'with-member-predicates' and
'predicates->parsers'. these form a construct that needs to be
attached to the global namespace tree.
the former creates a collection of membership predicates.
the latter creates a map (finite function) from atom -> parser.
the problem with the current approach is the generality of the
parsers: they don't just map names to functions, but also create
'classes' with similar behaviour, so there is a level of indirection
that needs to be captured. the live parser map is
* symbol -> parser (parser primitive)
* symbol -> symbol (parser class)
if they are stored in this way, interpretation is quite
straightforward. the approach is:
* provide alternatives for 'with-member-predicates' and
'predicates->parsers' so they postpone their behaviour and store
it in the global namespace.
* provide an interpreter.
OK. implemented + tested.
Some further cleanup. Maybe it's best to not store symbols in the
dictionary, but parsers: use cloning instead of delegation? This way
the dictionary IS the finite function. The real problem is that macros
have a delegation method (function composition) but parsers (and
assemblers for that matter) have not.
Forth syntax parsers (lookahead) have no composition
mechanism. Therefore cloning is used to give some form of code
reuse. It used to be delegation, but this gives dynamic behaviour
which contrasts with the static, declarative intent of the global
name space, regardless of its implementation as a hash table.
and about ns:
The global namespace is used as:
* declarative symbol table (single assignment, mutual refs)
* cache (forth macros should eventually be defined in state file)
Maybe forth.ss should be separated into generic forth style parser
macros and functions and the definitions of the parser words.