-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shaving behavior #29
Comments
We could split it into it's own module fn::shave(3)::curry(); What say @tomekwi @hemanth @davidchase ? |
👎 Too much of chaining with |
It’s not a side-effect. It’s 100% pure and well-documented. Have you read the discussion at #17? |
plus(1, 2, 3); //» 6
plus(1)(2, 3); //» 6
plus(1, 2)(3); //» 6
plus(1)(2)(3); //» 6 As for shaving – since it’s not possible to plus(1)(2, 3)(4); – it shouldn’t be possible to do this (the last argument should have no influence on the result): plus(1, 2, 3, 4); That’s most logical and least astonishing to me. But feel free to disagree @rtm! |
Created a new org as a home for |
“thisables” – the best name ever! 😃 |
I am wondering if shaving is something that makes sense as a feature of
curry-this
.Shaving is a good thing, and of course there are times when we want to do that. However, to me it makes more sense to have this be a separate feature (probably in some other functional library), rather than baked into currying. Is there a precedent for shaving in other currying libraries? If I need shaving, I can write it quite easily as:
I'd rather do this explicitly myself rather than have it be a side effect of passing placeholders to the curry function. In this approach,
fn::curry(_, _)
is equivalent tofn::curry()
, with no shaving implications.The text was updated successfully, but these errors were encountered: