On Apr 13, 2007, at 14:35 , Klaus D. Witzel wrote:
On Fri, 13 Apr 2007 13:39:08 +0200, Bert Freudenberg wrote:
On Apr 13, 2007, at 13:27 , Klaus D. Witzel wrote:
Hi Bert,
on Thu, 12 Apr 2007 18:31:55 +0200, you wrote:
This is actually wrong.
:)
Only SmallIntegers are special [*].
What happens is this: When you add two SmallIntegers (like "3 +
4"), and the result is a SmallInteger, the result is calculated
in the bytecode directly. Otherwise, a regular send of #+ is
performed.
Right.
From there, everything else happens in the image,
Not really. (Integer>>#+ aNumber) sends (self digitAdd: aNumber)
which is implemented as <primitive: 'primDigitAdd' module:
'LargeIntegers'> which is part of the VM. Of course the
LargeIntegers module may be absent, have failed to load, may not
like the argument, etc.
No, this is an *optional* primitive. It's there purely to speed up
computation and can be safely removed.
Sure, but this thread is not about what happens when the optional
primitive is removed, and I was not reflecting that, either. I was
rather discussing the point when the primitive does *not* fail on
one of Patrick's subclasses and, what the returned species is.
You could change the Integer classes to handle subclasses properly
(via species etc.). So far, this has not been necessary. My point
was that this (unlike SmallIntegers) is *not* hard-coded in the VM.
I think it depends on operand order. When the LargeIntegers module
is invoked (in my previous example when sending + myLargeInteger to
SmallInteger 1) then a "hard-coded" instance of
LargePositiveIntegers is returned.
The attached class can be used (together with my previous example)
to illustrate my point. The class does not inherit from some
default large integer class and the primitive does not fail,
regardless of operand order. I hope I didn't base my argument on a
bug or mistake.
I don't see your point. Do you want the primitive to fail for your
class? This is outside of its spec, so to say. Do not use the
primitive if you are not satisfied with its behavior.
FWIW I do not disagree with anything about your argument, except a
bit with "hard-coded".
It is not hard-coded in the VM, exactly as I wrote above.
SmallInteger arithmetic is hard-coded: There is no way to generally
redefine SmallInteger>>+ unless you modify the bytecode interpreter,
because method is never actually activated unless you use #perform:,
or the result is not a SmallInteger.
But you are free to redefine what happens outside the realm of
SmallIntegers. Invokation of the LargeInteger primitives is
voluntary, you are not forced to use them.
- Bert -
| 