by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 22:17
    CrossEye commented #2779
  • Jan 31 2019 21:04
    ArturAralin commented #2779
  • Jan 31 2019 20:08
    CrossEye commented #2779
  • Jan 31 2019 18:56
    buzzdecafe commented #2631
  • Jan 31 2019 18:09
    ArturAralin commented #2779
  • Jan 31 2019 16:18
    CrossEye commented #2779
  • Jan 31 2019 16:10
    CrossEye commented #2631
  • Jan 31 2019 16:06
    CrossEye commented #2777
  • Jan 31 2019 14:44
    ArturAralin opened #2779
  • Jan 31 2019 07:39
    inferusvv commented #2631
  • Jan 31 2019 03:07
    sespinozj commented #2771
  • Jan 31 2019 02:33
    machad0 commented #2771
  • Jan 31 2019 02:26
    JeffreyChan commented #2777
  • Jan 30 2019 14:30
    CrossEye closed #2777
  • Jan 30 2019 12:13
    vanyadymousky updated the wiki
  • Jan 30 2019 01:42
    JeffreyChan commented #2777
  • Jan 29 2019 21:06
    vanyadymousky updated the wiki
  • Jan 29 2019 16:28
    CrossEye commented #2777
  • Jan 29 2019 15:50
    mbostock commented #2772
  • Jan 29 2019 15:48
    CrossEye commented #2772
Ludwig Magnusson
@TheLudd
I'll stay on 15 for now then :)
Aldwin Vlasblom
@Avaq
But wouldn't you expect R.divide to be able to let divideBy20 = R.divide(20)?
Danielle McLean
@00dani
Non-serious suggestion: just make lt take only one parameter. lt(x, y) is just a long way to spell x < y, which you don't need, whereas lt(x) is useful.
Obviously it'd still return a function taking the second parameter, but the point is it's only allowed to take one argument at a time. Like a Real Haskell Function.
Aldwin Vlasblom
@Avaq
Maybe I'm wrong.
It's an odd one to think about, but my intuition went with R.lt(6) to test if the following value is less than 6. I think I've even used it like that to explain currying to colleagues. :P
Danielle McLean
@00dani
… hmm, actually, here's a thought. What if R itself were made callable, and then you wrote something like R(6).lt to express the section (6 <)? It's a hack, but maybe it's a good one?
Scott Sauyet
@CrossEye
@00Davo That would be an odd hack for Ramda. Seems almost... stateful.
Aldwin Vlasblom
@Avaq
@00Davo Yeah! And then we can implement a .chain() method so we can keep on chaining: R(6).chain().lt(3).equals(true).value()!
Danielle McLean
@00dani
It's not actually stateful. R() would just return an object full of partially-applied functions.
Aldwin Vlasblom
@Avaq
(I'm just kidding, of course) ;)
Haha, so when you call R(x), all of Ramda's functions are partially applied with x, and the results are returned in an object. That's an interesting way of doing things. :P
Scott Sauyet
@CrossEye
@Avaq, @00Davo: One thing that bothers me about the chaining syntaxes is that they usually only apply to the libraries built-in functions. In R.compose/R.pipe, there's nothing special about Ramda functions; you can pass anything you want. So, while you could do something like `R(3).someRfunc, the only way I know to make it more generic so that you could apply any other function you like is with a stateful registration process.
So yes, I've thought about this idea a bit! :smile: Although I never considered using R itself as the function.
@TheLudd: We'll see what happens. It's not at all clear that people will want to roll back the compose changes.
Tamas
@bling5630
@knubie yes, basically I looking for the point-free version, thank you, longer but better for me :)
Scott Sauyet
@CrossEye
@TheLudd: I find it broken now, but it's also simplified in some nice ways.
@bling5630: and look what you brought on! :smile:
Danielle McLean
@00dani
Yeah, R(x).whatever would be a lot less interoperable. Considering R.flip is available, though, maybe that's okay? R(x).f would really just be sugar specifically for the binary operator funcs.
Aldwin Vlasblom
@Avaq
@bling5630 This solution is much shorter: R.filter(R.where({length: R.both(R.lt(3), R.gt(6))}))! :P
Tamas
@bling5630
folks, thank you all of the ideas!
Aldwin Vlasblom
@Avaq
@CrossEye Doesn't that read like "filter where length is both less than three and greater than six"? :P
Ok I stop now.
Matthew Steedman
@knubie
@Avaq certainly has a point there
Scott Sauyet
@CrossEye

