[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SRFI-1/SRFI-13 inconsistency in tabulate procedure
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
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
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).