Comments on "Transducers & Effects – Mike Innes"

[tkf]

@MikeInnes

This is quite a different way of thinking about it, but the core idea is the same: use the same syntax to define a sequence which can either eagerly (and efficiently) produce values upfront, or lazily produce them on demand.

It’s nice to know we arrived at similar solutions from very different angles

@MikeInnes

The main motivation for into is that if you know what data structure you’re producing, you can avoid the state machine in some cases (eg building an array via collect ).

The corresponding API I use in BangBang.jl (one of the spin-off/dependency libraries of Transducers.jl) is append!!(dest, src) -> dest′. It is driven by the foldl of src by default. But it’s possible for dest to take the control and drive src iteration via iterate.

@MikeInnes

by dispatch (doing the right thing for the data structure)

I’d even say Julia is partially doing this already as of Transducer as an optimization: map, filter and flatten by tkf · Pull Request #33526 · JuliaLang/julia. Here, foldl dispatches on the lazy transformed iterator types and apply the corresponding transducers to the reducing step function. OK, this still works only with functions calling foldl in their call chain. However, it should be possible to lower for x in xs to foldl as I demonstrated in FLoops.jl so that the native for loop syntax is lowered to appropriate code via the dispatch mechanism.

@MikeInnes

Here’s how I’d write zip :

What I wasn’t sure was that there might be some magical way to directly do it with handle. But the effect handler seems to need a corresponding scope and using next(xs) looks like a clean solution to me.