Robert Withers a écrit :
> 
> On Oct 13, 2007, at 6:14 PM, tim Rowledge wrote:
> 
>>
>> On 13-Oct-07, at 3:55 PM, Robert Withers wrote:
>>
>>> The problem I perceive I have is when we have (4 + 5 eventual).  
>>> There is nothing that intercepts it.
>>
>> Err. 4 + {some not-integer-not-float} will fail. It will get trapped 
>> in the prim failure code for SmallInteger>+ and the {some 
>> not-integer-not-float} will be sent #adaptToInteger:andSend: which 
>> rather usefully includes both the original 5 and the #+ selector. 
>> Seems like a perfect opportunity to build a promise and return it, no?
>>
>> That looks like intercepting your problem to me, how about you? I 
>> think you're probably making this far more complex than it needs to be.
> 
> Well, Tim, it seems this may be the extent of the comments you are 
> willing to make on my problem.  I can understand you not wanting to get 
> too deep on the issue, still it disappoints me.  I spent some effort 
> trying to explain my problem clearly.  I hadn't even described the hard 
> problem yet, which is having eventual sends in a context with multiple 
> returns.   Unfortunately, my original question remains unanswered: how 
> can I execute bytecodePrims and primitives from the image?
> 
> To test the possibility of doing this in the image with the example we 
> were exploring (4 + 5 eventual), I loaded up SqueakElib for the first 
> time in well over a year, to see what happens.  I knew it didn't succeed 
> for some reason.  It blows up with a #mustBeBoolean error when it gets 
> inside of:
> 
> Integer>>#+ aNumber
>     "Refer to the comment in Number + "
>     aNumber isInteger ifTrue:
>         [self negative == aNumber negative
>             ifTrue: [^ (self digitAdd: aNumber) normalize]
>             ifFalse: [^ self digitSubtract: aNumber]].
>     ^ aNumber adaptToInteger: self andSend: #+
> 
> Because aNumber is eventual, sending #isInteger returns a promise which 
> is the receiver for the inlined #ifTrue:.  The promise is not a boolean 
> (yet), so it errors out with #mustBeBoolean.
> 
> So, at the very minimum I will need to make ifTrue:, ifFalse:, 
> ifTrue:ifFalse:, and ifFalse:ifTrue: all special selectors and 
> normalSend them.  Here are the bytecodes for the above method, and line 
> 43 represents the ifTrue, I believe (why are the line numbers starting 
> with 41?), although knowing which flavor of if it is seems to have been 
> lost when compiling.  Bytecodes for the #ifTrue: emitted by the 
> MessageNode somehow (emitIf:on:value:).  I looked for where #+ is 
> encoded as bytecodePrimAdd, but couldn't find it.
> 
> 41 <10> pushTemp: 0
> 42 <D4> send: isInteger
> 43 <AC 0F> jumpFalse: 60
> 45 <70> self
> 46 <D3> send: negative
> 47 <10> pushTemp: 0
> 48 <D3> send: negative
> 49 <C6> send: ==
> 50 <9C> jumpFalse: 56
> 51 <70> self
> 52 <10> pushTemp: 0
> 53 <E2> send: digitAdd:
> 54 <D1> send: normalize
> 55 <7C> returnTop
> 56 <70> self
> 57 <10> pushTemp: 0
> 58 <E0> send: digitSubtract:
> 59 <7C> returnTop
> 60 <10> pushTemp: 0
> 61 <70> self
> 62 <26> pushConstant: #+
> 63 <F5> send: adaptToInteger:andSend:
> 64 <7C> returnTop
> 
> 
> This method (Number>>#+) also contains multiple returns, illuminating 
> the hard problem, since eventually sending doesn't know in advance what 
> the result of executing conditional logic will be, it needs to be 
> prepared to execute all branches and when one succeeds, to bail on the 
> other possible branches.  I'm not sure what I will do about this.
> 
> Rob
> 

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.

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...).

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)?

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

Nicolas