Wording of the rationale

[Jens Axel Søgaard <jensaxel@soegaard.net>]

I am little unhappy about the wording of the rationale:

    RATIONALE

    When SRFI 32 Sort Libraries was withdrawn, it had 28 procedures for
    what should have been a clean, simple interface.

In my view SRFI-32 *is* clean and simple. Comparing the number 28
to the number of procedures defined in SRFI-95 is unfair, since
SRFI-95 covers the "What"-part but not the "How to"-part of
SRFI-32.

    These 28 arose for several reasons:

       * List and Vector versions were separated, even though Scheme has
         manifest types which eliminate ambiguity as to the caller's
         intentions.

Separating list and vector functions are tradition. In R5RS we have,
for example list-ref, vector-ref and string-ref instead of general ref.
One benefit of this choice is that compilers get a fair chance to 
generate efficient code.

       * Four varieties of algorithms were provided (quick, heap,
         insert, merge) even though quick, heap, and insert sorts have
         no significant advantage over merge-sort.

First: The choice between these algorithms were in the "How to"-part
of SRFI-32. If a user doesn't care, which algorithm is used, he can
use list-sort!, vector-sort!.

Second: What does "no significant advantage" mean? I were of the
impression, that the "hidden constants" of O(n log (n)) of
vector-quick-sort were smaller than that of vector-merge-sort.

Third: The different algorithms have different memory requirements.
If very large vectors are sorted, it makes sense to choose a slower
algorithm that allocates very little extra memory. Some versions
of vector-merge-sort! allocate a helper array the size of the original.

Also: Is merge-sort the fastest algorithm, if the elements are "almost
sorted"?

      * Sort and stable-sort varieties were included, even though an
        unstable sort has no performance advantage.

As I see it, the reason they are in SRFI-32 is not efficiency but
completeness. Nevertheless, if vector-quick-sort! (which is unstable)
is faster than vector-merge-sort! (which is stable) then it makes
sense to let vector-sort! default to vector-quick-sort! and
let vector-stable-sort! default to vector-merge-sort! in the
name of efficiency.

--
Jens Axel Søgaard