[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vector compare

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.



Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes:

> There are two really fundamental ways of lifting a total
> order to finite length sequences: lex and length>lex (aka tdeg).
> These are provided through making them the default for lists
> and vectors, which also provide abstract names for the orderings.
>
> The SRFI gives full choice with convenient notation:
>
> http://srfi.schemers.org/srfi-67/srfi-67.html#node_sec_4.2
>
> The only issue in the discussion is the definition of
> DEFAULT-COMPARE, and the more philosophical aspect how
> to interpret lists and vectors ('two subtypes of sequence'
> vs. 'two independent data types').

It's also about the meaning of VECTOR-COMPARE.

> Scheme (R5RS) doesn't unify lists and vectors at all:
> The operations are named entirely different, the set of
> available operations is totally different (and incomplete),
> and operations that could dispatch on representation
> (e.g. APPLY) all expect lists as arguments.

Sure.  But just because the representation is different doesn't mean
that the comparison should also be different, no matter the price.
After all, you chose "standard" lexicographical ordering for strings,
too, which are conceptually vectors of characters.  By Jens's
"fundamentalist" argument (strings are specified in terms of LENGTH
and REF), strings should be compared the same as vectors.  But they
shouldn't, because we'd all have this funny gut feeling, and it
would be significantly useful than the definition you chose.  The same
holds true for VECTOR-COMPARE.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla