[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Should NaN be false? (Was: Re: simple question about NaN ...
- From: Dirk Laurie <dpl@...>
- Date: Wed, 23 Feb 2011 08:38:56 +0200
On Tue, Feb 22, 2011 at 07:41:46PM +0200, Renato Maia wrote:
> On 21 Feb 2011, at 18:37, Dirk Laurie wrote:
> > (a) NaN is to numbers what nil is to Lua values: not-a-number vs
> > not-a-value. It makes intuitive sense that it should be
> > logically
> > different from numbers.
> OK, but why this implies NaN should evaluate to false?
Not "implies", but "makes intuitive sense".
There are three options.
1. NaN is true.
2. NaN is false.
3. Trying to convert NaN to boolean is an error.
Option 3 is expressly designed out of Lua: everything must be
convertible to boolean. There are pros and cons to 1 and 2:
Pro 1: type(NaN)=='number'
Con 1: but NaN means 'not a number'
Pro 2: all situations in which NaN's arise are exceptions
Con 2: it is not the status quo
> Apparently, Lua authors regret that nil evaluates to false : "Not
> introducing booleans from the start had a few unfortunate side-effects.
> One is that we now have two false values: nil and false."
Suppose that booleans had been introduced from the start. Which
would the authors have chosen?
1. nil is true.
2. nil is false.
3. Trying to convert nil to boolean is an error.