[Squeak-e] eventual references and promises. What's an alternate compiler solution to deal with promise continuations?

[Robert Withers]

Hi All,

Does the rubber band nature of eventual message sending, especially now 
that #immediateRef is working, help provide an interesting interface 
for users?  I don't know if people are aware of the way I adopted 
Mark's E eventual sending.  This is especially true since I really 
haven't written any documentation on it.  :(

Here's an attempt at an introduction to them:  From reading ( 
http://www.erights.org/elib/concurrency/msg-passing.html ), I got very 
excited.

In E, with specialized syntax, an expression like  "person <- 
computeCreditRating()"   would eventually send the message and 
immediately return a promise for the result.  This promise will 
'become' the result of the eventual send.  This requires a promise 
continuation to be sent with the message, so that the evaluation will 
resolve the promise.

Before that happens, your subsequent code can send messages to the 
promise or the original eventual reference.  There are special messages 
that you can send to synchronize with the result.  There is a way to 
write code that waits until a set of promises are resolved, before 
doing further work.  This allows you to synchronize the results.

To try this I decided that building a trampoline that you could send 
messages to as a surrogate to the real object would allow us to trigger 
eventual sending just by slightly changing the sending context.  This 
sending context was scoped to that object reference that built the 
context for you, when you sent #eventualRef to the object reference 
that will be your receiver.  This way, we don't need special syntax to 
invoke eventual messages.  The machinery of ScriptScheduler and 
ScriptProcess, allows an implementation of #immediateRef to work.  This 
is the first step toward adding the synchronization features.  The next 
step would be to synchronize multiple promises, but I don't have a 
solution in mind, yet.  Anyone have an idea?


[Context implementation]
I also want to discuss how to improve my contexts.  Maybe it is 
possible to have a perfectly contained reference to an object and use 
#dnu and a special class for promises.   I demonstrated that with 
changes to the bytecodePrimitiveClass and bytecodePrimitiveEquivalence 
methods, that double-dispatch equivalence and class as a message send 
allow surrogates to really stand in for eventual objects.  Is there a 
way to do this without changes to the vm?

For efficiency, I had also thought that with the above description of 
promises and their continuations, on Erights, these references could be 
defined precisely enough to put into the vm.  If you look at my 
vm-redirectors changeset, you can see that I came up with a pretty 
clean approach to intercepting message lookup.  I use the 
compactClassIndex to register the Messageredirector class and be able 
to quickly determine this in the vm.   Using the same strategy, we 
could have special eventual send references, and promise references, 
that the vm could detect, then the vm could execute different lookup 
strategies and manage all special reference creation and resolver 
activation.

We still need a way to implement far references and their promises so 
that the captp and vatp machinery can be interfaced.  Are these 
references in the vm?  Yes, but only to redirect the message send like 
I do in Referencecontext.  See #redirectMessage: for the entry point 
from the vm redirector (or the 
MessageRedirectionProxy>>#doesNotUnderstand:).    I am bothered 
fundamentally by having to use #immediateCallSelectors and 
#eventualControlSelectors to choose how to send the message.  I thought 
that Anthony's work or Traits or MethodWrappers would be some 
alternatives to replacing this mess.


see ( http://swiki.squeakfoundation.org/squeak-e/3 ) for SqueakElib, 
Scripting and the bridge code to see how #immediateRef behaves.

cheers,
rob