On Tue, Nov 3, 2015 at 10:10 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

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.

Since it's rare for a SRFI document itself to contain the reference implementation rather than pointing to one outside, this issue is not likely to come up again, so I'm not going to worry about it now.

I am happy to apply fixes for correctness and major performance bugs in the reference implementations for finalized SRFIs as long as:

the reference implementation is outside the document, e.g. in a Git repo
the change doesn't change the SRFI's API
the change is announced on the SRFI mailing list and is uncontroversial

Since such changes are tracked by version control and don't cause divergence from the agreed-upon spec. for the SRFI, that seems fair and practical.