"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Fri, Apr 23, 2004 at 02:50:42PM -0400, Austin Hastings wrote:
> : Sure, but "You haven't provided a value yet." doesn't seem very ...
> : exceptional.
>
> The important thing will be "You didn't provide a value at line 42, though
> you didn't actually try to use it till line 582."
Just wondering, are we going to have semantics similar to the old NaN Vs
Signaling-Nan in IEEE floating point? An IEE NaN has an N-bit field where
the source of the NaN can place a value representing the reason for the NaN.
It can also set a flag which selects between two behaviors:
* normal NaN: If you attempt to use the NaN in any calculation, then you'll
get back the original NaN (the defined semantics are actually a bit fuzzy
here -- an implementation is permitted to lose any information that you
embedded in your NaN. But presumably, if your hardware inserts a value, it
also knows not to trash it).
* Signaling NaN: If you attempt to use the NaN in any calculation then you
get an FP exception. If you have set your processor to trap on exceptions,
then you get a trap.
I'm not sure how much of this is relevant to C<undef>, but it might be nice
to have the ability to have an undef that says "if used, then trap" (using
the current "use fail" mode -- if that still exists)
Dave.
ps. as an aside, it would be really nice to have support for
getting/handling numeric exceptions -- even for things like an overflow
("carry") on a primitive "int". As a bonus, an "int" with saturation
semantics (cf the normal modulo semantics) would be nice, too. I think that
would need parrot-level support to be efficient.
