Dave Cridland writes:
I'm really not so sure. On the face of it, it sounds like bad design,
but I think there's at least two cases here - an attempt to compare
"fish" and "bicycle", and an attempt to compare "fish" and "2". I
have a feeling this is an important distinction.
It is precisely the distinction between "neither input is valid" and
"one input is valid, the other not".
Arguably, "fish" is equal in numeric value to "bicycle" - they both
have no numeric value, so it's the same as comparing NIL and NIL with
"i;octet".
Or as comparing null with null in SQL.
Equally, "2" has a numeric value of 2, whereas "fish" does not, so
they are unequal - like comparing NIL and an existing string with
"i;octet".
Or as comparing 2 with null in SQL. And wouldn't you know, SQL is
different from ACAP in this respect.
x=> select 42 as answer where 2=2;
answer
--------
42
(1 row)
x=> select 42 as answer where 2!=0;
answer
--------
42
(1 row)
Makes sense so far? Let's compare things with null a little:
x=> select 42 as answer where 2=null;
answer
--------
(0 rows)
x=> select 42 as answer where 2!=null;
answer
--------
(0 rows)
x=> select 42 as answer where not(2=null);
answer
--------
(0 rows)
x=> select 42 as answer where null=null;
answer
--------
(0 rows)
I'd rather not venture into this dark and confusing maze of null/nil
semantics. These are choices for the protocol to make, say I.
Instead, I think I'll add a fourth operator, valid, which indicates
whether a given string is valid input for the collation. It's not
really necessary. indomain(a) is true if and only if a=a. But it sounds
sensible. Permits protocols to differentiate between one and two
invalid inputs if they want to, without resorting to hacks like a=a.
Arnt