This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 contain all messages, not just those from before July 7th, 2015.
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 ab) -> #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 definedas 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