What should (not $nil) be

[hanche]

The code not $nil currently results in $true.

I think it probably should result in $nil instead.

Rationale: Way back when, $nil was introduced as an elvish analogue of SQL's NULL. The intent, as in SQL, is to indicate a lack of a definite value, whether currently unknown, not yet assigned, or irrelevant. In SQL, NULLs are contagious, in that almost every operation involving a NULL returns NULL. Arguably, elvish's $nil should behave the same way.

Making not $nil produce $nil is a backward incompatible change, but I think it is unlikely that any code relies on it being $true.

However, once we do this, the question arises what to do about $nil in the other logical functions, and and or?

• It could be argued that and $nil $true should return $nil, while and $nil $false should return $false, since the “true value” of the former is unknown, while the latter is false no matter what.
• Similarly, or $nil $false should perhaps return $nil, but or $nil $true is tricky, since it normally returns either the first or second argument depending on the truth value of the first argument.

The latter two points are perhaps more likely to get current code into trouble. It might force the use of (coalesce $x $false) in situations where one really wants $nil to behave as a definitely false value.

Also, some might object that an if–else statement becomes ambiguous if the condition evaluates to $nil, at least if we take consistency very literally. But I think that is taking consistency one step too far. In SQL (at least sqlite and postgresql), select case when null then 1 else 2 end returns 2, as seems reasonable and proper, even though a stickler for consistency might insists that NULL is the right answer.

[xiaq]

Hmm, I didn't intend $nil to model SQL's NULL - the name coalesce is indeed borrowed from SQL, but that's the full extent. It has the more traditional (and sensible) meaning of absence of value rather than SQL's meaning of uncertainty of value.

Elvish doesn't do three-valued logic anywhere, so I'm not intending to let the genie out. An interesting proposal, but no thanks :)

[hanche]

That's all right. I just wanted to be sure the present behaviour is as intended. At the time, I was the one most inclined to think it should be like SQL's NULL, but I'm okay with the present semantics. I'll just have to program around it if I ever encounter the issue (which may never happen).