SRFI* Editor here. I enjoyed reading this post, and wish I had seen it sooner. I'm a big fan of transducers, and would like to see them used more in Scheme.

SRFI* Editor here. I enjoyed reading this post, and wish I had seen it sooner. I'm a big fan of transducers, and would like to see them used more in Scheme. I want to respond to one comment in the post about the SRFI process: Unlike a normal library, the whole point of SRFIs is that once they’re finalized, that SRFI is locked in stone. You can’t just add or remove or deprecate functions. You can change the default implementation if there’s a bug or add a post-finalization note about how the implementation should behave if there’s ambiguity, but you can’t just start picking and ripping at an SRFI. This kind of attitude towards software / APIs is anathemic to change. The idea behind SRFIs is that an author comes up with an idea, writes it down clearly, provides a sample implementation, gets feedback from the community, and tries to persuade Scheme implementations to adopt it. Because this is the goal, once a SRFI is published, it needs to be stable, not a moving target. That's why we treat it like a standard rather than a library. But there's no reason at all that new versions of a proposal can't be published as new SRFIs. In fact, some SRFIs, e.g. SRFI 231: Intervals and Generalized Arrays**, are the result of several rounds of refinement, each published as a separate SRFI. But if your Scheme implementation says that it supports SRFI N, you know what you're getting. I would welcome a SRFI from Thatgeoguy to help bring his work from CHICKEN Scheme to other Scheme implementations. We've brought many ideas from one implementation to others this way. * Scheme Requests for Implementation, https://srfi.schemers.org/ https://srfi.schemers.org/ ** https://srfi.schemers.org/srfi-231/srfi-231.html https://srfi.schemers.org/srfi-231/srfi-231.html