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.
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@xxxxxxxxxxxxxxxxx (i.e., not to comp.lang.scheme).
-Olin