This page is part of the web mail archives of SRFI 32 from before July 7th, 2015. The new archives for SRFI 32 contain all messages, not just those from before July 7th, 2015.
shivers@xxxxxxxxxxxxx writes: > I have changed the SRFI accordingly. The new draft is at > http://www.cc.gatech.edu/~shivers/srfi/srfi-32.txt > and will propagate out to the standard url > http://srfi.schemers.org/srfi-32/srfi-32.html done. > [On the subject of parameter order between the < arg & the data arg:] > Do you provide functions with the same _names_ as existing > implementations, or just the same interfaces? > > Hmm, there is a small amount of clash, but less than I would have supposed. > Check the other-implementations summary. But even if the *names* don't clash, > the *convention* is completely inverted from current practice, which is asking > for confusion. > > Let's hear from some other voices. "Ben Goetter (in the field)" <goetter@xxxxxxxxxx> writes: > "Operation currying" is a nice turn of phrase. Chez gets the parameter > order right by taking the opportunity to make its SORT parameter order > agree with Scheme's MAP, FOR-EACH, and APPLY. Yes, this is incompatible > with Common Lisp, but it means that I-- I mean, a Scheme programmer-- > will guess the parameter sequence correctly. I also believe that Chez is doing the Right Thing by changing the order of the parameters in the sort procedure, and friends. This order agrees not only with Scheme's MAP, FOR-EACH, etc. but also with several other procedures: FILTER, FILTER-IF, SOME, EVERY, and in general, with all procedures that apply a procedure to a given set of data-structures. A lot of useful code out there will break with such a change, no questions there. Nevertheless, it is maybe for the best, and a well written library, as I'm sure Olin's is, will ease the transition. I can live with the Common Lisp convention, not very happy, though. --Francisco