These are chat archives for ramda/ramda
dissocPath. The way
partial.lensesdoes it is by essentially specialising the lens representation (allowing path arrays as lenses) and the implementation to deal with those cases. I wouldn't say it is pretty internally, but I would argue (and have argued) that it is preferable to optimize a library so that one doesn't have to worry about those same issues elsewhere.
partial.lensesalso uses a different and more limited (and for that reason significantly faster) currying implementation, that doesn't support placeholders or variadic arguments, but does facilitate staging (unlike Ramda's currying). According to my tests, currying in JS is a major performance killer, unfortunately.
f(a, b), calling
f(a), means you can do some heavy lifting on
a, instead of doing that when it's called with
curryN(4, ...). It results in a curried function that takes 4 arguments. However, it actually takes arguments in two stages. It first takes two arguments, performs a bit of computation, and then takes two more arguments. The staging allows one to avoid redoing the computation in the middle. Follow the definitions from here to see how they are using
constAs. The staging is also mentioned in the documentation and is shown in the approximate type sig (tooltip of the header link) by means of parentheses (F# uses a similar notation).
toStringand better error messages?
Is there a good Ramda-y way of turning:
const x = ['a', 'd', 'g']; const y = ['b', 'e', 'h']; const z = ['c', 'f', 'i'];
as @safareli pointed out,
const zippy = zipWith((a, b) => a + b) compose(join(''), zippy(x), zippy(y))(z)
const x = ['a', 'd', 'g']; const y = ['b', 'e', 'h']; const z = ['c', 'f', 'i']; compose(join(''), unnest, transpose, unapply(identity)) (x, y, z)
unapply(identity)and just pass
[x, y, z]into the function instead.