Sebastian Egner <xxxxxx@philips.com> writes:

> Yes, there is little precedent---probably due to the late
> introduction of SRFI-16 (case-lambda).

No, I don't believe that's the case. CASE-LAMBDA is nice, but that
doesn't mean it has to be used everywhere and in any manner
applicable.

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

The problems come later, when you pass these things around as
higher-order procedures, and it's not immediately apparent that the
procedure you've been passed uses an unorthodox argument processing
convention.  (This is generally a case against overloading in
higher-order languages, I think---it doesn't scale well.)  This is why
you haven't encountered the problem yet, but may in the future.

>> Is there a rationale [...]
> Actually, there is a rationale for this.

I'm sorry, I should have referred to the rationale.  You argue that
the specific overloading you chose favors the optional argument at the
beginning:

- You use overloading to implement the curried version.

  I think that's a bad idea, partly for the reason described above,
  and partly for the existence of SRFI 26, which makes it clear that
  there's currying going on with little notational overhead.  (But who
  am I talking to? :-) )

- You ditch the overloading, your rationale goes out the door.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla