Pipeline function?

[samfrances]

I was thinking of contributing a pipeline function, which is the same as compose but reversing the arguments.

compose(f, g, h)(x, y) is the same as f(g(h(x, y))), which is the same as pipeline(h, g, f)(x, y).

Personally, I find this ordering easier to read and reason about.

However, the contributions section of the README suggests that it might be best to check issues for contribution ideas, so I thought I would canvas for opinions before contributing.

[eriknw]

I agree that it's more natural. Thanks for the suggestion. This has been asked for before, so I think we should try to find the best way to spell this so we can add it.

See #213 for previous discussion.

I think pipeline is too similar to pipe. Any other ideas for a name?

[samfrances]

Well, a logical but unlovely option would be composeLeft. Otherwise, there are some precedents for flow (e.g. lodash uses this name: https://lodash.com/docs/4.17.4#flow)

Looking at #213, it looks like this was already perfectly well implemented in that pull request, in terms of the code itself. Am I right in understanding that choosing an appropriate name was the main obstacle to adoption?

[cgarciae]

@samfrances I implemented this library with has excellent support for pipeline-style functions: https://github.com/cgarciae/phi

However, you can't have better support for that than using coconut: http://coconut-lang.org/

[samfrances]

Hi @cgarciae . Do the << and >> operators work on simple functions, or just on P expressions?

[cgarciae]

@samfrances All the operator work with simple function and values, however, at least one of the objects involved has to be an phi object. If you have the functions f and g , you can compose them like this

P >> f >> g

or like this using the F function which coverts into phi objects

F(f) >> g

In coconut you get the previous at a language level via the .. operator:

g .. f

Or using pipes with a value

x |> f |> g

[chuckwondo]

It's a shame that #213 was closed, but I'm glad to see this one still open.

I feel that it is a bit unfortunate that pipe is not symmetrical with compose in that pipe should produce a new function, as compose does. The implementation of pipe also seems to be counter to this sentence in the Composability section of the docs:

"Each toolz function consumes just iterables, dictionaries, and functions and each toolz function produces just iterables, dictionaries, and functions."

I find pipe as currently implemented to be of limited use because I want it to return a new function, not a value, so that I can compose it in various ways. By extension, the same can be said for thread_first and thread_last, but I'll ignore them for now since this issue is about pipe.

However, I do see why pipe (as well as thread_first and thread_last) may have been implemented such that the first argument is the value to be piped (or threaded). If a pipe (or thread) operator were built into the language, then the syntax would start with the value to be piped through a series of functions, so by having the pipe function take the value as the first argument, it looks visually similar to a syntax that would use a pipe operator.

That is, if Python included |> as a pipe operator, then you might be able to write something like value |> f |> g |> h. Therefore, the pipe function mimics that syntax by supporting pipe(val, f, g, h). Unfortunately, that's not conducive to composability.

Can we please find a mutually agreeable name for a "pipe" function that does not take a value as the first argument, but rather simply produces a new function? Perhaps we can name it flow, as suggested earlier in this issue? I would be agreeable to composeLeft simply for symmetry with compose, but I prefer the shorter name. I also like the name pipeline and think that its similarity to pipe is actually a good thing, as it is indeed similar. Yet another possible name is into (which I garnered from a Coconut example of one of its compose operators ..>, which does the same thing as we're discussing in this issue).

[fionafibration]

I second the idea of composeLeft, it's very natural-sounding, and if you know what compose does, it's immediately apparent what composeLeft does

[chuckwondo]

@mrocklin Any thoughts here, given that you closed #213?

[eriknw]

Thanks for the discussion. I support adding pipeline. I'm happy with the functionality and the name.

[samfrances]

Fantastic! I have created a PR for this: #451

[stereobutter]

+1 for compose_left (or any other spelling) since pipeline vs pipe is very confusing and compose_left is self-explanatory for everyone who knows what compose does

[eriknw]

Aha! How about compose_pipe?

[samfrances]

I'm happy to update the PR to support whatever naming, once the question is settled. However, I think compose_pipe is actually quite confusing. Obv, pipeline is my preference, as I suggested it (actually, I would prefer pipe, but its already taken), but I would be happy with compose_left.

I'm not sure what the feeling is about aliasing - i.e. it could have more than one name.

[chuckwondo]

I agree that compose_pipe is confusing. I would be happy with compose_left, if others find pipeline potentially confusing as well. Although compose_left is a longer name, it is arguably much more clear as to its functionality, and also mirrors other function names/pairings that have a "left" or a "right" orientation.