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

More on 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.

We can't change SRFI's 1 or 13 in the fashion I proposed in the last msg, 
as they are both final. So let me restate the problem.

[By the way, if you sent mail to either srfi mailing list, it was lost.
 Those mailing lists have just now been re-activated; mail to them will
 work now.]

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 basically two possibilities:

A. Do nothing. Live with the inconsistency for now.

B. Change LIST-TABULATE to be
    (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

   This would require issuing a *new SRFI*, e.g. SRFI-24, which would be identical to
   SRFI-1 except for the parameter order in LIST-TABULATE.

What do people think? 

Argument for choice A (doing nothing):
    General tiredness, unwillingness to move to a new SRFI for such a small
    change. Might be better to wait a year and see if anything other problems
    emerge, then all can be fixed in one lump.

Argument for choice B (issuing a new SRFI):
    The earlier you establish a convention, the more it pays off.
    Less code is written that will break. More cross-module consistency
    is established. The "cost" of switching to a new SRFI is pretty
    trivial. Waiting for a year makes the cost of switching more painful
    to the community, as more code will be written with the older API.

I am pretty evenly split about this, though on reading the two arguments,
B seems like the "right thing."

We could make the wait-a-year approach more palatable by unofficially 
announcing that SRFI-1 clients should avoid LIST-TABULATE.

Comments? Send them to srfi-1@xxxxxxxxxxxxxxxxx (i.e., not to comp.lang.scheme).