Hi Linus,

thank you for your reply. I still have to go through it in detail, but
here are a few first comments/questions:

Am So., 3. Mai 2020 um 19:12 Uhr schrieb Linus Björnstam
<xxxxxx@veryfast.biz>:

> You are right that the use cases overlap, and currently all it boils down to is eager vs lazy semantics (or push vs pull). There is a slight difference in ergonomics in that you can extend a transducer on both sides:

I suppose that you call a generator's semantics a pull semantics. So
an accumulator in the sense of SRFI 158 will have a push or eager
semantics, right? So SRFI 158 can support both styles.

In SRFI 171, the procedures that apply transducers (like
LIST-TRANSDUCE) act like generators The reducers of SRFI 171
correspond to accumulators while the transducers are maps that are
eventually to be composed with accumulators.

Is this correct?

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).

Thus, I am wondering whether on can conflate both concepts into one of
generators and accumulators that are based on some state that is
threaded through (I am thinking of Haskell's state monad here).

Thanks!

Marc