[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More on SRFI-1/SRFI-13 inconsistency in tabulate procedure
- Subject: Re: More on SRFI-1/SRFI-13 inconsistency in tabulate procedure
- From: Dave Mason <dmason@xxxxxxxxxxxxxxx>
- Date: Wed, 21 Mar 2001 21:01:14 -0500
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."
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
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
------- End of Blind-Carbon-Copy