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

Re: 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.



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