This page is part of the web mail archives of SRFI 1 from before July 7th, 2015. The new archives for SRFI 1 contain all messages, not just those from before July 7th, 2015.
Olin Shivers <shivers@xxxxxxxxxxxxxxxxxxx> 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)...).