[<<][staapl][>>][..]
Sun Feb 10 14:50:08 CET 2008

state management / the point of prj>

something really smelly about it. i think i'm better off with true
mutation in the scheme sense, instead of working around it the way is
done in prj.ss

the base line is: this prj> mode should be usable for DRIVING THE
TARGET. the whole functional state business is overkill: most code can
really be made functional, and possibly more understandably written in
scheme. whenever state recovery is necessary, it can be moved to the
functional domain (i.e. assemble and compile as they are now..)

the problem i'm trying to solve is discipline: not gratuituously using
global state. maybe i should read some haskell tips, since this is the
way haskell programs seem to be written: a bulk of pure functions and
a central state management module through monads.

let's see some important properties:

  - the interactive forth layer translates to prj scat code
  - the macro code is purely functional code with a threaded asm state
  - staying close to scheme keeps things simple


other remarks:

  - base and prj are different. this is clumsy.
  - there are 2 namespaces: NS and the prj state namespace.
  - prj already behaves as true mutable state. is permanence necessary?
  - atomic failures

preliminary conclusion is: scat code is important as intermediate
layer between scheme and forth, both for interactive and compile time
use. the compile time part needs to be functional because it makes
computations easier: compilations should be really just functions. the
interactive part however is intrinsicly stateful: ultimately it
manages the state of the target and the current view (debug UI).

the only place where current scat/state approach is useful is atomic
state updates. these however, can be replaced by purely functional
code and a transaction based approach: each command is a state
transaction and either fails or succeeds. compositions of transactions
should maintain that property. aha, holy grail identified:

   COMPOSABLE TRANSACTIONS


maybe i just need to start reading again. this is very related to COLA
(combined object lamda architecture) and the recent transactional
memory stuff in haskell.



[Reply][About]
[<<][staapl][>>][..]