-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Stdlib: Add function composition combinator #12770
Conversation
My opinion based on a quick look:
|
While overuse of infix operators can certainly harm code readability, I think that more sparing/deliberate usages of them can make things clearer. For the purposes of this PR consider |
There is also the issue that the choice of
In other words, the name of the operator is controversial, and it is better to split this discussion on the operator from the simple I am personally in favor of settling a name for the composition operator, but this is better done in a large discussion rather than in a PR. |
This has already been discussed to death here. |
In Preface we use |
I removed the infix operator for now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I am in favour of this addition. As it touches the standard library, a second approval from a core dev is needed.
Friendly ping. This is a simple PR to review; we still need a second reviewer; volunteers welcome! |
I looked at it today. It's ok with me if someone wants to ack on my behalf. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved (on behalf of @dbuenzli, but I'm happy with it, too)
Thanks for the prompt review! I took the liberty of amending the Changes file accordingly. |
Add
Fun.compose
andStdlib.(@.)
for function composition. Useful when wanting to apply multiple functions when wanting to map over a list asList.map (f @. g) l
exposes the high-level logic in a clearer manner thanList.map (fun x -> f (g x)) l
. The choice of@.
was made because Haskell uses.
for function composition and there is probably a clearer choice that could be made for OCaml.