This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 are here. Eventually, the entire history will be moved there, including any new messages.
Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes: > Yes, there is little precedent---probably due to the late > introduction of SRFI-16 (case-lambda). No, I don't believe that's the case. CASE-LAMBDA is nice, but that doesn't mean it has to be used everywhere and in any manner applicable. > 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). 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. >> Is there a rationale [...] > Actually, there is a rationale for this. I'm sorry, I should have referred to the rationale. You argue that the specific overloading you chose favors the optional argument at the beginning: - 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. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla