This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.
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 work now.] 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 convention. 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). -Olin