Not really in favor of this. Expressions like builtins.foldl' (flip compose) id are likely to be very slow. Also, the use of such abstractions can make code less readable. For instance, if I see f (g x) I know what it does, but if I see compose f g I have to look up the definition of compose first.

I'm still super green to Nix, so apologies for any lack of knowledge when it comes to perf characteristics - is there a reason for that suggested slowness in the implementation of pipe? From what I can see in the docs / implementation foldl' should be strict on the operator so evaluation should be the same as if everything was inlined + the overhead of flipping.

As for readability, I prefer pointfree (which these enable). The lack of an infix (.) operator for the straight compose function isn't ideal, but consider the following:

pipe [ a b c d ]

vs

x: d (c (b (a x)))

It comes down to stylistic preferences. Happy to keep it in my personal libs if it doesn't mesh with the style used through the rest of the repo.

Entirely coincidentally I spent an hour or so yesterday looking for a compose function. I'm not sure I'd guess the definition of pipe correctly, but I'd have thought function composition is up there with map or fold/reduce in terms of widespread functional idiom

I have a definition of this too, with comment saying along the lines of "surely it exists already and but I'm blind so here we go"... Haha.

Are these named similarly elsewhere? Consistently? If so helps a bit with reading.
I mean pipe seems pretty clear :).

If perf is bad maybe it should just be a builtin! :P

compose should be fairly familiar for people from most language backgrounds.

pipe is also common terminology across F#, OCaml, Elixir, Elm, Julia, Hack, LiveScript, the tc39 proposal and quite a few libraries for various languages, as well as UNIX pipes, although in most of these it's represented as the |> operator.

Happy to split these out if they're easier to consider in isolation.

Definitely agree that builtins would be optimal. If going that route, extending to . and |> operators would be beautiful, but I'm lazy and implementation here was trivial :)

What is the status of this pull request?

@edolstra expressed some valid performance concerns with pipe, which are likely reason enough to drop that from inclusion in this PR.

I've just had a grep through the current repo state and could find another implementation of compose introduced here. Unfortunately github code search is a little rudimentary, but from a brief look across other nix projects the occasional implementation pops up elsewhere too. With this I'd still argue that there could be some value in just having it as part of base lib.

Let me know which way you'd like to go and I can either drop this down to just compose, or close this off without the merge.

In my opinion neither of this is useful unless it's defined as a infix or used in laguage where it's possible to write binary functions as infix (like haskells ``` syntax).

Let's close this for now.