These are chat archives for ramda/ramda

13th
Jul 2015
Asaf
@asaf-romano
Jul 13 2015 04:54
Is the nArgs->unary->unary... good old path of pipe/P (and the inverse for compose/P) changed in any way, apart currying?
David Chambers
@davidchambers
Jul 13 2015 05:04
That should be the same.
The “first” function can have any arity; the remaining functions are expected to be unary.
I’m writing the upgrade guide for v0.16.0 now. :)
Asaf
@asaf-romano
Jul 13 2015 05:34
@davidchambers By the way, did you see my reply from a couple of days ago
David Chambers
@davidchambers
Jul 13 2015 05:36
Yes, I did. We should add an internal function for determining a function’s name, and use it in _toString.
Asaf
@asaf-romano
Jul 13 2015 05:51
Regarding pipe, I read it as the support you were going to add to multiple arguments along the pipe is off the table for now?
I'll file a ticket on constructor.name
David Chambers
@davidchambers
Jul 13 2015 06:02

Yeah, supporting functions of arbitrary arity in pipe and compose proved problematic. Here’s a simple example of something that breaks:

R.pipe(R.add, R.map)(10, [1, 2, 3])

We’re expecting [11, 12, 13], but we’ve actually passed 10 and [1, 2, 3] to R.add. Oops!

Asaf
@asaf-romano
Jul 13 2015 07:02
@davidchambers I admire you for the courage to even try that :)
David Chambers
@davidchambers
Jul 13 2015 07:04
I still think there’s something there, but it can’t be the compose function. Perhaps R.compose could be for composing unary functions, and R.composeX (for some X) could be for composing functions of arbitrary arity?
Asaf
@asaf-romano
Jul 13 2015 07:04
one you're not unary, it's very unlikely that x would be the same for all functions in the pipe
David Chambers
@davidchambers
Jul 13 2015 07:05
Oh, I don’t mean X as in some number. I just mean some letter (a suffix). We have R.composeK and R.composeP, so I thought we’d think of a one-letter suffix for the new function.
I haven’t thought of a suitable suffix. If this were Haskell we could call it R.compose'. ;)
asaf-romano @asaf-romano notes himself to discuss compose.promised etc one of these days
Asaf
@asaf-romano
Jul 13 2015 07:08
What would be nice is if there was some way to automate this: pipe(x => [x, 1], apply((x, y) => ...)
David Chambers
@davidchambers
Jul 13 2015 07:10
It’ll get a bit nicer once we can write [x, y] => … rather than R.apply((x, y) => …).
Asaf
@asaf-romano
Jul 13 2015 07:10
that's a problem I encounter very often, esp. when promises are involved, and then I cannot workaround this with converge.
for clients, that is.
what CrossEye experienced there would probably be my day to day experience to.
I'm a little skeptical about bi/tri-compose, honestly. Just being practical, with the JS IDEs situation and the lack of types in the languages, it's going to be very hard to get your pipe right, and very easy to introduce all sorts of wtf bugs.
Asaf
@asaf-romano
Jul 13 2015 07:17
in other news, wasn't there some R.something wrapper around the delete operator
David Chambers
@davidchambers
Jul 13 2015 07:17
R.dissoc?
asaf-romano @asaf-romano should add a renameProperty function to the cookbook
Asaf
@asaf-romano
Jul 13 2015 07:18
thanks
probably for my own use I guess :)
ah