The `|>` operator would be great for function composition instead. Explanation...

[TheNavigateur]

The existing code

const doubleThenSquare = value=>square(double(value))

would be rewritable as:

const doubleThenSquare = double |> square

Reasons to prefer this instead of |> being a function call operator:

1. Genuinely saves code
2. The tersely composed functions can be called any time and be tersely used to compose other functions
3. Has logical consistency (FunctionExpression |> FunctionExpression instead of InputExpression |> FunctionExpression |> FunctionExpression)

Fuller explanation here:

https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
https://esdiscuss.org/topic/native-function-composition

[Volune]

With the current proposition, you can write

const doubleThenSquare = value=>value |> double |> square;

You can also write

const result = 42 |> double |> square;

With your change, this second example would become:

const result = (double |> square)(42);

In my opinion, the extra parenthesis are an issue. It's easier to compose functions, but chaining calls would be less maintainable.

const map = f => function*(iterable) { for(const v of iterable) yield f(v); };
const tap = f => function*(iterable) { for(const v of iterable) {f(v); yield v;} };
const toArray = () => iterable => [...iterable];
const filter = f => function*(iterable) { for(const v of iterable) if(f(v)) yield v; };

const result = (
    filter(x => (x % 2 == 0))
    |> map(x => x * 2)
    |> tap(x => {
       console.log(x);
    })
    |> toArray()
)([1,2,3,4,5]);

[TheNavigateur]

Not sure I agree that chaining calls would be less maintainable: Current proposal provides an "alternative syntax for chaining calls", which can lead to inconsistent code where some people choose x(y(v)) and others choose v|>y|>x or a combination thereof. Using |> for function composition on the other hand provides a clear separation of meaning, which I think could be better for readability, which I think could feed right into maintainability.

Also it is worth considering the use cases for such constructs. Is it more useful to create reusable composed functions or execute the composition in place? I would argue that having the terse syntax for reusable function composition adds a whole new dimension of expressive power to the language, whereas the proposal doesn't save any coding complexity as such over x(y(v)), just linearises it.

[mAAdhaTTah]

FWIW, this example:

const result = (double |> square)(42);

isn't that different from how you have to do it now using a pipe implementation:

const result = pipe(double, square)(42);

so there are some parallels to current practice with @TheNavigateur's suggestion.

In my experience, a function composition is rarely called where it's defined; that suggests the syntax that favors composition over evaluation might be better for the language.

[littledan]

I am not sure how the semantics for this should work. Do you want |> to do a different thing depending on whether the left hand side argument is a function or not?

[TheNavigateur]

No, always function composition

[littledan]

If it's always function composition, that would make the normal use case of x |> f |> g ==> g(f(x)) not work. Is this what you would intend?

[mAAdhaTTah]

I believe that's the intention. I would argue the use case of calling inline is less common than defining and executing functions separately.

[TheNavigateur]

Yes. (f |> g)(x) for immediate calling, f |> g for creating a reusable composed function.

[dallonf]

I'm not an expert on language design, but if I may weigh in...

Both directions of the proposal do things that can already be done in the language...

// Equivalent in proposal as written
const value = x |> a |> b |> c;
const value = compose(a, b, c)(x); //assuming a third-party `compose` function, provided in many libraries
const value = pipeline(x, a, b, c); //assuming a third-party `pipeline` function, which I've never seen before in a library and in fact wound up writing one myself*
const value = c(b(a(x)));

// Equivalent in proposal according to this issue
const fn = x => c(b(a(x)));
const fn = compose(a, b, c); //assuming a third-party `compose` function, provided in many libraries
const fn => a |> b |> c;

The prior art cited in the proposal README suggests that several existing functional languages use the |> symbol for immediate execution (and some others use a different symbol but have the same feature); I don't believe any existing languages use this symbol for function composition. (do correct me if I'm wrong)

In my opinion, the proposal as written benefits everyone - functional and imperative styles alike - in fact, it can help imperative style developers begin to adopt a functional style; imagine if jQuery were written with this syntax instead of creating custom objects to allow chaining. Changing it to a function composition operator only benefits functional-centric developers.

