Wed Apr 2 20:39:46 EDT 2008
some words about
1) bottom-up VS. late binding.
2) augmentation (permanent) or
default + specialization (temporary redefine)
(the interesting thing about writing brood/scat is that it brings up
issues that seem quite important on the level of larger scale program
so, is this specialization of deep components just a dirty hack?
+ bottom up design with static binding at least solves the
'undefined' errors: the lowest layer's linking is statically
checked. having a core that's bottom up makes it easier to develop
and test: there are a lot of macros and transformers in there. the
defaults for low-level components could be just for testing
+ allowing vectored code (making everything a parameter) solves
having to explicitly _declare_ things as a parameter: some
pluggable behaviour is necessary in the current approach.
are parameters necssary in the core language? they make sense for rpn:
used in scat/macro/interactive.
do the macros need a similar approach?
is this all a consequence of the solution, or the problem?
seems the most important question is: OK to let higher level modules
modify parameters, instead of setting them with 'parameterize'?
what about making re-definition explicit in the 'compositions' macro?