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