More on SRFI-1/SRFI-13 inconsistency in tabulate procedure

[Olin Shivers <shivers@xxxxxxxxxxxxx>]

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