Open TheLudd opened 7 years ago
This makes sense to me. I don't think the prior art should dictate our parameter order.
Of course this would be a major breaking change.
@CrossEye glad we agree at least =)
I like it. My only thought about a PR here is that the general consensus seems to be that we should rip transducers out of the core, so I'm not sure this is worth a PR since it is a breaking change?
@kedashoe: We'll see if I'm really back on doing some real Ramda work, but if so, I agree. I think we want this done with transducers wherever they land, but it's not clear yet where that will be.
the general consensus seems to be that we should rip transducers out of the core
Yes, but I have been having trouble imagining how to do so in such a way that they can be transparently plugged in.
I'm having problem in understanding something kinda related to "order". I'm using R.into with a composed transducer but the order of the functions calls inside R.compose is the opposite (left to right), like pipe, and vice-versa: using R.pipe the functions are called from right to left. https://goo.gl/ZuKUvN
Is this the expected behaviour?
Yes, this is the expected behavior. There are several good articles, mostly Clojure related:
I realized something yesterday about
transduce
that has bothered me for a long time. Every time I use it I pretty much make a custom transducer function but the accumulator function and the initial argument pretty much only varies in two ways.flip(append)
and acc is[]
add
and acc is0
Because of this, it seems a better argument order would be
transduce(xf, acc, transducer, list)
. With this I could createtransduceToList = transduce(flip(append), [])
transduceToSum = transduce(add, 0)
I suspect that other uses of
transduce
would follow the same pattern.I realize that
transduce
is not a ramda invention and that it probably follows a format from somewhere else. I just wanted to bring this up for discussion.