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