At 5:56 PM -0800 1/22/07, Larry Wall wrote:
Whether a Num that happens to be an integer prints out with .0 is a
separate issue. My bias is that a Num pretend to be an integer when
it can. I think most folks (including mathematicians) think that
the integer 1 and the distance from 0 to 1 on the real number line
happen to be the same number most of the time. And Perl is not about
forcing a type-theoretical viewpoint on the user...
Up front, I will say that, all this stuff about 1 vs 1.0 won't matter
at all if the Int type is an actual subset of the Num type (but whose
implementation is system-recognized and optimized), meaning that Int
and Num are not disjoint, as "most folks" usually expect to be the
case, such that, eg, 1 === 1.0 returns true.
Of course if we did that, then dealing with Int will have a number of
the same implementation issues as with dealing with "subset"-declared
types in general.
I don't know yet whether it was decided one way or the other.
Whereas, if Int is not an actual subset of Num, and so their values
are disjoint, then ...
FYI, my comment about a stringified Num having a .0 for
round-tripping was meant to concern Perl code generation in
particular, such as what .perl() does, but it was brought up in a
more generic way, to stringification in general, for an attempt at
some consistency.
Whether or not that is an issue depends really on whether we consider
the literal 1.0 in Perl code to be an Int or a Num. If, when we
parse Perl, we decide that 1.0 is a Num rather than an Int such as 1
would be, then a .perl() invoked on a Num of value 1.0 should return
1.0 also, so that executing that code once again produces the Num we
started with rather than an Int.
On the other hand, if .perl() produces some long-hand like "Int(1)"
or "Num(1)", then it won't matter whether it is "Num(1)" or
"Num(1.0)" etc.
-- Darren Duncan
