Olin Shivers <xxxxxx@tokyo.cc.gatech.edu> writes:

> What do people think?

Is there a procedure in place for extending existing SRFIs in a
backward compatible way?  If so, I would extend SRFI-1 to also accept

  (list-tabulate PROC LEN)

in addition to

  (list-tabulate LEN PROC)

and deprecate the latter variant, with the choice for the implementor
to be vocal about this deprecation (i.e. issue an annoying warning
when the latter variant is used).  The two variants should be readily
distinguishable based on the type of the first argument.

When there is no explicit way to extend an SRFI, I would issue a new
SRFI that provides the extended version of SRFI-1, and which will
answer for requests of both SRFI-1 and the new one.

> Argument for choice A (doing nothing):
>     General tiredness, unwillingness to move to a new SRFI for such a small
>     change.

If this argument has weight, it might be an indicator that the SRFI
process needs to make the cost of changing, or rather, extending an
existing SRFI less daunting.

While technically there might not be a difference between extending an
existing SRFI and issuing a new SRFI that subsumes the functionality
of the old one, it might make for a cleaner structure of the SRFI
collection when it is easy to see what is a new version of a module,
and what is a new module.  Maybe the IETF distinction into RFCs and
STDs can be an inspiration (although nobody really refers to STDs, as
it seems (RFC0822 vs STD0011)...).