David Van Horn wrote:
> I agree that this SRFIs current optional arguments specification is
> cognitively cumbersome.

Because of the (=? cmp)-short cut?

> Beyond the cognitive burden, it also makes  static analysis of code
 > very difficult.

Why is that?

> I also agree comparisons should be the first argument (if used), and I'm
> not averse to requiring the compare procedure, but I realize it's verbose.
>
> Would the following work as a reasonable compromise?

> procedure:  ((=? [ compare ])  x y )
...
> This has the added benefit(?) that you can now drop `?' since =, <, >,
> <=, >= are not defined on 0 or 1 arguments, thus:
>
> (= 1 2)   ;; performs a test with R5RS semantics.
> ((=) 1 2) ;; performs a test with SRFI-67 semantics.

This costs an extra function application per comparision. Personally,
I'd rather remove the (=? cmp) short cut than pay an extra cost per
comparison.

The only situation in which I would specialize =? with respect to
a fixed comparion function, is when the specialized comparison
is used twice or more. In that situation a LET is needed, so
whether I have to write

   (let ([my=? (=? my-cmp)])
     ... (my=? a b) ...
     ... (my=? c d) ...)

or

   (let ([my=? (cut =? my-cmp <> <>)])
     ... (my=? a b) ...
     ... (my=? c d) ...)

isn't terribly important to me.

--
Jens Axel Søgaard