To that point, I strongly disagree with @mAAdhaTTah's suggestion that "the use case of calling inline is less common than defining and executing functions separately"; this has not been my experience with JavaScript at all.

I think function composition is great, but please don't hijack a good proposal like this! How about a separate operator? Or even just including a native compose function in the spec?

*shameless plug: https://github.com/phunware/pipeline

[TheNavigateur]

I disagree that changing it to a function composition operator only benefits functional-centric developers.

Consider the following use case for declaring no-param, no-result functions to be executed in order:

Composition operator:

const switchOnEngineThenDrive = switchOnEngine |> drive

This is beautiful chaining of imperatively ordered functions in a short syntax.

Consider the equivalent for the immediate execution operator:

const switchOnEngineThenDrive = ()=>(undefined |> switchOnEngine |> drive)

(This already highlights the logical inconsistency in having InputExpression |> FunctionExpression |> FunctionExpression as opposed to just FunctionExpression |> FunctionExpression. There is a readability predictably about always having only a FunctionExpression before a |>.)

Now let's look at immediate execution for the same:

Composition operator:

(switchOnEngine |> drive)()

Immediate execution operator:

undefined |> switchOnEngine |> drive

I would argue that the composition operator approach is preferable for imperative style development too. Reusability, readability, intuitiveness

[mAAdhaTTah]

To that point, I strongly disagree with @mAAdhaTTah's suggestion that "the use case of calling inline is less common than defining and executing functions separately"; this has not been my experience with JavaScript at all.

Fair; that's likely specific to functional programming, which is what I expect the proposal is likely to be most popular/useful to.

[jasmith79]

@dallonf "never seen and ended up writing myself"?

http://ramdajs.com/docs/#pipe
https://lodash.com/docs/4.17.4#flow
https://vanslaars.io/post/create-pipe-function/

I'm too lazy to search for more. Or did I misunderstand what you were driving at?

[littledan]

There's clearly a use case for both of these, and you can definitely use one to get the other, at the cost of a little bit more syntax. The question is more like, which one is more common and intuitive.

[dallonf]

@jasmith79 All three of the examples you gave are for function composition, ex. pipe(a, b, c) is equivalent to x => c(b(a(x))). I called this compose in my examples and, as I mentioned, it is quite common in third-party libraries. Less common is a function that replicates the functionality of this proposal, ex. pipeline(x, a, b, c) is equivalent to c(b(a(x))).

To other responses... to be clear, I see the value in function composition. But I see it as a tool to solve a different problem than the pipeline operator is intended to solve, so I believe deserves its own proposal. (I would be strongly in favor of making that compose function which is so common in third-party libraries part of the core language, for example).

However, this discussion is not a matter of proving that function composition is useful, or even that it is more useful; in order to turn the immediate execution pipeline operator proposal into a function composition proposal, you would have to determine that immediate execution has no value at all and has no place in the language, which I do strongly disagree with and I believe I am backed up by the fact that immediate execution pipeline operators can be found in F#, OCaml, Elixir, Elm, Julia, Hack, and LiveScript (I copied that list from the README - but I'll also add Clojure's equivalent).

In conclusion...

[TheNavigateur]

I don't think it's a question of whether immediate execution has "no value at all". The composition operator version achieves immediate execution with mere parentheses:

(switchOnEngine |> drive)(100)

The converse is not true: doing composition with the immediate execution operator requires value=> and value |> in each case, at the least. Therefore I would suggest that the composition operator would more effectively take care of a wider range of use cases already. I would even argue it handles immediate execution more readably and intuitively. (And for immediate execution with no args, do you really prefer undefined |> switchOnEngine |> drive more than (switchOnEngine |> drive)()?)

The other issue, which maybe you can address, is the unintuitiveness of expression arguments InputExpression |> FunctionExpression |> FunctionExpression |> ... and so on. Logically you would normally want expressions surrounding an operator to be treated the same regardless of which part of the code you are looking at (e.g. + - / * % || >> && etc.). However, this treats the first argument differently than the 2nd argument onwards, even though it's the same operator. Does this not bother you at all?