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
@bling5630 if you're looking for a point-free solve something like this would work:
var filterByLength = R.filter(
  R.converge(
    R.and,
    R.compose(
      R.lt(3),
      R.prop('length')
    ),
    R.compose(
      R.gt(6),
      R.prop('length')
    )
  )
);
that's obviously longer, though
Aldwin Vlasblom
@Avaq
Something like R.filter(R.where({length: R.allPass([R.gt(6), R.lt(3)])})) is shorter.
Danielle McLean
@00dani
Pity Ramda doesn't make functions into applicatives. filter $ ((> 3) <&&> (< 6)) . length
Matthew Steedman
@knubie
This would work too R.filter( R.compose( R.contains(R.__, R.range(4,6)), R.prop('length')))
Scott Sauyet
@CrossEye
I'd still choose R.lt(R.__, 3) or R.flip(R.lt)(3) for readability.
Aldwin Vlasblom
@Avaq
@CrossEye I was just going to ask; What's up with the argument order of gt and lt? It had me confused for a moment. I expect var lt6 = R.lt(6) to make a predicate function that returns true when the argument is Less Than 6.
Danielle McLean
@00dani
It's because R.lt(x, y) means x < y and curried arguments apply left to right. https://github.com/algesten/fnuc exists mainly because that's Kind of Weird.
Scott Sauyet
@CrossEye
@00Davo: the language doesn't really offer us the opportunity. We did try something once, but it wreaked havoc with one's sense of what currying would do.
Danielle McLean
@00dani
Yeah, fnuc's approach to currying is also pretty confusing.
Scott Sauyet
@CrossEye
@Avaq: but what would you expect R.lt(7, 12) to return?
Danielle McLean
@00dani
Could "reverse" currying like fnuc be added, but only applied in Ramda itself to lt and similar functions? Or would that be too inconsistent?
Since those functions are all binary it shouldn't be too difficult to figure out how the reverse-curry should behave, I figure.
Scott Sauyet
@CrossEye
that's what we did try. The resulting confusion is what got is to add the placeholder.
Danielle McLean
@00dani
Dang.
Oh hey, speaking of: Why's the placeholder an object with a specially-named field on it? Just making it an empty object and then comparing against that in the functions would work too, no?
Aldwin Vlasblom
@Avaq
@CrossEye Well, I would have to think about it for a brief moment, taking into consideration that Ramda tends to "swap" arguments, and conclude that it would probably return false because 12 is not less than 7.
Scott Sauyet
@CrossEye
It's pretty easy to make a universal claim that fn(a, b) === fn(a)(b) for Ramda functions. To say its the same except for certain non-commutative operators was problematic. And we probably couldn't just say binary functions, either, or would you expect R.map(fn, list) but R.map(list)(fn) ? Madness.
@Avaq where does Ramda swap arguments?
Or are you suggesting that we should?
Ludwig Magnusson
@TheLudd
I seem to remember something about compose being broken in the latest release. Is that correct?
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!