> So the remaining difference to SRFI 158 seems to be that in the SRFI
> 171 model an explicit state ("result-so-far") is threaded through,
> while in the SRFI 158 model, an accumulator has to keep some internal
> state (and is thus less pure).

I've been wondering whether it would be fruitful to design a low-level
language in the style of C++ around transducers. Most of the messy stuff
in low-level programming is about allocating and freeing collections /
aggregate data structures. If the programmer could concentrate on
writing stateless transducers and those could be plugged into ready-made
collection types from an STL-like library, maybe programmers could avoid
most of the error-prone boilerplate while keeping zero-cost abstractions
and a simple memory management model. Since the transducers are mostly
stateless, they could perhaps be re-used for compile-time computation as
well.