This page is part of the web mail archives of SRFI 32 from before July 7th, 2015. The new archives for SRFI 32 contain all messages, not just those from before July 7th, 2015.
I think the ordering op should go first. Also, <= seems much more
intuitive than <.
I note that the non-mutating vector sorts are guaranteed to copy the
vector. It would seem potentially very useful to give some indication of
whether the new vector is in fact different from the old vector, to allow
programmers to optimize for generational collectors.
It would seem potentially slightly useful to have "fully copying" sorts,
that are guaranteed not to mutate the original list and not to share any
list structure with it, but I don't know if this would be sufficiently
useful to include.
" make only a single, iterative, linear-time pass over their argument
lists, constructing their results by side-effecting these lists.
The intent of this algorithmic commitment is to allow the programmer
to be
sure that if, for example, LIST-MERGE! is asked to merge two
ten-million-element lists, the operation will complete without
performing
some extremely (possibly twenty-million) deep recursion. That is,
LIST-MERGE! is implemented as an iterative algorithm. "
So does this mean that LIST-MERGE! is guaranteed to return an object
containing no new cons cells? The spec is not so clear here.
--
Night. An owl flies.
David