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.
------- Blind-Carbon-Copy To: srfi-1@xxxxxxxxxxxxxxxxx Cc: srfi-editors@xxxxxxxxxxxxxxxxx Subject: Re: More on SRFI-1/SRFI-13 inconsistency in tabulate procedure In-reply-to: Your message of "21 Mar 2001 16:01:23 EST." <k1u24mygyk.fsf@xxxxxxxxxxxxxxxxxxx> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 21 Mar 2001 21:01:14 -0500 From: Dave Mason <dmason@xxxxxxxxxxxxxxx> (I've removed srfi-13 from the followup list; I don't see any reason to continue to send there.) >>>>> On 21 Mar 2001 16:01:23 -0500, Olin Shivers <shivers@xxxxxxxxxxxxx> said: > 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. > A. Do nothing. Live with the inconsistency for now. > B. Change LIST-TABULATE to be (LIST-TABULATE proc len) -> list This >[...] > 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. This would be perfectly reasonable. As one of the srfi-editors, let me point out that there is a policy already in place for making SRFIs deprecated. SRFI-24 (or whatever) would be marked as superceding SRFI-1 during the discussion period, and as soon as SRFI-24 was marked final, SRFI-1 would be marked deprecated. ../Dave ------- End of Blind-Carbon-Copy