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 co...@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
