Auto-promotion of Integer to BigInt
Austin_Hastings at Yahoo.com
Wed Nov 11 02:58:49 UTC 2009
I concur. Autopromotion is a HLL decision, and likely to be implemented
in a variety of hll-specific ways (or not implemented, as the case may
be). At the most basic Parrot level, I think the types should stay
segregated, and should throw an exception or something if they are going
If there is an "obvious" autopromotion strategy, I think the HLL guys
(which technically includes me, but I know when my clue-meter reads zero
and this is one of those times) will be the ones able to tell us. Then
the basic types can be made "autopromotion-ready". Maybe we can put a
logo on them or something.
Andrew Whitworth wrote:
> If I had my druthers, I would disable autopromotion of Integer to
> BigInt. I agree that it's easy enough to flag on overflow and to
> manually promote to BigInt if necessary. I don't suspect many people
> will agree with this.
> --Andrew Whitworth
> On Tue, Nov 10, 2009 at 1:11 PM, Martin Kealey <martin at kurahaupo.gen.nz> wrote:
>> I'm looking at the test suite for BigInt, and it includes some tests that
>> Integer gets promoted to BigInt when the result would be out of range.
>> I tried adding tests for "neg" and "abs" and they failed, so obviously
>> there's an implementation issue.
>> But beyond that, is there a good reason why Integer's behaviour should
>> differ from int? I mean, if someone wants BigInt behaviour (even for little
>> numbers) they only have to ask for it. Conversely, how else does one box an
>> Also autopromotion does nasty things to representational constancy (bad for
>> So I'd like @parrot_dev's advice: do I go ahead and put in tests for
>> everything assuming that autopromotion will always happen when needed, or do
>> we rip out autopromotion entirely? Or perhaps fork Integer into Int (boxed
>> int) and Integer (small BigInt)?
More information about the parrot-dev