[<<][staapl][>>][..]
Tue Feb 20 17:13:23 GMT 2007

next actions

run time state? or where to store the file handler? do this
non-functionally, since it's I/O anyway.. why not?

that seems to work. got ping working too. and @p+ next couple of
things should be really straightforward, but i am missing one very
important part: I CAN'T USE QUOTED PROGRAMS!!!

so i need to do something about that..

again, as far as i understant, the problem is in 'run'. if you hide
information by 'dipping' the top of the stack, there is no way to get
it back, unless you can bypass this mechanism somehow.

the thing that has to change is the interpreter.

ok. it should be possible by doing something like

    '(some app code) compile-app (for-each) invoke

making sure that the dict gets properly tucked away.

the nasty thing is this is dependent on the number of arguments the
combinator takes.

(invoke-1 swap run)
(invoke-2 -rot run)


invoke is bad for the same reason...

something is terribly wrong with the way i'm approaching this.. no
solution. too many conflicting ideas.

1. i need combinators to "just work"
2. i need to be able to run non-state code properly

possibilities:
- patch all quoted code -> parsed as state code
- do not patch combinators

maybe i should just try?

this is crazy...

i just don't get it.

heeeelp!


i don't know how to solve it.. but i can work around it :)

basicly, the problem i have is that i can't use higher order functions
in combination with the state abstraction: basicly, because the
abstraction effectively uses a different kind of VM. to solve it, i
need to either accept i have to change the VM, or just make the data
i'm using persistent. there are several options:


* turn the n@a+ and n@p+ into target interpreter instructions. this
  just makes them static, so i do not have to use references to
  dynamic state in the core routines. might be the sanest practical
  solution.

* just forget about the functional approach to the dynamic state and
  store this in a global variable. a bit drastic, and i will probably
  regret that later, since it feels like giving up on a good idea at
  the first sight of real difficulty...

i will go for the first one so i can at least finish the interaction
code.. this has the advantage of making the monitor itself a bit more
robust, since it will provide full memory access.

one thing i didn't think about though: making ferase and fprog
primitives will make them a bit less safe (ending up sending random
data). i should add a safety measure.

ok, that seems to work.



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