Transducers.js Round 2 with Benchmarks

Post by tel » Mon, Oct 13, 2014, 1:57 PM UTC

Thomasdah wrote: post #20

Touche wrote: post #13

What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?

The goal is to be less-verbose. You are able to use tansducer-based functions (map, filter, ...) on any datastructure that is iterable. For me, performance is a bonus. I do not know how this compares to a monad/monoid. If anyone can explain, please go ahead. Thx!

Monad/Monoid are a different category of things from transducers—think of them more like an interface than a thing. For instance, a basic model of Transducer is as follows

    type Trans a b = forall r . (r -> b -> r) -> (r -> a -> r)

and it turns out that this is isomorphic to (e.g. an optimization of) the list Kleisli arrow

    type KleiList a b = a -> [b]

and lists are monads. For a slightly different reason, this argumentation leads me to believe that Transducers ought to be monads via the Reader/List transformer stack. I haven't verified it, however.

Transducers could be monoids, too. You'd need to have two operations like so

    zero :: Transducer a b
    add  :: Transducer a b -> Transducer a b -> Transducer a b

and perhaps there would be necessary restrictions on the choices of `a` and `b`. It's immediately obvious we could make this work if `a` and `b` were equal

    zero :: Transducer a a
    add  :: Transducer a a -> Transducer a a -> Transducer a a

as this is now just the "identity" transducer and transducer composition which satisfy all the laws of monoid.

Post by Touche » Mon, Oct 13, 2014, 4:13 PM UTC

Thomasdah wrote: post #20

Touche wrote: post #13

What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?

The goal is to be less-verbose. You are able to use tansducer-based functions (map, filter, ...) on any datastructure that is iterable. For me, performance is a bonus. I do not know how this compares to a monad/monoid. If anyone can explain, please go ahead. Thx!

You are able to use transducers on any datastructure that implements the protocol. Which means usually implementing it yourself.

for/of solves this in JavaScript. I don't see the usability improvement this presents. I'm not being a naysayer. I hope I'm wrong here, I'm just asking.

Re: Transducers.js Round 2 with Benchmarks

Re: Transducers.js Round 2 with Benchmarks