Mike Sperber wrote:
> The spec has:
>
> procedure:  (=? [ compare ] [ x y ])
> procedure:  (<? [ compare ] [ x y ])
> procedure:  (>? [ compare ] [ x y ])
> procedure:  (<=? [ compare ] [ x y ])
> procedure:  (>=? [ compare ] [ x y ])
> procedure:  (not=? [ compare ] [ x y ])
>
> I dislike having the compare optional argument at the beginning: There
> seems to be almost no precedent for it in Scheme libraries, and it
> means that the parameter positions change their meaning depending on
> the total number of arguments, which I find confusing.

Yes, there is little precedent---probably due to the late introduction of SRFI-16 (case-lambda).
And, yes, we are aware that these procedures are overloaded to the limit.

But no, in the brief time this SRFI is around I did not encounter any problems with the
convention of having the compare procedure in the beginning. In fact, I do experience
it as quite natural in all circumstances I came across until now (more about it below).
 
> Is there a rationale for having it at the beginning rather than at the
> end?  Alternatively, one could always require it to be present, which
> I personally would prefer.

Actually, there is a rationale for this. To begin with, please refer to

  http://srfi.schemers.org/srfi-67/srfi-67.html#node_toc_node_sec_Temp_32

a) Why is the compare proc. optional?

With the mechanism presented in this SRFI, the built-in fixed-type comparisons
= < char<? etc. could be made obsolete. We do not expect this to happen any
time soon but this SRFI (or rather a simplified version of it) is nevertheless
designed to qualify as a replacement.

For this it is critical that the most frequent comparisons (i.e. for numbers, chars,
strings, and symbols) are as convenient as possible. This is the purpose of
having an optional (default) compare procedure.

In effect, (<? x y) is as convenient as (< x y), and for real numbers it even
means the same ;-)

b) If there is an optional compare proc. why is it in front?

So that (foo compare x y) is always understood as (foo (compare x y)).
This is consistent throughout the SRFI with all operations accepting a
compare procedure as parameter---no matter the arity.

Personally, I would find it confusing if the compare procedure argument
is in front for some operations and at the tail for others. Consider:

        (if<? (compare x y) A B)
        (if (<? compare x y) A B)
        (if ((<? compare) x y) A B)

The confusion of compare changing places might be more than the
confusion of having an optional leading argument.

c) Why are the arguments x and y also optional?

In order to support the higher-order function style of programming.

In particular, (<? compare) constructs a comparison predicate from
a comparision, so that you can say

   (my-sort-by-less-than xs (<? my-compare))

> (Great SRFI in most other respects, BTW!)

(Thanks!)

Sebastian.