On Tue, Jun 5, 2018 at 3:24 AM, Dirk Laurie
<dirk.laurie@gmail.com> wrote:
2018年06月05日 10:03 GMT+02:00 Viacheslav Usov <via.usov@gmail.com>:
> On Tue, Jun 5, 2018 at 3:35 AM, dyngeccetor8 <dyngeccetor8@disroot.org>
> wrote:
>
>> Current behavior of "and" and "or" operators is equivalent to following
>> Lua-like functions.
>
> The behaviour is documented in section 3.4.5, and the essential part of it
> is the "short-circuit evaluation; that is, the second operand is evaluated
> only if necessary". Your explanation is far more complicated than that and
> is technically incomplete and/or inconsistent anyway.
The OP was playing an intellectual game (as is clear from his remark
"I should add that I do understand what's happening here.") The rest
of us don't want to play along, and would rather discuss the
curiosities of 'and' and 'or'. So (sorry, Sam) do I.
That's not entirely fair. I was neck deep in SQL, and wanted to see if evaluation
could be adjusted to match the three-valued logic.
The advantages are considerable!
So with the thread well and truly hijacked, here is my 2¢'s worth.
It isn't a hijack imho. The short-circuit behavior is desirable, in a way that trumps
the utility of a nil == null semantics.
I didn't know the first thing about how we got here, thanks for that!
One could imagine a language where, say, the ternary operator, as well as "&", "|", "!",
follow a lazy evaluative logic, while "and", "or", and "not" follow a three-valued Boolean
logic, and were thus required to evaluate eagerly.
Wouldn't be Lua, though.