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
|