On Tue, 25 Jun 2019, at 23:30, John Cowan wrote:
>
>
> On Tue, Jun 25, 2019 at 5:00 PM Linus Björnstam
> <xxxxxx@veryfast.biz> wrote:
>
> > 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.
>
> Only the most general generator constructor, make-coroutine-generator,
> uses call/cc. All the others use mutable state only, as do all the
> accumulators (reducers in your terms).
> > 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.
>
> You set up nested calls, with a generator constructor on the inside
> invoked by a generator operation, which is invoked by another, ...
> which is either pulled from by the program or accumulated using an
> accumulator.

Of course it can be done, but this is yet again lazy semantics. Applying a generator to something like a channel or a queue is best done on the reading/taking side whereas transducers are a much better match for the pushing side. And transducers can of course be extended on each side, whereas generator chains can grow in one direction only.

Transducers also have an interesting property of Being pretty easy to implement without hidden state without affecting the ergonomics of using them. There is nothing stopping you from passing state along the transduction, and even building it anew on each element, making them "pure". In the atria transducers (c++) everything is efficiently inlined, which is a luxury that is harder to manage in scheme.

It is still my opinion that implementing transducers on top of generators is doable, but probably not a great idea. However, for dealing with transforming collections without intermediate results, it is in many ways simpler to use generators.

>
> I'm now definitely going to create yet another SRFI that is upward
> compatible with 158 (which is upward compatible with 121), adding
> generator analogues of some of your procedures plus the three mentioned
> above. I think the chain procedure will in effect construct the nested
> calls described above, so it takes a generator constructor as the first
> argument and generator operations as the rest of the arguments and runs
> them left to right (left = inside, right = outside). Perhaps the last
> argument will be an accumulator, or I may keep that separate. The
> tricky bit is the arguments to be passed to the intermediate generator
> operators. To handle these nicely, it may have to be a macro.
>
> Detailed review of SRFI 171 to follow.
>
>
>
> John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
> LEAR: Dost thou call me fool, boy?
> FOOL: All thy other titles thou hast given away:
> That thou wast born with.
>