My God
What so cool with Internet and forums like advogato is that
ideas, words and units of thought is flowing from mind to
mind mutating, mixing, replicating, bouncing, In a very
subtle way. The communication is many to many and this is
indeed important, we must be able to communicate in order to
make sure that the world won't fuck up.
Introspection is a nice powerful feature that seems like a
hot topic these days. I try to practice this a lot, not only
in my code, but on myself. It is kind of cool to dig out the
association and logic behind an idea.
One idea I got was to check out scheme. There is some nice
food for thought in that community. I've planning to read
about lazy evaluations, but here is my current view on
delayed evaluations.
If D1,D2 is delayed, basically f(D1,D2) :D3 is delayed
as well represented if any of its arguments is delayed. Now
this means that D1->D3 and D2->D3 and you see that what you
have is a directed acyclic graph (DAG) that represent your
overall delayed state with a pointer to a function at each
node. So it is not at all a difficult concept. But what
about and (if D A B), D is delayed. Here it seems you need
to store the value of both A and B in order to be able to
use it later, this is actually a difficulty. I will need
only one of A and B but I have to get both values in order
to later retrieve the correct value. If you have recursion
in A or B you may find your way into an infinite loop. So if
A = (g C E) you need to store (g C E)
and continue so recursively. With no gotos and internal
state in your code you will then be safe. If you have state
you then need to store the state related to both A and of B.
A key issue here is to avoid relation pollution e.g. you do
not want to store state that is not needed to retrieve the
value later.
In my (switch-if P A B) construct if P A is incremented
else B is incremented. I try to avoid using delayed values
in the P but storing the state of A and B may seem to solve
the problem. will it will be safe? No, there is another
problem. A and B will contain signals backwards in the
system about yielding values, about finishing iteration and
skipping stuff. So depending on the possible signals send
back you will have both complicated knots to untie as well
as more trivial ones. Some of these questions can be
mitigated by simply returning values of special type like a
skip value. A quit value which also can be implemented.
Consider that we are under a delay. And now the delay is
activated with a skip value. This is the interesting
construct. Consider an update of internal state:
(update Var Vals Oldval)
The most simple choice of logic is that if any Val is a skip
value, Var is a skip value and equal to Oldval. A function
just returns a skip value if any of it's arguments is a skip
value. This logic is then transported in the delay graph.
The finish signal is a little more subtle but basically
each object as a finish value Vf, and if object Y at an
update gets a finish value then it should fire it's finish
function to update Vf, the variable representing the
finishing value. Else the transportation and action of
the finish type is like skip but of higher precedence.
Now the actual iteration is something like
(do
(make-generator X)
(loop X))
(define loop X
for:
(X.next)
Ret = (relate Ret (X.val))
(if (finish? Ret)
goto exit
goto for:
exit:
X.Vf
The relate is just a relation that represents the transport
of the finish all the way to the current Ret if this has
been delayed and you have to iterate a few iterations more
than needed.
Trying to handle the yield signal is delayed. No just
kidding. You need to do the following
(do A B C)
The logic is, take next A, if A is a yield stop! and use
value of A. the next time start with A again. Else continue
with B and so on. Now if B is delayed and might be a yield
you need to store the state of the do e.g. the state of
A,B,C and the internal state of do e.g. a program pointer.
Then at the next update of this object if the delayed value
have materialized you will then just continue with the
evaluation of the do construct and everything would be fine
else you will have to just chain the actual updating and
return the delayed value.
Can we have infinite loops? Well, At each step you will have
a tree of objects that you update in the natural order, when
you update subtrees will collapse an new subtrees will be
created. A delayed object is returned at a certain object
and then transported to objects below it in the order. Hence
if you keep a logic where you always will fill in the
missing information at the same object that you issued the
delay you will be safe.
I didn't realize all this before I started writing. This is
why I write, enjoy
