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

Re: cell recycling; reference implementation; param ordering; fresh lists



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