4 ms·

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

• tel 12y ago
  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.
• Touche 12y ago
  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.