bear wrote:

> Just a quick word, but I've found it useful in several applications to
> have a comparison procedure that imposes a total ordering on data of
> many differnt types.  This is useful mainly for making 'ordered
> collections' such as trees and ordered arrays that can use any atom as
> a key.  I call it "gcmp", but there's probably a better name.

The compare procedure default-compare which uses the ordering

null < pair < boolean < char < string < symbol < number < vector < other

was meant to be used for this purpose. Since this ordering can't
accomodate all needs, we have provided refine-compare, select-compare
and cond-compare which is used to construct new compare procedures.

   <http://srfi.schemers.org/srfi-67/srfi-67.html#node_idx_40>
   <http://srfi.schemers.org/srfi-67/srfi-67.html#node_sec_4.5>

> The important thing is that the comparison is transitive: If (gcmp a
> b) -> #t and (gcmp b c) -> #t, then (gcmp a c) -> #t.

An order relation induced by a compare procedure is transitive.

     <http://srfi.schemers.org/srfi-67/srfi-67.html#node_sec_5>

> The particular order defined isn't terribly important.

The rationale behind the current choice of ordering is founc here:

<http://srfi.schemers.org/srfi-67/srfi-67.html#node_toc_node_sec_Temp_18>

> If adopted, I think it ought
> to be okay for gcmp to have implementation-defined intertype ordering
> and complex-numeric ordering, but intratype ordering should be defined
> as for the ordering predicates within each type;

In order to allow implementations to use a straight forward
integer comparision of the tags of two values?

> the uses to which
> gcmp can be put are more related to computational requirements to
> compare and order objects for purposes of key comparison than they are
> to any inherent "real" or "mathematical" order for anything.

Agreed.

--
Jens Axel Søgaard