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.
The discussion on optional arguments at the beginning stopped before a consensus was reached. Since the last letter in the thread was posted a while ago, I have made an attempt to recap the discussion.The discussion started in <http://srfi.schemers.org/srfi-67/mail-archive/msg00036.html>
in which Mike Sperber writes: 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 on the total number of arguments, which I find confusing. In <http://srfi.schemers.org/srfi-67/mail-archive/msg00039.html> Sebastian Egner writes: 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: (if<? (compare 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 argument. In <http://srfi.schemers.org/srfi-67/mail-archive/msg00046.html> Mike writes - 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. and elsewhere suggests Solution #1: Ditch the curry overload; make the comparison an optional last argument. Solution #2: Make the comparison a mandatory first argument. I'll for a moment assume that we ditch the curry overload and let the compare argument be the first of any optional arguments. Do we then get consistency? Well, almost, but there is still an (unrepairable) conflict with these functions (chain=? compare x1 ...) (chain<? compare x1 ...) (chain>? compare x1 ...) (chain<=? compare x1 ...) (chain>=? compare x1 ...) (pairwise-not=? compare x1 ...) (min-compare compare x1 x2 ...) (max-compare compare x1 x2 ...) (kth-largest compare k x0 x1 ...). [the conflict being (=? x y compare) versus (chain=? compare x y) ]. [Note: The if-family of macros also take compare as first parameter]The main objection against solution #1 is thus that it will become harder to remember where the compare functions are to be placed.
But why did Mike objecti to putting the optional argument in front? On the technical side in <http://srfi.schemers.org/srfi-67/mail-archive/msg00045.html> he writes: 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. I am not sure I understand what he is getting at. If an unknown function is passed, then you obviously don't know how to call it correctly - and if you do know it, then you are aware of the functions calling conventions. On the cognitive front in <http://srfi.schemers.org/srfi-67/mail-archive/msg00049.html> he argues (prompted by the curry overloading I think) that having different names for different operations is preferrable (I tend to agree with that). Also on the cognitive front it should be mentioned that the traditional way of passing optional arguments is to use the variable number of arguments-mechanism. One might even say that our problem is that Scheme doesn't have a way to specify optional arguments. If it were possible to specify optional arguments with keywords this whole thread wouldn't exists. I.e. both (<? :compare default x y) and (<? x y :compare default) would work. The argument for the compare argument in front is also cognitive. The most important one is consistency as mentioned previously. Another parameter to consider is code readability. In some situations it is important to have read a certain argument before reading the others. Erm - more concretely consider (<? compare x y). Here <? signals we need to compare something. compare describes how the things are compared, and x and y is what to compare. In (<? <large-expression1> <large-expression2> compare) one reads what is to be compared before one finds out how they are to be compared. In that situation I prefer (<? compare <large-expression1> <large-expression2>)Botner has a similar point in <http://srfi.schemers.org/srfi-67/mail-archive/msg00050.html>
SRFI 64 also has non-final optional arguments. E,g.: (test-eqv [test-name] expected test-expr) I think this is preferable to having two functions, and in this case having the test-name first is desirable for documentation reasons: (test-eqv "test-string-apppend-1" (....) (....)) To sum up - I think the choice is between tradition and consistency. In the end it is a matter of taste, which is why it is hard to choose. My personal preference is to keep the optional compare argument in front. Having it appear first in some functions (chain=?, ...) and last in others will confuse me. -- Jens Axel Søgaard