RE: nil isn't as unique in Lua 4.1

[RLake@...]

John McKenna escribió:

> It wasn't a question.  It was an example.  I know that there are ways
> to work around the problems that I was attempting to demonstrate, but
> they are still work-arounds.

"How do you store "false"?" looks like a question to me :-) I was trying
to be helpful.

> >Define the global false={} and test for its existence.

> A "false" value that can't be used in boolean expressions is hardly a
> solution.

It can easily be used in boolean expressions:

  if a ~= false or b ~= false then ... end

It just doesn't have the truth value you might expect it to have :-)

> I posted three examples where there is a need for a distinction between
> "doesn't exist" and "false".  There are many others.  Yes, in each
> particular case there's a way of working around it.  But in general
> you'll need to come up with a new method every time you hit the
> problem.  They're not intuitive.  They hide what the code is really
> doing.

I dunno. I came up with one way of dealing with it, and it works pretty
generally. I hide the mechanics in tag methods, so the code really does
what
it looks like its doing (as with other stuff hidden in tag methods). I
really
don't find that I have to work around the problem much, to be honest.

I think that in at least two of the examples you gave, you did not actually
want to
distinguish between nil and false. You wanted the underlying mechanics to
distinguish between nil and false. If you're memoising a boolean function,
for
example, you don't care whether the memoiser knows that the answer is false
or
has to work it out. You just want an answer which is true or false. (And
that's
why I wrote the memoiser generator that I outlined). Similarly, when you're
doing
inheritance, you (as a consumer) don't care whether the nil/false was
direct or
inherited. In both of these cases, the visibility of that fact out would
defeat
the point of isolating the mechanics from the use.

You might, of course, want to know (for any value, not just nil/false)
whether
it was going to take a long time to compute or not -- say, in an
interactive
environment. But that is a separate interface. ("known", maybe). I have a
memoiser version which does that, too, if you're interested.

Now, Markus Huber's example is more interesting. He wants to know whether
or not an argument is false or omitted, so he can provide an "explicit
false".
Adding "false" as a false value means that I can no longer simply test for
a defaulted parameter, though -- now I *have* to consider the case that it
might be an explicit false. So a workaround is required in either case: the
questions are, which cases are more common, and which base solution is more
elegant. I argue that the "single-nil" solution is more elegant, and the
cases
where you need an explicit false are rarer than the cases where you don't.

It is, in fact, one of my pet annoyances with the base Lua library that
some
functions actually do distinguish between explicit nil and the absence of a
parameter. They shouldn't, and it would be easier to call them if they
didn't.

In summary, I suggest that the "problem" you present is not that there is
only
one false value in the system; rather it is that you cannot store such a
value
in a vanilla table. The solution to that problem is to come up with a table
which accepts nil as a value, and I'm quite happy to have done so.

> If there wasn't the need to keep compatibility with existing code, I
> would argue that nil should not behave as "false" in expressions.  It
> expresses an entirely different concept.  I find "value == nil"
everywhere
> I need to test for existence much less confusing than any of the other
> options.  But I'm not a C programmer.  NULL == 0 == false only makes
> sense if you have a C background.

A low blow. I do program in C, but I don't have a "C background". I have a
Lisp background. But there are lots of languages other than Lua in which
the
absence of a value is indistinguishable from a boolean "false". And there
are
always some people who complain about that and some who will defend it to
the
death. So there is probably no resolution to the question.

Perl's flexibility about what is "false" has burned me a lot of times,
though,
and is on the list of why I will probably not use Perl anymore.