Skip to content
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

lib/trivial: add pipe function #71348

Merged
merged 1 commit into from Oct 21, 2019
Merged

lib/trivial: add pipe function #71348

merged 1 commit into from Oct 21, 2019

Conversation

Profpatsch
Copy link
Member

@Profpatsch Profpatsch commented Oct 18, 2019

pipe is a useful operator for creating pipelines of functions.

It works around the usual problem of e.g. string operations becoming
deeply nested functions.

In principle, there are four different ways this function could be
written:

pipe val [ f1 .. fn ]
pipe val [ fn .. f1 ]
compose [ f1 .. fn ] val
compose [ fn .. f1 ] val

The third and fourth form mirror composition of functions, they would
be the same as e.g. (f1 << f2 << f3 .. << fn) val.
However, it is not clear which direction the list should have (as one
can see in the second form, which is the most absurd.

In order not to confuse users, we decide for the most “intuitive”
form, which mirrors the way unix pipes work (thus the name pipe).
The flow of data goes from left to right.

Co-Authored-By: Silvan Mosberger infinisil@icloud.com

Motivation for this change
  • tested using nix library tests

Copy link
Member

@cdepillabout cdepillabout left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM, although personally I'd like a compose = flip pipe function.

I can understand the argument that it is confusing which order the functions will be applied, but there are a few places in our code-base at work I would like to use the compose function in a point-free manner.

`pipe` is a useful operator for creating pipelines of functions.

It works around the usual problem of e.g. string operations becoming
deeply nested functions.

In principle, there are four different ways this function could be
written:

pipe val [ f1 .. fn ]
pipe val [ fn .. f1 ]
compose [ f1 .. fn ] val
compose [ fn .. f1 ] val

The third and fourth form mirror composition of functions, they would
be the same as e.g. `(f1 << f2 << f3 .. << fn) val`.
However, it is not clear which direction the list should have (as one
can see in the second form, which is the most absurd.

In order not to confuse users, we decide for the most “intuitive”
form, which mirrors the way unix pipes work (thus the name `pipe`).
The flow of data goes from left to right.

Co-Authored-By: Silvan Mosberger <infinisil@icloud.com>
@Profpatsch
Copy link
Member Author

I’m gonna keep this open till Sunday, to see if people have more feedback.

@Mic92
Copy link
Member

Mic92 commented Oct 19, 2019

Also see #38422 for previous discussion about having this function. cc @edolstra

@rycee
Copy link
Member

rycee commented Oct 20, 2019

I've never really felt much need for such a function. Regular function composition seems fine to me, especially if one forgoes the dogma of indenting after parens 😉

For example

pipe [ 3 4 ] [
  (map toString)
  (map (s: s + "\n"))
  concatStrings
]

vs.

concatStrings
(map (s: s + "\n")
(map toString
([ 3 4 ])))

or

concatStrings
(map (s: s + "\n")
(map toString [ 3 4 ]))

Where I concede that the ending run of parens is a bit of a nuisance.

An example from Home Manager: https://github.com/rycee/home-manager/blob/024d1aa227978fe2dae2fb3e56bab9a7237c2401/modules/programs/firefox.nix#L212-L216

@infinisil
Copy link
Member

Yeah I have to say, putting functions in lists which then get composed together somehow doesn't feel very intuitive. Composing functions manually much more so.

@Profpatsch
Copy link
Member Author

Profpatsch commented Oct 21, 2019

Where I concede that the ending run of parens is a bit of a nuisance.

Not just that, you cannot just reorder elements without re-shuffling the parens, or insert new ones without keeping track of the closing parens. Plus, as you say, that all will go away anyway once nix gains a good pretty-printer.

@Profpatsch
Copy link
Member Author

Since there’s been lots of positive feedback, let’s merge.

@Profpatsch Profpatsch merged commit 8252861 into NixOS:master Oct 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants