Re: Different shades of false

["Alen Ladavac" <alenl-ml@...>]

> 1) On the one hand, it seems arbitrary to say that four non-truth
> values is better than two.

A friend of mine said wisely that it might not be better, but it certainly 
is not worse.  :) As having two of them is really non orthogonal to start 
with.

> From a purist standpoint, it would make  sense, I think, to insist on 
> exactly one.

But if nil is not that value, you'd be in serious problems as lua relies on 
the notion of not having runtime errors due to nils, and nil not being true 
saves it there. One solution would be to banish "false" from the boolean 
type.

> On the other hand, false is obviously not true, and (I think) nil is 
> likewise obviously not true. So if you were going to pare it down,  you'd 
> need to get rid of one or the other. I, personally, don't want  to get rid 
> of either. So I think we're stuck with more than one non- truth value.

Why not getting rid of false altogether? Isn't that much more orthogonal 
than the current situation? (I mean, I'd rather seek orthogonality in the 
other direction, but I'm interested to know whether you have some reasons 
for this.)

> So, then...why not go hog wild? If we've got two, let's shoot for one 
> 'false' value for each primitive type. nil, false, 0, "", and (for 
> consistency) {}.

You are right. Empty table should be considered as well, for consistency.

> Now it's easy to tell if a value is 'empty', but  harder to tell if it's 
> present than before.

It is not any harder. It is equally as hard, because false is already 
deceiving you. I'd just like to point this out by requiring foo~=nil to be 
used for presence, as just foo is not correct starting with lua 5.

> 2) I'd like Lua to match C for easier interfacing.

Really, this has more to embedded scripting in general than with C. I'm 
confident that everyone perfectly understand the concept of 0=false, 1=true, 
and that it is natural for that to be used in configuration scripts and 
similar. In all our previous projects, both in-game console commands and 
configuration scripts support a notion of booleans as 0/1. People are used 
to type some_config_var=1 or =0. If =0 started to _enable_ stuff, we'd have 
a lot to explain to the users. Duck-and-cover kind of explaining. ;)

One addition to this argumentation that now becomes obvious to me: As I see 
it, if we want orthogonality, then it is either (a) add one falseness for 
each type or (b) remove false from boolean type. Now, removing false from 
boolean gives a weirdness of not be able to verify whether a boolean 
variable is present. In this line, I only see more arguments for (a).

Alen