Re: comparators and "error"

[Arnt Gulbrandsen <[e-mail]>]

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