Re: Some small requests for the next release

[Rici Lake <lua@...>]

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