> Assuming that the perl parser generated IV SVs rather than NVs for
> the 2 constants 2,3, then my scheme would handle this fine; the IV
It currently does so.
> version of add() would be called, and an IV SB would result.
"The IV version of add()"? Beware of combinatorial explosion:
addII, addIU, addUI, addUU, addIN, addNI, addNN, addblahbah....
> However, my current scheme crashes and burns for the following:
>
> $a = 2;
> $b = 33;
> $c = $a ** $b;
Would work just fine in my 64-bit Alpha box :-)
> The way perl5 handles these cases is that $a + $b, $a * $b etc just
> silengly ignore any overlow and return an int, while $a ** $b appears
> to automatically upgrade to a float. My system currently says nothing
Yup. Welcome to the wonderful world of unsolicited and surprising
type conversions.
> I presume that with bigint in force, even
>
> $x = 2
> would make $x a bigint?
Not necessarily. The tokenizer is able to tell the difference
It currently does this by using UVs if a positive IV wouldn't
be enough, and NVs if even a UV wouldn't be. 'use bigint' could
be a hint saying "don't go NV unless absolutely unavoidable", such
as "sin(2)". For division such as 2/3, NV could still be be default
unless a "use bigrat" is in effect.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
