[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optional arguments at the beginning
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.
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
> 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
> end? Alternatively, one could always require it to be present,
> I personally would prefer.
Actually, there is a rationale for this.
To begin with, please refer to
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
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:
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
c) Why are the arguments x and y also
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
xs (<? my-compare))
> (Great SRFI in most other respects, BTW!)