> > Let me make it clear: AFAIK Perl NaN's will not be IEEE 754
> > compliant. That was certainly my intention in suggesting them to
> > Larry. I share the view of a number of other language designers that
> > the non-self-identity of IEEE NaN is (to slightly misquote Tim)
> > "ugly, non-intuitive and ugly; and non-intuitive too".
>
> But NaN could already be argued to be ugly, non intuitive and ugly.
> When you compare two indeterminate quantities (if quantity is even the
> right word) then expecting them to be equal is somewhat surprising.
I see your (and others') point here, but I view NaN as a *marker* indicating
a non-numeric result. Markers should always compare equal to themselves.
(Frankly, *everything* should compare equal to itself -- which is where
IEEE 754 goes horribly wrong.)
> Maybe NaN is a misnomer, since NaN already has a defined meaning in
> this context, the IEEE sense. Changing its semantics in a perl context
> is surely a recipe for confusion (assuming you're not already confused
> by the IEEE behaviour).
I suspect the number of people who know and understand the current IEEE
semantics is relatively small, compared to the number of people who
would be freshly confused if we honoured it in Perl 6.
I would dread to have to explain why:
$value == NaN;
produces the opposite value to:
$value.isNaN;
(and only in the important case).
> Trouble is, I'm not entirely sure what a good name for this would be.
C<NaN> is a good name. We just have to wrest it back from the corrupting
clutches of the bit-twiddlers!
Though, I confess, I wouldn't be averse to seeing a C<fail> value in Perl. ;-)
Damian
