Email list hosting service & mailing list manager

Order of arguments in set-map, set-unfold, ... Marc Nieper-Wißkirchen (03 Jan 2017 10:30 UTC)
Re: Order of arguments in set-map, set-unfold, ... Arthur A. Gleckler (29 Jan 2017 18:31 UTC)

Order of arguments in set-map, set-unfold, ... Marc Nieper-Wißkirchen 03 Jan 2017 10:30 UTC

In the specification of SRFI 113 the procedures set-map and set-unfold
are defined as follows:

(set-map <comparator> <proc> <set>)

and

(set-unfold <comparator> <stop?> <mapper> <successor> <seed>)

Until a recent change of the sample implementation, the sample
implementation (and its tests), however, implemented:

(set-map <proc> <comparator> <set>)

and

(set-unfold <stop?> <mapper> <successor> <seed> <comparator>)

While it is usually the right thing to modify the sample implementation
to fit the specification, this time, in my opinion, it was the wrong
thing, because it was actually the sample implementation which got the
order right:

The reason is that with the order of arguments as currently specified,
it is inconsistent with the order of arguments of hash-table-map and
hash-table-unfold of SRFI 125. As both SRFI 113 and SRFI 125 are going
to be part of R7RS-large I strongly urge to revert back the sample
implementation to what it was when SRFI 113 was voted for inclusion in
R7RS-large and to fix the spec so that it is consistent with the order
of arguments of SRFI 125. Otherwise, we will have a poor inconsistency
in R7RS-large (which would particularly be sad because otherwise it was
tried hard to avoid such inconsistencies; see, for example, the
rationale to SRFI 133).

N.B.: SRFI 146 currently uses the argument ordering of SRFI 125. Should
no change be made to SRFI 113, I will change the order of arguments of
SRFI 146 to match those of current SRFI 113 (but the inconsistency with
SRFI 125 would remain).

--

Marc

P.S.: The same holds for the analogous bag-procedures.