Another "pipeline" operator idea

# J?r?my Jud?aux (8 years ago)

I'd like to (re-)propose a "pipeline" operator. In fact, it has already been seen in some other places.

There are already some discussions and proposals:

This email is mostly to refresh the discussions on "pipeline" operators, I saw the two other proposals are still looking for Champions. There have been a lot of benefits already listed; chaining functions, not having to extend prototypes, reusability on data of different types, ... I have a personal use case about chain of Promises, which is not usable without a pipeline operator (no matter which one). Like promise %%% token.then(handler). And I suspect there are more useful ideas/libraries to be developed, just waiting for a(any) more advanced operator proposal.

For this "new proposal": Let's have a LeftExpression OPERATOR Thing ( OptionalArgumentList ) to be the equivalent of Thing ( LeftExpression, OptionalArgumentList). Where the ensemble Thing ( OptionalArgumentList ) is a valid expression, and Thing is not a call expression, or is a call expression in parentheses. I'm not sure how it translates into actual grammar.

So, in practice:

v OP f() is b(v) // like v |> f
v OP f(a) is f(v, a)
v OP f.call() is f.call(v) // like v::f()
v OP f.bind() is f.bind(v) // like v::f And more:
v OP f(a)(b) is f(v, a)(b)
v OP (f(a))(b) is (f(a))(v, b)
v OP (f())() is f()(v)
v OP (f()) is not valid
(v OP f)() is not valid
v OP o.f() is o.f(v)
v OP ((_) => f(_))() is ((_) => f(_))(v)
v OP (_ => f(a, _)) is (_ => f(a, _))(v) // improved with placeholder
v OP new F() is new F(v)
v OP await f() is await f(v)
v OP (await f)() is (await f)(v)
v OP _=>_() is (_=>_)(v) // not sure

And maybe that:

v OP yield f() is yield f(v)
v OP super() is super(v)

How it compares with a::b(): a bit more verbose, open more possibilities, doesn't solve the binding member access ::a.b. How it compares with a|>b: depends on situation. Doesn't require a temporary function, more verbose with inlined arrow functions, can be improved with placeholder, opens more possibilities (yield, maybe a bad thing).

About placeholders: placeholders can improve readability (v OP f(a) doesn't show that v will be the first argument, v OP f(#,a) does) and reduce the necessity for inlined arrow functions. But I don't think any pipeline operator should be delayed by that improvement.

It may not be wise to post "yet another operator proposal" when I'm waiting for an existing one to get advanced. Hopefully it will draw some attention back to the other proposals.

I'd like to (re-)propose a "pipeline" operator. In fact, it has already been seen in some other places.

There are already some discussions and proposals:

- https://github.com/mindeavor/es-pipeline-operator
- https://esdiscuss.org/topic/the-pipeline-operator-making-multiple-function-calls-look-great
- https://github.com/tc39/proposal-bind-operator

This email is mostly to refresh the discussions on "pipeline" operators, I saw the two other proposals are still looking for Champions.
There have been a lot of benefits already listed; chaining functions, not having to extend prototypes, reusability on data of different types, ...
I have a personal use case about chain of Promises, which is not usable without a pipeline operator (no matter which one). Like `promise %%% token.then(handler)`.
And I suspect there are more useful ideas/libraries to be developed, just waiting for a(any) more advanced operator proposal.

----
For this "new proposal":
Let's have a `LeftExpression OPERATOR Thing ( OptionalArgumentList )` to be the equivalent of `Thing ( LeftExpression, OptionalArgumentList)`.
Where the ensemble `Thing ( OptionalArgumentList )` is a valid expression, and `Thing` is not a call expression, or is a call expression in parentheses. I'm not sure how it translates into actual grammar.

So, in practice:
- `v OP f()` is `b(v)` // like `v |> f`
- `v OP f(a)` is `f(v, a)`
- `v OP f.call()` is `f.call(v)` // like `v::f()`
- `v OP f.bind()` is `f.bind(v)` // like `v::f`
And more:
- `v OP f(a)(b)` is `f(v, a)(b)`
- `v OP (f(a))(b)` is `(f(a))(v, b)`
- `v OP (f())()` is `f()(v)`
- `v OP (f())` is not valid
- `(v OP f)()` is not valid
- `v OP o.f()` is `o.f(v)`
- `v OP ((_) => f(_))()` is `((_) => f(_))(v)`
- `v OP (_ => f(a, _))` is `(_ => f(a, _))(v)` // improved with placeholder
- `v OP new F()` is `new F(v)`
- `v OP await f()` is `await f(v)`
- `v OP (await f)()` is `(await f)(v)`
- `v OP _=>_()` is `(_=>_)(v)` // not sure
And maybe that:
- `v OP yield f()` is `yield f(v)`
- `v OP super()` is `super(v)`

How it compares with `a::b()`: a bit more verbose, open more possibilities, doesn't solve the binding member access `::a.b`.
How it compares with `a|>b`: depends on situation. Doesn't require a temporary function, more verbose with inlined arrow functions, can be improved with placeholder, opens more possibilities (`yield`, maybe a bad thing).
About placeholders: placeholders can improve readability (`v OP f(a)` doesn't show that `v` will be the first argument, `v OP f(#,a)` does) and reduce the necessity for inlined arrow functions. But I don't think any pipeline operator should be delayed by that improvement.

----
It may not be wise to post "yet another operator proposal" when I'm waiting for an existing one to get advanced. Hopefully it will draw some attention back to the other proposals.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170313/c66943cb/attachment.html>