Right, which is why I use:

R.filter(R.where({length: R.both(R.gt(R.__, 3), R.lt(R.__, 6))}))

or

R.filter(R.where({length: R.both(R.flip(R.gt)(3), R.flip(R.lt)(6))}))
I don't love these solutions. I just haven't found anything I really like better.
Aldwin Vlasblom
@Avaq
But isn't the point of Ramda to provide "parameters [that] are arranged to make it convenient for currying"? If you have to R.flip them yourself all the time for legibility, that's inconvenient in my opinion.
Danielle McLean
@00dani
I'd const _ = R.__, which is a tiny bit more convenient to use when you have to. Still less convenient than having a function that's the right way around to begin with though.
Martin Algesten
@algesten
I'm obviously partial, but what is the argument for ramda's argument order. Doesn't all this flipping sort of imply that the whole API could benefit from reversing?
R.map(arr, fn);
Danielle McLean
@00dani
If flipping were more broadly necessary than in a few very specific cases, which basically are just "the non-commutative binary operators", then maybe. But for the most part the order it's in works out pretty well.
Aldwin Vlasblom
@Avaq
@algesten The argument is that arguments are passed in an order convient for currying. So R.map takes it's data last, because it's a much more common case to want to create a partially applied map with a mapper, than it is to create a partially applied map with it's data, waiting for different mappers to be passed-in
Martin Algesten
@algesten
ok. makes sense. it doesn't take long to get used to reverse currying though ;)
Aldwin Vlasblom
@Avaq
@algesten The argument we are having now is specific to gt and lt, where that idea seems to have failed to make it. :P
Scott Sauyet
@CrossEye
It also affects subtract, divide, modulo. But it's still a very small minority of Ramda functions.
@algesten: I have been fascinated by fnuc since I first saw it. But I've never been quite convinced. map(square) seems an obvious abstraction, and currying is familiar to most functional programmers in that format.
Aldwin Vlasblom
@Avaq
@CrossEye Ha, just ran into you SO question (via fnuc) - seems this is not a new problem what-so-ever. :)
Scott Sauyet
@CrossEye
Was just about to post the history of this issue: See #175, #368, and then where we reverted it in #388.
Martin Algesten
@algesten
@CrossEye i don't expect fnuc to go anywhere. but i'm happy you find it interesting. i'm all pro ramda and it's role in FP for javascript.
Aldwin Vlasblom
@Avaq
Ah I see. I agree with the conclusion of #388. No way should lt(x, y) !== lt(x)(y)! But I just feel the settled-upon order of arguments is wrong. I disagree with your statement that lt(10, 12) is the only comfortable way to write "is 10 less than 12", because under that reasoning map(arr, func) would also be the preferrable version.
Danielle McLean
@00dani
I'm not sure I follow that argument. map(func, arr) reads "map func over arr", which is totally reasonable.
Martin Algesten
@algesten

For a coffeescripter this makes so much sense.

map arr, (a) -> blaha

Granted could also be solved.

map(arr) (a) -> blaha
especially when the function needs a couple of lines
Aldwin Vlasblom
@Avaq
But isn't the reason libraries that came before chose a function-last interface because it reads and writes nicer? If I wouldn't consider currying, I would completely agree with their decisions. I feel ramda just does one thing: Giving up comfort for curry. :D
Which, in the end, turns out to be pretty comfortable in FP, because you're usually just passing one argument per call.
Matthew Steedman
@knubie
For Ramda, I think it's more important that a function read better partially applied, than it is for it to read better fully applied.
So I agree with @Avaq, most of the time I'm using functions like lt, gt, subtract, they're partially applied
and I either end up having to supply a placeholder or flip them
In fact, the first time I used subtract, I had just assumed the arguments were in the reverse order that they're currently in.
Scott Sauyet
@CrossEye
I think the reason that libraries that came before chose a function-first interface is that they were converting pseudo FP method-based libraries such as Array.prototype.map, and there it just felt more natural to convert arr.map(fn) to map(arr, fn). If they had been considering currying, or spending a lot of time looking at other languages that do this, they might well have chosen a different order.