I should be clearer.  Since my email service is hosed up, this may  
very well post 2 hours after I send it.

On Oct 13, 2007, at 6:32 PM, Robert Withers wrote:

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

I considered taking the approach you describe for all primitives/ 
bytecode methods.  There are problems with it, I think:
1) doesn't deal with bytecode methods called by special selectors.   
Doesn't this bypass the #+ method and its primitive failure code?  It  
has been my understanding that dealing with bytecode methods would  
require vm changes.
2) Would require lots of double dispatch coding for those selectors  
that don't currently use them.  This problem is compounded if there  
is more than 1 argument.
3) Doesn't deal with named primitives that are not currently in the  
image.  My hope is that I can make vm changes when primitive dispatch  
occurs prior to entering the named primitive function.  Verify all  
args on the stack at this point and do the eventual sending prior to  
activating the named primitive.  Is this even possible?  If so then  
perhaps it is possible for indexed primitives too.
4) Difficulties in finding all methods specifying a primitive.

This is all I can come up with at the moment, but these are some of  
the thoughts which have steered me to consider changing the vm.

Rob