The transduce form can very well be replaced by generators, although I doubt you will get the same performance out of it in most schemes where call/cc is expensive. The problem is all the other use cases. Generators have lazy semantics where values are "pulled" through. Transducers are eager where values are pushed through.

This matters very little when collections are transformed, where a lazy approach also means no intermediate collections, but the general transformation side is harder to imagine using generators. How would you suggest passing a generator as a step in an asynchronous channel would look like? I can see how it could be made to work, but I have a harder time understanding how it can be made general. A transducer returns a reducing function. Pushing a value through it is trivial and works regardless of context. A generator approach would have to know how to pull the value through.

Best regards
  Linus Björnstam

On Tue, 25 Jun 2019, at 14:03, Amirouche Boubekki wrote:
> Hello all,
>
>
> Linus thanks for this contribution the SRFI process.
>
>
> As you might know, both srfi-167 (okvs) and srfi-168 (nstore)
> rey on srfi-158 (scheme generators).
>
> My needs were mostly covered by scheme generators. I added
> two helpers generator-scatter and nstore-query.
>
> generator-scatter will unroll a generator of generators as flat generator.
>
> nstore-query will chain generators operations. Here is the
> implementation:
>
>  (define-syntax nstore-query
>  (syntax-rules ()
>  ((_ value) value)
>  ((_ value f rest ...)
>  (nstore-query (f value) rest ...))))
>
> It is like compose for generators. With that one ends up coding things like:
>
> (generator->list (nstore-query (list->generator (iota 10))
>  (lambda (g) (gfilter odd? g))))
>
> Which is similar to the following transducer:
>
> (transduce (tfitler odd?) (iota 10))
>
> It seems to me transducers can be implemented in terms of generators.
> And that the point of transducers it makes it easy to compose operations
> on list (but similarly on generators too) using high order functions unlike
> scheme generator.
>
> I am wondering whether transducers would not be better implemented
> as an extension to scheme generator aka. srfi-158
> <https://srfi.schemers.org/srfi-158/srfi-158.html>. Or something in
> like that.
>