show bytecodes?

Robert Withers reefedjib at yahoo.com
Sun Oct 14 01:32:06 UTC 2007


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?

This one could be done using double dispatch to the eventual arg,  
'tis true.  But what about the following, just as additional examples?
	primitiveAt
	primitiveAtPut
	primitiveNextPut
	primitiveStringAt
	primitiveStringAtPut
	primitiveStringReplace
and what about all the named primitives in various plugins?

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

There is no question that I am making it complicated, but I am trying  
to have all primitives/bytecoded special selectors be eventual safe.   
Since we are considering changing a fundamental invariant of the vm,  
and saying that a reference does not have to have immediate  
evaluation semantics and can be a promise with no current value, it  
is no surprise that it is complicated.  This is undoubtedly confusing  
my thinking and my solution.

Rob




More information about the Squeak-dev mailing list