SRFI-1/SRFI-13 inconsistency in tabulate procedure
Olin Shivers
(20 Mar 2001 23:10 UTC)
|
Re: SRFI-1/SRFI-13 inconsistency in tabulate procedure
sperber@xxxxxx
(21 Mar 2001 07:58 UTC)
|
Re: SRFI-1/SRFI-13 inconsistency in tabulate procedure
shivers@xxxxxx
(21 Mar 2001 15:36 UTC)
|
Re: SRFI-1/SRFI-13 inconsistency in tabulate procedure
Shriram Krishnamurthi
(21 Mar 2001 16:48 UTC)
|
More on SRFI-1/SRFI-13 inconsistency in tabulate procedure Olin Shivers (21 Mar 2001 21:01 UTC)
|
More on SRFI-1/SRFI-13 inconsistency in tabulate procedure Olin Shivers 21 Mar 2001 21:01 UTC
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@srfi.schemers.org (i.e., not to comp.lang.scheme). -Olin