[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More on SRFI-1/SRFI-13 inconsistency in tabulate procedure
The following message is a courtesy copy of an article
that has been posted to comp.lang.scheme as well.
We can't change SRFI's 1 or 13 in the fashion I proposed in the last msg,
as they are both final. So let me restate the problem.
[By the way, if you sent mail to either srfi mailing list, it was lost.
Those mailing lists have just now been re-activated; mail to them will
A reviewer has spotted a consistency problem between SRFI-13 & SRFI-1
that needs to be fixed. SRFI-13's procedure
(STRING-TABULATE proc len) -> string
takes it arguments backwards from SRFI-1's
(LIST-TABULATE len proc) -> list
As future SRFIs may also introduce by-index TABULATE constructors for other
aggregate data structures (e.g., vectors), it's important to be consistent.
There are basically two possibilities:
A. Do nothing. Live with the inconsistency for now.
B. Change LIST-TABULATE to be
(LIST-TABULATE proc len) -> list
This would be consistent with all the other higher-order iterators
such as MAP, FOR-EACH, ANY, EVERY, etc. This is a *very* widely-maintained
This would require issuing a *new SRFI*, e.g. SRFI-24, which would be identical to
SRFI-1 except for the parameter order in LIST-TABULATE.
What do people think?
Argument for choice A (doing nothing):
General tiredness, unwillingness to move to a new SRFI for such a small
change. Might be better to wait a year and see if anything other problems
emerge, then all can be fixed in one lump.
Argument for choice B (issuing a new SRFI):
The earlier you establish a convention, the more it pays off.
Less code is written that will break. More cross-module consistency
is established. The "cost" of switching to a new SRFI is pretty
trivial. Waiting for a year makes the cost of switching more painful
to the community, as more code will be written with the older API.
I am pretty evenly split about this, though on reading the two arguments,
B seems like the "right thing."
We could make the wait-a-year approach more palatable by unofficially
announcing that SRFI-1 clients should avoid LIST-TABULATE.
Comments? Send them to srfi-1@xxxxxxxxxxxxxxxxx (i.e., not to comp.lang.scheme).