SRFI-1/SRFI-13 inconsistency in tabulate procedure Olin Shivers (20 Mar 2001 23:10 UTC)
|
Re: SRFI-1/SRFI-13 inconsistency in tabulate procedure
sperber@xxxxxx
(21 Mar 2001 07:58 UTC)
|
Re: SRFI-1/SRFI-13 inconsistency in tabulate procedure
shivers@xxxxxx
(21 Mar 2001 15:36 UTC)
|
Re: SRFI-1/SRFI-13 inconsistency in tabulate procedure
Shriram Krishnamurthi
(21 Mar 2001 16:48 UTC)
|
More on SRFI-1/SRFI-13 inconsistency in tabulate procedure
Olin Shivers
(21 Mar 2001 21:01 UTC)
|
SRFI-1/SRFI-13 inconsistency in tabulate procedure Olin Shivers 20 Mar 2001 23:09 UTC
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