[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On optional arguments



I agree that this SRFIs current optional arguments specification is cognitively cumbersome. Beyond the cognitive burden, it also makes static analysis of code very difficult.

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 )
procedure:  ((<? [ compare ])  x y )
procedure:  ((>? [ compare ])  x y )
procedure:  ((<=? [ compare ])  x y )
procedure:  ((>=? [ compare ])  x y )
procedure:  ((not=? [ compare ]) x y )

A few examples for illustration
  ((>?) "laugh" "LOUD") ===> #t
  ((<? string-compare-ci) "laugh" "LOUD") ===> #t
  (define char<=? (<=? char-compare))
  (sort-by-less '(1 a "b") (<?)) ===> '("b" a 1)
  (sort-by-less '(1 a "b") (>?)) ===> '(1 a "b")


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.
(=)       ;; returns a procedure of arity 2 with SRFI-67 comparison semantics.
(= c)     ;; returns a procedure of arity 2 with SRFI-67 comparison semantics.


David