Re: Re: Native Function Composition

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

Dante Federici
This is probably covered by the pipeline operator proposal:


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

Naveen Chawla
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
Reply | Threaded
Open this post in threaded view
|

Re: Native Function Composition

Claude Pache

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

Simon Staton
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.


I 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
Reply | Threaded
Open this post in threaded view
|

Re: Native Function Composition

Naveen Chawla
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
Reply | Threaded
Open this post in threaded view
|

Re: Native Function Composition

Naveen Chawla
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.



On 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

Simon Staton
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

kai zhu
-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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

Jordan Harband
"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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

T.J. Crowder-2
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:

```js
let x = sync1 |> sync2 |*> async1 |> sync3 |*> async2 |*> async3;
```

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

Naveen Chawla

On Sat, 26 Aug 2017 at 13:17 T.J. Crowder <[hidden email]> wrote:
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:

```js
let x = sync1 |> sync2 |*> async1 |> sync3 |*> async2 |*> async3;
```

-- T.J. Crowder
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Native Function Composition

Isiah Meadows-2
Just thought I'd throw this out there: I've been off-and-on working on
my own function composition strawman [1] for about a year now [2]. I
decided just now to make some edits to clean up the proposal and
address some other ideas that have come up since (e.g. async
composition).

[1]: https://github.com/isiahmeadows/function-composition-proposal
[2]: https://esdiscuss.org/topic/function-composition-syntax
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Aug 30, 2017 at 4:48 AM, Naveen Chawla <[hidden email]> wrote:

> I've updated my proposal to use `+>` instead of `|>`, based on this
> discussion:
>
> https://github.com/tc39/proposal-pipeline-operator/issues/50
>
> https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
>
> On Sat, 26 Aug 2017 at 13:17 T.J. Crowder <[hidden email]>
> wrote:
>>
>> 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:
>>
>> ```js
>> let x = sync1 |> sync2 |*> async1 |> sync3 |*> async2 |*> async3;
>> ```
>>
>> -- T.J. Crowder
>> _______________________________________________
>> 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