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

Re: More on SRFI-1/SRFI-13 inconsistency in tabulate procedure



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