Re: Unexpected behavior with "not not"

[Rici Lake <lua@...>]

On 30-Jun-05, at 12:47 PM, Wim Couwenberg wrote:

> The compiler makes the following substitutions if nil, false or true
> are encountered as *constants*:
>
>         not nil --> true
>         not false --> true
>         not true --> false
>
> so "not not nil" is directly emitted as "false".  (See the codenot
> function.)

Also, not 6 is directly emitted as "false" and "not not 6" is directly
emitted as true. (The optimisation is not <any constant other than nil 
or false>).

> On the other hand, "not not <expr>" is replaced by "<expr>", so "not
> not (nil and true)" is replaced by "nil and true" which evaluates to
> nil.  (See the jumponcond function.)

Not quite true ... it only happens during boolean evaluation. Compare:

> =not not (a + 1)
true
> =not not (a or 6)
3

The not not is eliminated in the second case because it's evaluated
in a boolean context, thanks to the "or".
> I'd guess that this was an oversight when introducing true and false
> in Lua 5?

I guess the oversight, if you like, is the "not not" optimisation.
Of course, the truth value of the expression is correctly computed,
but the statement in the reference manual that it always returns
'true' or 'false' is not 6 :)

On the other hand, I've never really liked that 'not not' idiom.
Coercing to a boolean should never really be necessary imho.


> (I hope this explanation is at least somewhat accurate...  :-)  )