Re: Some small requests for the next release
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Some small requests for the next release
- From: Rici Lake <lua@...>
- Date: Wed, 2 Mar 2005 16:10:02 -0500
On 2-Mar-05, at 2:35 PM, Mark Hamburg wrote:
The difference between math.nan and nil is that you can perform
arithmetic
on math.nan.
That's currently true but it could easily be changed; simply substitute
a NaN for nil in arithmetic computations. However, there is a more
profound difference:
nil == nil ==> true
NaN == NaN ==> false
Were it not for that, I would advocate making nil and NaN the same
thing.
I could live with breaking that particular IEEE-749 oddity but there
are actually good reasons for it, or at least reasons some people think
are good. Worth thinking about, though.
I could personally also live with nil having the semantics described
below, rather than create yet another special case. I don't think it
would be awful for nil[x] to be nil rather than throwing an error;
however, there are good reasons for throwing the error as well (or at
least reasons some people think are good). I do not believe that it
would be a good idea to silently return a different special value,
though: either throw an error or return nil.
Actually, it would be sort of cool to have a NaN equivalent for other
operations. Call it NotAValue and perhaps it's actually the same as
NaN. For
example:
x = nil
y = x.field
y is now equal to NotAValue.
That would, however, change the semantics with respect to error
detection.
Mark