Per Bothner scripsit:

> >But for the time being, I have little motivation to go that route.  It's
> >mentally straining for me to go through this type of code.  I wish to
> >allocate my time and energy to other things.
>
> That is your choice.  It is also my choice to reject your submission.

Well, of course there is no reason why there should be only one
implementation of any given SRFI.  (For example, there is the sample
implementation of SRFI 1, which is widely used, and then there is the
lightweight Chibi implementation.)  The implementation that lives at
(or with) srfi.schemers.org is just a sample; it does not constitute a
reference implementation, even though the SRFI process document uses that
term.  Given a conflict between it and the spec, the spec always wins.

What isn't particularly clear is who has change control over the sample
implementations.  For the SRFIs themselves, change control clearly lies
with the editors: once a document is finalized, the authors can't go
changing it (although IMO a reasonable allowance for typos and editorial
glitches should be made -- SRFIs are not RFCs).  For the implementations,
it has always been assumed that the implementation authors have change
control, but the SRFI process documentation is silent on the point.

In particular, there seems to me no reason why alternative implementations
can't be added to the git archive, perhaps in subdirectories.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Is not a patron, my Lord [Chesterfield], one who looks with unconcern
on a man struggling for life in the water, and when he has reached ground
encumbers him with help?        --Samuel Johnson