John,

I am not in favor of having multiple different versions of the SRFI document and reference implementation, due to the confusion that arises. A finalized SRFI is immutable; that has been the rule since the beginning, and to date there have been no exceptions. I agree with Arthur that in this case a link to a description of the problem and corrected code, posted prominently near the beginning of the SRFI, is preferable to having two different versions of the SRFI.

On Wed, Nov 4, 2015 at 12:10 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
Arthur A. Gleckler scripsit:

> (The reference
> implementation was included in the text of the SRFI, which was finalized
> years ago, and this change isn't a fix for an error, so I decided not to
> modify the reference implementation, even in the repo.  This link, though,
> should help implementers find this improvement.)

IMO this unduly favors form over substance.  You'd apply a fix to a
performance bug in a sample implementation that was in a separate file.
(At least I hope you would, because I intend to fix correctness and
major performance bugs in the sample implementations of my SRFIs and hope
you'll apply the changes I send you.)  The fact that the implementation is
physically incorporated in the document also containing the specification
doesn't make it part of the specification.  In short, the bug should
be fixed directly in the code with a notice that this has been done and
by whom.  If Phil is agreeable (and I gather he is), I think that would
be best overall.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann
man auch in grossen Dingen nicht vertrauen.  --Albert Einstein on honesty