Re: Different shades of false

[Gavin Kistner <gavin@...>]

On Mar 2, 2006, at 7:32 AM, Alen Ladavac wrote:
> In the original Lua, 0 was logically true, because the only  
> logically false
> value was nil. That made sense. But since the introduction of the  
> boolean
> type in Lua 5, there is a slight mess in what is actually logically  
> false, causing me to reconsider on the idea of 0 being logically true.
> [...snip...]
> For interfacing with C programs, and for general convenience of the
> scripting user, we are considering patching the lua in our app, to  
> have zero
> and empty string mean the same thing (logically) as false as nil  
> currently
> do.

To help the discussion, I think there are two, separate, arguments here:
1) I'm confused that there are two non-truth type/values, and
2) I'd like Lua to match C for easier interfacing.


My personal view on these:
1) On the one hand, it seems arbitrary to say that four non-truth  
values is better than two. From a purist standpoint, it would make  
sense, I think, to insist on exactly one.

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.

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) {}. Now it's easy to tell if a value is 'empty', but  
harder to tell if it's present than before. Which use case is more  
common? Which paradigm are the majority of Lua scripters more likely  
to expect? (C users lean one way, Ruby users another...and who knows  
which way new users lean.) Even _if_ the current situation makes it  
harder to perform the more common tasks, is the confusion and  
compatibility break the the change would effect worth the benefits?

Further, the concepts of truth/non-truth and present/empty are  
intertwined, but separate. Do you really want to collapse them  
together? There are cases where it would be convenient to test a  
value for emptiness by treating it directly as a truth value. More  
often (for me) I prefer the distinctness. If you want a catch-all,  
how about writing an 'empty()' function that wraps it all up for you,  
testing the type/value pairs that you like?


2) I can see how this would be convenient, if your C programs are  
using 0 or "" to mean 'false'. In my company, there is a group of  
people who write C(++), and a group who use the Lua bindings they  
provide. Though I coded in C 10 years ago, I no longer have to deal  
with it, so I personally have no need for Lua to ape C. (In fact, I'd  
rather it didn't.) Further, the Lua bindings abstract values and  
methods from the C++ side, so an appropriate Lua binding (for me) is  
not to have raw access to values in the engine, but to provide lua- 
like wrappers for them. This includes things like providing table- 
arrays that start at 1 (and not 0), and would include provide proper  
Lua boolean representations for values that may be stored differently  
in C++.


So, I'm generally arguing to keep things the way they are, with a  
huge dash of "discuss how it affects the usability of the language  
before deciding".