Mon Mar 17 10:45:46 EDT 2008

lifting applicators

so.. splitting the stack/state objects themselves into different types
is straightforward. now, how should a language type be implemented? as
a run method? this is probably the most straightforward way: the
default could be apply, and anything smarter than the base langauge
simply overrides it.

this is confusing. if a word has an explicit 'apply' method, it's no
longer a procedure (which has an implicit, universal apply method).

dead end? yes.. a word structure is either a procedure, or not. why
should it be an abstract type? ->
  * to add annotation
  * to distinguish from other procedures

let's reach for the bottle: can i solve this with dynamic binding?
no.. all the words that somehow are to operate on the state need to be
lifted. it's not that the functions deep inside some dynamic extent
need to be updated, it's that the state itself needs to be
accessible. it's probably possible to solve part of it with dynamic
binding, but that will not play nice with closures..

so.. to come back to a comment in brood: the problem is not that prj
state language is a bad abstraction, it's that the lifting of
operators from base -> state is not so straightforward : anything that
passes or duplicates the whole state needs to be handled.

eventually, this boils down to 'run' and anything built from it. maybe
the compilation should handle this?

the next step to the solution is: 'run' should be isolated: no-where
should there be 'apply': i could keep the base representation for
debugging purposes, but everywhere else it should be abstract

maybe 'base-control' should be separated out again, like it was in
BROOD-2? am i going in circles? not really: but w.r.t. to lifting,
control operations are different.

next: split off control.ss which contains all the code tainted with

so, why is dynamic binding for state so bad? suppose there's a
transition from scat/state -> scat/base, and something needs to access
the state inside the scat/base extent. if this is allowed, the whole
base language is no longer referentially transparent.

let's see..
  ifte : (choose run)

is it possible to lift 'ifte' if the source is not available?

maybe i just need continuations?

there's something right in my face here i just don't see..