• Subject: Re: Different shades of false
• From: Ryanne Thomas Dolan <rtdmr6@...>
• Date: Thu, 02 Mar 2006 14:14:22 -0600

I guess my wording was ambiguous.  Sorry if I confused anyone.

I did not mean to suggest that "" == 0 should evaluate true.  I posed the question "Would it make sense at all if "" == 0?" to suggest that if changes were made to Lua such that "" == false and 0 == false, then "" == 0 would be a logical consequence, which doesn't make any sense at all (to me).  Indeed, I think "" == 0 makes a lot less sense than false == nil, and I am very glad that neither _expression_ is true in Lua.

I just wanted to clarify that I am siding with the first argument and didn't mean to bring up the second.  Thanks for catching my mistake!

On Thu, 2006-03-02 at 21:00 +0100, Tobias Käs wrote:
```Dolan, Ryanne Thomas (UMR-Student) wrote:

>Exactly.  The only problem with nil/false is that people use these values incorrectly.  nil is by no means synonomous with false, so it makes sense that nil ~= false.  Being false and not defined are two very different states.
>
>And the proposal that all types should have true/false values seems strange to me, as anything with true/false evaluations is by definition a boolean, which Lua of course already has.  Would it make sense at all if "" == 0?
>
>
You are contradicting yourself here ;-)
At one point you say nil ~= false because they have different meanings.
At the other point you argue "" == 0 incase 'if' treats them the same.

If you stand by the first argument, you would consequently have to say
"" ~= 0
If you stand by the second argument, you would have to say nil == false

As already has been pointed out, nil and false being different has some
So if you say "undefined" evaluates to "false" in the context of an 'if'
(even though they are not the same), you could as well say "empty"
should evaluate to "false" in the same context.

Since the ambiguity already exists it wouldn't make things much more
worse I guess ;-)
Though in the end it probably is just a matter of taste which you prefer.

>So long as you take the convention that nil means something like "undefined" then everything makes sense the way it is.
>
>

```