[deleted]
Transducers for JavaScript
11–20 of 27 posts
Re: Transducers for JavaScript
#12Re: Transducers for JavaScript
#13Friendly advice: maybe also include the output of the example code in the README.
Re: Transducers for JavaScript
#14Earlier quoted context omitted.
I think it only iterates over the collection once.
Then what happens to operations that access the collection? like third argument in JavaScript's native forEach?
That's what a zipper [1] is good for. It gives you access to the rest of a collection relative to the current position.
[1] http://en.wikipedia.org/wiki/Zipper_%28data_structure%29
Re: Transducers for JavaScript
#15It'll be interesting to look into how the Clojure people implemented this. I released the same library a few weeks ago: https://github.com/jlongster/transducers.js, and I'm about to release the next version with an API almost the same as the OP. I think mine has more integration with JS data structures and stuff like monkeypatching existing ones (like immutable-js) to work with this. We'll see how all this shakes out though; not sure if it'll be good to converge on one official library or if it's ok to have multiple.
Re: Transducers for JavaScript
#16It'll be interesting to look into how the Clojure people implemented this. I released the same library a few weeks ago: https://github.com/jlongster/transducers.js , and I'm about to release the next version with an API almost the same as the OP. I think mine has more integration with JS data structures and stuff like monkeypatching existing ones (like immutable-js) to work with this. We'll see how all this shakes ou…
ClojureScript?
Re: Transducers for JavaScript
#17Notes and examples of Transducers and Reducers
https://gist.github.com/runexec/06b56a9dbd15e43145b9
Re: Transducers for JavaScript
#18As somebody with more experience with Haskell and Scala than Clojure - how to Transducers differ from Functors in Haskell?
On the surface they seem very similar.
Re: Transducers for JavaScript
#19So I checked the definition of a transducer,but i'm not smart enough to get it. What the difference between that library and say lodash where I can bind and compose functions? because it seems like the same stuff var f=_.compose( _.partialRight(_.filter,isEven),_.partialRight(_.map,inc)) ; or something.
Transducers allow the abstraction of algorithmic transformations independent from the input and output, and even the process of iteration.
Whereas lodash operates on arrays and objects calculating intermediate results, transducers simply define the transformation in terms of functions similar to what you pass reduce: start with a memo, execute a function with a memo and an item, return the possibly transformed memo for the next iteration. Once you abstract the transformation away from the data, you can apply the same transformations to different processes that start with an initial value and step through a result. One benefit is that you can compute the result in one pass (without intermediate results). Another is you can use the same transformation in different contexts (lazy lists, indefinite sequence generation, CSP, event streams, etc.).
The source could be anything that produces a sequences of values: streams, iterators, callbacks, immutable-js, etc. You simply have to define (external to the transducer) how you append each item to the supplied result. The "step function" that knows how to append results to values is passed to the transducer, and the transducer executes the step function when reducing over results.
It's interesting you mention lodash in the context of transducers, as I have been developing my own take on transducers closely following the underscore API [1].
Re: Transducers for JavaScript
#20So I checked the definition of a transducer,but i'm not smart enough to get it. What the difference between that library and say lodash where I can bind and compose functions? because it seems like the same stuff var f=_.compose( _.partialRight(_.filter,isEven),_.partialRight(_.map,inc)) ; or something.
Transducers allow the abstraction of algorithmic transformations independent from the input and output, and even the process of iteration.
Whereas lodash operates on arrays and objects calculating intermediate results, transducers simply define the transformation in terms of functions similar to what you pass reduce: start with a memo, execute a function with a memo and an item, return the possibly transformed memo for the next iteration. Once you abstract the transformation away from the data, you can apply the same transformations to different processes that start with an initial value and step through a result. One benefit is that you can compute the result in one pass (without intermediate results). Another is you can use the same transformation in different contexts (lazy lists, indefinite sequence generation, CSP, event streams, etc.).
The source could be anything that produces a sequences of values: streams, iterators, callbacks, immutable-js, etc. You simply have to define (external to the transducer) how you append each item to the supplied result. The "step function" that knows how to append results to values is passed to the transducer, and the transducer executes the step function when reducing over results.
It's interesting you mention lodash in the context of transducers, as I have been developing my own take on transducers closely following the underscore API [1].