R.equals(new Error('XXX'), new Error('XXX')) this evaluates to false - the tests in equals.js test for it to be true
npm run test it passes
npm run pretest && mocha test/equals
dist/ramda.js that is commited is the build from the most recent tagged release.
npm run build prior, it was using ramda v0.18, which didn't yet have the equals implementation for Error
npm run test implicitly runs npm run pretest by convention of npm scripts prefixed with pre (and likewise for post).
@gilligan You can view it as a way to compose a computation, where every step takes the value(s) from the previous step, and emits zero or more new values for the next step. This allows the final computation to be used in any kind of reduction (map, filter, etc) of any kind of list (array, stream, generator, etc). The internal mechanism also has a built-in way to deal with short-termination (when doing a take(), for example).
Since you're extending the "step" function you end up with a means to "stream" your input list through the entire computation value by value, rather than doing .map().filter().take() and building up intermediate lists in between steps. So once you've coded a transducer it is more efficient, and more reusable than when you code a chain of operations.
I found watching this video over and over again quite helpful in gaining an understanding: https://www.youtube.com/watch?v=6mTbuzafcII
pipe([map(f), filter(g)], arr) go into([], compose(map(f), filter(g)), arr). I really like using them for processing object streams in Node with transduce-stream, because it allows me to work using my normal Ramda workflow on Streams: import throughx from 'transduce-stream';
stream.pipe(throughx(compose(
map(f),
filter(g),
take(5)
), {objectMode}))
pipe and compose from :point_up: December 12, 2015 10:11 AM have the same order of operations. I take it transducers do something to reverse the order of operations?
