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
    partial eval.

  + 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?