[E-Lang] Operators #2: Comparison

[Ralph Hartley]

Mark S. Miller wrote:

> In E currently:

>    x < y             x compareTo(y) belowZero()
>    x <= y            x compareTo(y) atMostZero()
>    x <=> y           x compareTo(y) isZero()
>    x >= y            x compareTo(y) atLeastZero()
>    x > y             x compareTo(y) aboveZero() 

Don't you need something like <>          (x compareTo(y) belowZero()) || x compareTo(y) aboveZero())

I assume != is the negation of == so just as we need a separate <=>, we need (though, I conceed, not desperately) a "not equivalent" operator.

> * On Java classes (and by extension perhaps, on declared E types, should we 
> ever declare such things, as we probably will): x <= y means that x is a 
> declared subtype of y.  If y is a class, then x is y or a class that extends 
> a class that's <= y.  If y is an interface, then x is y or x is a class or 
> interface that extends or implements a class that's <= y.

You mean:

If y is an interface, then x is y or x is a class or 
interface that extends or implements a class OR INTERFACE that's <= y.

>   x < y means that 
> x is a declared strict subtype of y, that x < y && !(x <=> y).
> 
> * On regions: x <= y means that the set of members of region x is a subset 
> of the set of members of region y.
> 
> * On sets: x <= y means x is a subset of y.
> 
> 
> Lists
> 
> 
> I think this issue breaks my attempt to unify lists and multisets.

Perhaps a better unification is between lists and maps with integer keys 
(see below).

> So, on lists: x op__cmp(y) compares them lexicographically -- compares 
> their elements pairwise left to right until it encounters the first pair 
> that aren't equivalent.  The answer to the overall compareTo is negative, 
> positive of NaN, exactly as the first non-equivalence is one of these.  If 
> the two lists are of equal length and everywhere pairwise equivalent, then 
> the two lists are equivalent.  (When the only disagreement is length, we 
> generalize the answer from String.  What is it?)

The shorter string is < the longer.

> Maps
> 
> It is plausible either to not define op__cmp on Maps, or to define it 
> according to the keys of the Map considered as a set.  After some voice 
> conversations with Dean, I'm inclined toward the first answer: not to define 
> it on Maps.  If you want to operate on the keys of the maps as sets, ask the 
> maps for their keys.

Not defining it at all has its merits, but comparing the sets of keys 
isn't right anyway. The comparison of two maps should depend on the 
values, not just the keys. Here is a try at a definition:

x < y if x is empty but not y.  x > y if y is empty but not x.  x<=> y 
if both are empty.
If x or y don't both have a first key (a key < all other keys) , then x 
op_cmp(y) is NaN.
Otherwise, if the first keys of x and y are not the same (<=>, I'm 
pretty sure == is to strong) it's also NaN.
Otherwize, if a op_cmp(b) is not 0 (where a and b are the values 
associated with the first keys of x and y respectively) it's a op_cmp(b).
Otherwize it's (x tail()) op_cmp(y tail()) (where x tail() is x with the 
first (according to < on the keys) key value pair deleted).

Or for those who don't care to parse my recursive definition, compare 
the value sets lexographically, where the position of a value in the 
"string" is determined by its key. The comparison between two maps is 
determined by comparing the values associated with the least keys such 
that the comparison is not 0. By this definition two maps that happen to 
be functions with the same domain will be <=> if they map the same keys 
to the same values, which is the normal definition of equality for 
functions.

This corresponds exactly to lexicographic order for lists if a list is a 
map who's keys are a range of integers, starting with 0. So (A,B,C) is 
actually the same as {0->A, 1->B, 2->C}. With that definition of a List, 
there is also no question of needing a way to find an element by it's 
place in the list, x[3] is, um ... let's see now ... , it's x[3].

Multimaps:

I have no idea whatsoever of what the comparison of multimaps would 
mean, so there is no danger of surprising anyone. If you did define it, 
I would have to look it up each time I used it (very rarely). Don't bother.

Ralph Hartley