"Lex Spoon" <lex at cc.gatech.edu> wrote:
	> (There are other orders which are also compatible with =, such as
	>  - first compare the lengths,
	>  - then compare the elements ONLY if the lengths are the same.
	>  This is almost always faster, and has some nice properties.
	
	Gee, yet another way to compare collections.  Note, though, that this is
	not a total ordering, either -- arrays of different lengths will be ~=
	but they will be neither #< nor #> .
	
No, it's a total order.
	#(4) < #(1 2)		(length is less)
	#(1 2) < #(4 2)		(length =, first element <)
	#(1 2) < #(1 4)		(length =, last element <)

If two arrays have different lengths, then one of them is shorter,
and that one is less.  If they have the same length, then either
all elements are equal, so the arrays count as equal,
or one position has unequal elements, and the first such position
determines the order.  (Of course, taking the last position would
also work.)

This order was used on strings in PL/CV,
and it's _almost_ the order Prolog uses.
(Prolog actually compares function symbols first, then arity,
 and then elements.  So if you use f, f(X1), f(X1,X2), .. and so
 on for sequences, you get this order.)

I'm not advocating that ordering; lexicographic has always suited me.
I brought it up because that's the reason why I didn't just post an
[ENH].