Auto-promotion of Integer to BigInt

Andrew Whitworth wknight8111 at
Wed Nov 11 13:16:48 UTC 2009

On Tue, Nov 10, 2009 at 9:58 PM, Austin Hastings
<Austin_Hastings at> wrote:
> 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 to overflow.

That's my thought exactly. Any autopromotion decision (or any kind of
automatic decision making) that Parrot does will work for some HLLs
but not work for others. Matrixy, for instance, would prefer
saturation on integer overflow. Other languages may want autopromotion
to Float or something like that. Parrot really just can't know what
HLLs are going to need and attempts to make decisions like this
automatically are more likely than not going to be wrong.

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

Being able to specify a behavior on overflow to serve as a default
might be nice. Being able to specify a type to use for autopromotion
would be good. But again, in the case of Matrixy, we want saturation,
not autopromotion (although I fully intend that we will have to
develop our own types anyway).

--Andrew Whitworth

More information about the parrot-dev mailing list