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
Matthew Steedman
@knubie
@CrossEye I think he's referring to the data being the last argument, as opposed to a library like underscore where it's the first
Scott Sauyet
@CrossEye
Yes, today or tomorrow I'm going to raise an issue to fix it.
Ludwig Magnusson
@TheLudd
@CrossEye It does not seem to be completely broken. Is there a good defenition of when it fails?
Scott Sauyet
@CrossEye
well, #1318 is there for discussion already. I'm going to create a PR.
Aldwin Vlasblom
@Avaq
@CrossEye Yeah, I mean reversed, as opposed to say, underscore. The data comes last. When I'm unsure about which of the arguments goes for "data", I use the "assign partially applied function to variable and ask myself what I would expect it to do"-method. Though that method seems to fail for Ramda's gt and lt, like I explained. It's not the end of the world, but Ramda's argument order has started to make a lot of sense to me, until I met gt and lt just now. :P
Scott Sauyet
@CrossEye
Compare 0.15: http://bit.ly/1PUEiW6 to current:http://bit.ly/1PUEiWa on
R.pipe(R.add, R.map)(10)([1, 2, 3])
Yes, for a while we had flipped versions of some of these functions. We lost them when we thought it was all figured out with the operators idea. The whole thing was started by my looking for good names for flipped versions of lt, gte, etc. We had subtractN, divideBy, and such, but no good names for these.
I'd love a better solution, but R.lt(7, 12) just seems to me it should return true and divide(20, 5) should return 4 not 0.25. fnuc was built around trying to solve this issue, but I think it ends up somewhat incoherent.
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