The following message is a courtesy copy of an article
that has been posted to comp.lang.scheme as well.

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 three possibilities:

1. Change SRFI-1 to
    (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.

2. Change SRFI-13 to
    (STRING-TABULATE len proc) -> string
   This is probably a bad idea; would break consistency with lots of other
   routines. It does have the charm that the numeric argument is usually
   shorter than the PROC argument, and when you have a huge lambda
   expression for the PROC parameter it's easier to read when it's
   ordered this way. Nonetheless, I feel the consistency cost outweighs
   this benefit.

3. Do nothing.

My preference is option 1. It does mean changing a standard that's been set
for about a year and a half. Nonetheless, I suspect that it will probably go
through w/o too much pain, and we thereby gain a consistent framework as we
move forward to other libraries.

Comments? Send them to srfi-1@srfi.schemers.org (i.e., not to comp.lang.scheme).
    -Olin