Brian,

I learned recently that I had built a late evaluation mechanism,  Ok, I
said, but who cares?  If I don't "force the thunk", but rather let the
messages execute when they can, am I still doing lazy evaluation?   The
purpose was to provide programming facilities to hide latency.  Instead
of demanding computation completes at a particular time, eventual
sending expects delayed completion.  It manages to chain a sequence of
messages, to various points in the resulting promise tree, so that the
results of the previous computations can be conditioned.  

I really did this for distributed messaging.  There is a way to queue up
message sends, for some time interval, and send them in bulk to the
remote object.  This would cut down on yoyo traffic and cut all the
interveaning latency out of the block of computation.  Since it is
asynchronous, users are forced to condition for failure and won't lock
up the image while waiting.

I saw a stork once, but they are very, very fast, when making a
delivery.  hmmm...forwardingBlocks.  What trickery is this!?  :)


Rob

ps.  I updated the eventual send page with a big renaming of classes to
match the diagram.  Next step is the RemoteSecretary, serialization, and
sockets, plus the requisite RemoteContext and RemoteResolver.

Brian Keefer <mgomes21 at cox.net> wrote:

> 
> I consider it silly because I am only following my aesthetic sense in
> making it. I have no practical project to actually use and test it in.
> Experiencewise, I still believe that new object instances are delivered by
> a stork ;) .