Re: Another nil/false proposal (long)

[Edgar Toernig <froese@...>]

RLake@oxfam.org.uk wrote:
> 
> Now let's define two "almost identity" operators:
>      !a   is a unless a is nil, in which case it's "nil-but-true"
>      ?a  is a unless a is "nil-but-true" in which case it's nil
>[...]

Don't you think it gets much too complicated?  What you get is a new
special value and two operators the convert nil to special and vice
versa.  You trade one special value with your special value and gain
nothing (except confusion *g*).

IMHO, the false in Lua-4.1 works perfectly.  There's only thing that
is inconvenient: the new behaviour of the "or" and "and" operators.
Especially "or" was used to replace missing (nil) values and this no
longer works under all circumstances.

So better introduce a special operator ("alternate", "default", "||", "?")
that does this and be finished.  I think, with such an operator available,
I wouldn't even care when "and" and "or" would always give boolean
results then.  This would inhibit the previous "misuse" of them ;-)


> It also solves that irritating problem with dostring where you want to be
> able to test for success, but you also want to allow the string to return
> nil. Returning !nil is exactly what is called for, and makes it easy to
> test for later.

It wouldn't!  The string may want to return !nil.  The problem remains.
You can solve it by _always_ returning a status value as the first result.
(Btw, the same for dofile, loadstring, loadfile, and call.)

> Now, let's take this idea one step further. With the above simple concept,
> we can provide the consumer of a functional interface a way of specifying
> "really nil, not the default value":
>         foo(42, !nil)

... and foo has to be prepared to convert !nil to nil.  And if I want to
pass !nil?  IMHO, you just move the problem around ;-)  Up to now, nil
was special - you make "nil-but-true" special (why don't you call it
"true"? *g*).

Ciao, ET.