These are chat archives for ramda/ramda

16th
Jul 2017
Jonah
@jonahx
Jul 16 2017 17:42
super common problem whose best solution i’m unsure of: in every project, i end up with a file called ramda_utils.js or similar — which contains the kind of util functions that exist in the ramda cookbook, generally. obviously there’s plenty of overlap among projects, but at the same time not enough overlap to justify a single, ever-growing ball of mud collection that i’d include in any project. the question, what is the best way to maintain re-usability across projects, while still only “importing” (in the general, non implementation specific sense of that word) the functions i need into a particular project. on one extreme there is the node-esque “leftPad” philosophy where you package each function separately, but that approach feels wrong to me, mostly because functions do form semantically related clusters. on the other end, you could be forever curating a “date_utils” and a “math_utils” and so on, but resolving conceptual overlap, or moving functions from one module to another, etc, also seems like a burden. how do you deal with this?
Luis Felipe López G.
@luishendrix92
Jul 16 2017 20:06
Does anyone know what's the haskell equivalent of Ramda's R.converge ?
I was playing around with Monoid and Applicative but couldn't find something similar
Denis Stoyanov
@xgrommx
Jul 16 2017 21:09
@luishendrix92 for example u can use sequence sum $ sequence [(+10), (+20)] 10
Luis Felipe López G.
@luishendrix92
Jul 16 2017 21:25
I guess it'd be savvy to do a foldl to generalize the operation
after sequence
foldl1 finalOperation $ sequence fs x
for lists of functions with length greater than 1
Denis Stoyanov
@xgrommx
Jul 16 2017 21:37
@luishendrix92 it was just example