[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.

Mike Sperber wrote:
> Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes:
> > This is in contrast to the point of view we have taken for this SRFI:
> > There are two abstract data types called VECTOR and LIST, where
> > VECTOR is specified by a SIZE procedure and a REF procedure
> > (e.g. constant-time random access finite-length sequences) and
> > LIST is specified by procedures EMPTY?, HEAD and TAIL (e.g.
> > unbounded finite stacks).
> But you're omitting a detail here, which is that REF is specified in
> terms of natural numbers, which have inductive structure, which could
> be used to justify choosing the list order.  Of course, this is
> far-fetched, but that, to my mind, also holds for vector comparison
> you picked.

I think we have just beaten this justification horse to death.

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:


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').

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.