# Re: Re: Native Function Composition

12 messages
Open this post in threaded view
|

## Re: Re: Native Function Composition

 This is probably covered by the pipeline operator proposal: _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Re: Native Function Composition

 That's a syntax for calling functions, not creating a composed function for being called any time.Personally I don't find that proposal compelling because I don't think it saves much code vs current syntax - it only straightens the order and replaces () with using |>.However, if it were used for function composition instead, it could be more useful e.g.Current way:```const doubleThenSquareRoot = value=>squareRoot(double(value))```Pipe:```const doubleThenSquareRoot = double |> squareRoot```On Fri, 25 Aug 2017 at 00:36 dante federici <[hidden email]> wrote:This is probably covered by the pipeline operator proposal: _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Native Function Composition

 > Le 24 août 2017 à 23:13, Naveen Chawla <[hidden email]> a écrit : > > That's a syntax for calling functions, not creating a composed function for being called any time. > > Personally I don't find that proposal compelling because I don't think it saves much code vs current syntax - it only straightens the order and replaces () with using |>. Straightening the order is still a big deal in lengthy expressions. And imbalance of nesting parentheses is one of my main sources of syntax errors. —Claude _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Re: Native Function Composition

 In reply to this post by Dante Federici I have started to setup a proposal for this, contribution and changes are greatly welcomed. So far I have looked at 2 approaches, one more functional and the other is using infix operators.https://github.com/simonstaton/tc39-functional-composition-proposalI have included these points you have raised regarding the pipeline operator and looked at alternatives.At some point today I will include more details on this. Feel free to open PR's_______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Native Function Composition

 In reply to this post by Claude Pache On Fri, 25 Aug 2017 at 12:24 Claude Pache <[hidden email]> wrote: > Le 24 août 2017 à 23:13, Naveen Chawla <[hidden email]> a écrit : > > That's a syntax for calling functions, not creating a composed function for being called any time. > > Personally I don't find that proposal compelling because I don't think it saves much code vs current syntax - it only straightens the order and replaces () with using |>. Straightening the order is still a big deal in lengthy expressions. And imbalance of nesting parentheses is one of my main sources of syntax errors. Yes I think this applies in cases of function composition. My point was that it doesn't save much code, especially in comparison to allowing `|>` to be used directly as a function composition operator, which would give you the linearity you could want, as well as adding a whole dimension of expressive power to the language, instead of just allowing a re-ordered way of writing existing syntax.  —Claude _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Native Function Composition

 Aw, snap! I've written up a much shorter proposal myself. I do think composition should be in-order of call, i.e.```const composed = a |> b |> c  //c(b(a(f)))```Reads "do a `then` b `then` c"The advantage is that no-param calls can also be easily chained using the syntax:```const switchOnTheEngineThenDrive = switchOnTheEngine |> drive```I also don't think the reverse operator should be allowed. I think it compromises readability and could introduce confusion.I've written my shorter proposal here: https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-compositionOn Fri, 25 Aug 2017 at 16:56 Naveen Chawla <[hidden email]> wrote:On Fri, 25 Aug 2017 at 12:24 Claude Pache <[hidden email]> wrote: > Le 24 août 2017 à 23:13, Naveen Chawla <[hidden email]> a écrit : > > That's a syntax for calling functions, not creating a composed function for being called any time. > > Personally I don't find that proposal compelling because I don't think it saves much code vs current syntax - it only straightens the order and replaces () with using |>. Straightening the order is still a big deal in lengthy expressions. And imbalance of nesting parentheses is one of my main sources of syntax errors. Yes I think this applies in cases of function composition. My point was that it doesn't save much code, especially in comparison to allowing `|>` to be used directly as a function composition operator, which would give you the linearity you could want, as well as adding a whole dimension of expressive power to the language, instead of just allowing a re-ordered way of writing existing syntax.  —Claude _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Re: Native Function Composition

 In reply to this post by Dante Federici That link appears to be broken Naveen, If you are considering a similar approach let’s collaborate would be interested to get your outlook on this and we could probably expand on either of these _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Re: Native Function Composition

 -1 composition and pipeline-operators are both INCOMPATIBLE with javascript's async-programming style, and will likely result in tech-debt when used.  its fairly common for blocking-code to evolve into async-code as features are added, e.g. ```js result = arg |> operator1 |> operator2 |> operator3; // becomes spaghetti-code when operator2 evolves // to require async-merging with database-queries, file-reads, etc. ... operatorAsync2(arg |> operator1, function (error, data) {     if (error) {         ...         return     }     result = data |> operator3;     ... }); ``` On 8/25/17, Simon Staton <[hidden email]> wrote: > That link appears to be broken Naveen, If you are considering a similar > approach let’s collaborate would be interested to get your outlook on this > and we could probably expand on either of these > _______________________________________________ > es-discuss mailing list > [hidden email] > https://mail.mozilla.org/listinfo/es-discuss> _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Re: Native Function Composition

 "incompatible" is a very strong and likely incorrect claim. `(sync1 |> sync2 |> async1).then(x => x |> sync3 |> async2).then(x => async3)` could work just fine. On Fri, Aug 25, 2017 at 6:43 PM, kai zhu wrote:-1 composition and pipeline-operators are both INCOMPATIBLE with javascript's async-programming style, and will likely result in tech-debt when used.  its fairly common for blocking-code to evolve into async-code as features are added, e.g. ```js result = arg |> operator1 |> operator2 |> operator3; // becomes spaghetti-code when operator2 evolves // to require async-merging with database-queries, file-reads, etc. ... operatorAsync2(arg |> operator1, function (error, data) {     if (error) {         ...         return     }     result = data |> operator3;     ... }); ``` On 8/25/17, Simon Staton <[hidden email]> wrote: > That link appears to be broken Naveen, If you are considering a similar > approach let’s collaborate would be interested to get your outlook on this > and we could probably expand on either of these > _______________________________________________ > es-discuss mailing list > [hidden email] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss
Open this post in threaded view
|

## Re: Re: Native Function Composition

 On Sat, Aug 26, 2017 at 3:07 AM, Jordan Harband <[hidden email]> wrote:>> "incompatible" is a very strong and likely incorrect claim. `(sync1 |> sync2 |> async1).then(x => x |> sync3 |> async2).then(x => async3)` could work just fine.Or indeed, a robust proposal might allow for async functions in the pipeline (with some indication, so you can look at the code and reason about it; although `then` accepts non-thenable values and you can't tell by looking, so...). Conceptually:```jslet x = sync1 |> sync2 |*> async1 |> sync3 |*> async2 |*> async3;```-- T.J. Crowder _______________________________________________ es-discuss mailing list [hidden email] https://mail.mozilla.org/listinfo/es-discuss