> General Issues:
> It is my personal opinion that this module should be helpful to anyone
> involved in either total orders or partial orders, such as floating-point
> numbers (which form a total order if you ignore NaNs and -0.0). One way of
> doing this would be to use an exception/condition to express a lack of
> total order, another would be to return something other than -1, 0, 1 from
> the compare procedure (perhaps return +nan.0), which would violate the
> conditions for a compare procedure according to this module as specified so
> far. I'm not sure what the best way to do this is, except to provide
> additional procedures for floating-point numbers, and not handle partial
> orders in a general way. My intuition tells me that a general approach
> would be more valuable in the long term, than to special case floats.
> Treating any and all partial orders that come along as special cases, just
> seems wrong to me.

SRFI 114 does provide a special case for floats. What would be other
use cases for partial orders in general?

Subtyping relations are a partial ordering.

Consider:

Numbers >= Complex >= Reals >= Rationals >= Integers >= Naturals

However, consider also:

Numbers >= Complex >= Imaginaries

The Imaginaries type is "incomparable" to the Reals, Rationals, Integers, or Naturals type, because it follows a different branch of subtyping. This forms a partial ordering.

It would be nice to be able to "compare" two type objects and learn if one is a sub-type of the other, is the same type, or are incomparable.

Sets may also be compared (basically, if you consider that subtype == subset, so that "the set of Numbers is a superset of Reals"), and the result may also be "incomparable", i.e. one is not a strict subset of or equal to the other.

For floats, perhaps NaN should return "incomparable" if one side is a NaN and the other is not, or "equal" if both are NaN (this would simplify some uses of hash tables). As for -0.0, perhaps we can consider it as actually being -(epsilon/2), so that it is less than 0.0 but greater than -epsilon, where epsilon is the tiniest representable non-zero float.

Personally, I'd like the "incomparable" case to return "a unique, non-numeric object of unspecified type, which may be compared by eq? to the exported binding INCOMPARABLE, e.g. (eq? (compare a b) INCOMPARABLE)." but that's just me.