lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
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

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".