[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SRFI-1/SRFI-13 inconsistency in tabulate procedure

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

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).