Hi Nicolas,

On Oct 15, 2007, at 3:25 PM, nicolas cellier wrote:

>
> Doing this, you will inline code until the viral #eventual message  
> has contaminated every other message receiver.
> Risk is to end up with huge unmanageable expressions.

It's true that it seems that an eventual ref will contaminate method  
contexts and objects which come into contact with the eventual ref  
and that that could spread to all references and activations within a  
process.  While I haven't thought through this viral aspect that  
deeply, my hope is that some way could be found to inoculate as fast  
as they get contaminated or otherwise limit how much gets contaminated.

> You don't have to develop all possible branches... #ifTrue:ifFalse:  
> would result in an EventualMessageSend with 5 eventual as receiver  
> and some blocks as argument, once you know how to recompile with  
> optimization off (You should also consider NewCompiler for  
> compiling blocks...).

Yes, but one or both of these blocks (both in the example given) may  
have a return statement, which would return from the method context  
that called ifTrue:ifFalse:.  So I am thinking that context needs to  
be infected as an eventual context and generate a promise:resolver  
pair such that an internal return, like the one in the block above or  
the one at the end, would resolve the promise.  Also, all statements  
in the context would need to be eventually sent, and all refs would  
need to become eventual, to maintain msg ordering.  I think.

>
> Shouldn't you concentrate on resolving the promise as a kind of  
> message send at highest level possible, like (4 + 5 eventual)  
> resolve in (EventualSend receiver: 4 message: #+ argument: 5  
> eventual)?

Yes, but you have already made it viral by making the #+ be sent  
eventually.  What I am saying instead is making that happen from  
inside the implementation of #+, and it is occurring because inside  
of that implementation is is sending ifTrue:ifFalse: which is a  
primitive/bytecodePrim.  Not making normal activations eventual, but  
just activations that contain a primitive call, was a way I was  
planning to limit the viral nature.  Your point about full  
contamination may trump this hope.

>
> That's however quite a challenge...
> Maybe an ExceptionHandler trapping the Eventual>>doesNotUnderstand  
> to backtrack thisContext stack while an eventual argument has been  
> passed...

That's an interesting idea.  Then we would be explicitly infecting  
all contexts on the stack, but perhaps it could be done without much  
VM work.  I still need to get ifTrue: and friends (and possibly  
others like #whileTrue:) to normalSend their selectors if they fail,  
so I can intercept the msg send and make it eventual.  Then we can  
start playing with it.

Cheers,
Rob