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