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

Re: On optional arguments

This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 contain all messages, not just those from before July 7th, 2015.

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