Re: Another nil/false proposal

[David Jeske <jeske@...>]

I apologize to everyone because this has already been hashed and
rehashed. If people would prefer we take this off list, just say so,
and I'll followup individually from now on.

On Mon, Jan 14, 2002 at 06:58:58PM -0500, RLake@oxfam.org.uk wrote:
> > I thought I had to use your new operators both when I put nil into a
> > table AND when I try and take it out.
> 
> That depends on what you are going to do with the results, I
> suppose. Let me be clear: I'm not saying you have to use the new
> operators at all. I'm not suggesting that boolean values be changed
> in any way. I'm suggesting that nil continue to be the (unique)
> false value. So existing boolean expressions need not be changed at
> all, and neither does putting boolean values in a table unless you
> find it annoying that the false value is indistinguishable from a
> non-existent key...

It's not that I find it annoying. It's that I find it non-functional
with no easy workaround.  Using the proto-inheritence which is
supplied as an example in the lua manual, the following code does not
work:

  true = 1

  a = {
    isMarried = true
  }

  b = {
    parent = a
    isMarried = nil
  }

  if b.isMarried then
    print "this is an error"
  end

The only way (that I can find) to make this work, is to use "0" as
another false value, and to change all tests to "~= 0". Which means
that an if statement now ALWAYS looks like:

  if (b.isMarried ~= 0) and (c.isMarried ~= 0) then
    print "arn't boolean tests annoying now?"
  end


You can say what you want, but in this case "0" is a false value, and
I should be able to drop it into a boolean test and have it come out
as false.

Perhaps I didn't understand where you were going with your operators,
but as far as I can tell, your proposed operators did not fix this
problem, as they would have to be used just as often as the "~= 0"
test.

> I agree, and that's why I don't think false is necessary. However,
> the world is not always that simple, as various people have pointed
> out.  Sometimes you need to put a value in the table without knowing
> whether it's a boolean or not. 99.9% of the time that is not the
> case, which is why I said that 99.9% of the time you don't need the
> operators.

The trouble with your operators, as I see it, is the same trouble with
the ~= 0 test. You need to know beforehand whether the item you are
getting back will be a boolean value, in order to correctly handle it
in a boolean test. If anything, your operators make it worse, because
now you have to know whether or not it's a boolean value just to store
it in a table.

> So what to do? I find the addition of "false" to the language a bit
> annoying because it changes the semantics of a = a or default which
> is an idiom I use a lot, and because it doesn't strike me as either
> clean or elegant. 

Certainly that is a difference between you and I as I never use the
"or" idiom you point out above. However, I did suggest the creation of
a new operator which is intended to do what you're doing above. It
seems the biggest trouble is coming up with a name for it. :)

> I was suggesting an alternative to that, which as I said, would be
> invisible 99.9% of the time and easy to use the other 0.1% of the
> time, and which had no impact on (my) existing code. However, I
> noted that it solved a couple of existing problems as well: the
> idiom a and b or c is frequently used by Lua programmers (as the
> C-operator a?b:c) but if fails precisely in the case where b is
> nil. In addition, as Roberto pointed out:

I really think that the current nil behavior is broken 50% of the
time, that is, every time nil is used as false in a boolean variable. 

For example, I have code which walks tables in order to facilitate
exploratory programming and poking around from within my program. The
trouble is, whenever booleans were set to nil, they didn't show up in
the introspection anymore! Too bad, you only get to find out about the
possible properties when they are true. Same thing with global
variables. The code to USE the global variables is still there, but
suddenly they are erased from existance, just because someone decided
to make them false.

I personally hope that with the introduction of a boolean type, people
completely stop using nil for anything other than deletion, becauase I
think the Lua world will be a more sane place for everyone. :)

<sarcastic jibe>
Then, if we can just add exceptions and build a module system, we'll
be 1/2 way to Python! (where I write most of my code these days)
</sarcastic jibe>

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net