Function composition vs pipeline

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

Function composition vs pipeline

Naveen Chawla
I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features:

e.g.

They can of course co-exist, but there is overlap only in the respect that both allow function pipelines to be called from left to right (except the input parameter in the case of the composition feature, which requires existing bracket syntax to be used to call it). If one were to be chosen, would say that a function composition operator adds a whole new dimension of expressive power to the language, whereas a pipeline operator only offers a different way of calling functions.

I was wondering about all of your thoughts about whether you'd prefer only the pipeline operator, only the composition operator, or both, or neither to be added to the language (these are pretty much all the possibilities), and why.

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

Re: Function composition vs pipeline

Jordan Harband
How is either operator not "a different way of calling functions"?

On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]> wrote:
I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features:

e.g.

They can of course co-exist, but there is overlap only in the respect that both allow function pipelines to be called from left to right (except the input parameter in the case of the composition feature, which requires existing bracket syntax to be used to call it). If one were to be chosen, would say that a function composition operator adds a whole new dimension of expressive power to the language, whereas a pipeline operator only offers a different way of calling functions.

I was wondering about all of your thoughts about whether you'd prefer only the pipeline operator, only the composition operator, or both, or neither to be added to the language (these are pretty much all the possibilities), and why.

_______________________________________________
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: Function composition vs pipeline

=?utf-8?Q? J.=C2=A0S._Choi ?=
In reply to this post by Naveen Chawla
See also recent discussions in these GitHub issues that touch on composition: https://github.com/tc39/proposal-pipeline-operator/issues?q=composition+sort%3Aupdated-desc.

Look particularly at the issues that were created after 2018-01-31 – when Gilbert/Mindeavor split the proposal into four competing proposals – since those issues reflect the current state of the art. To see those four competing proposals, look at the pipeline operator’s wiki, which has a list of the four proposals (https://github.com/tc39/proposal-pipeline-operator/wiki).

In particular, Naveem, you may be interested in https://github.com/tc39/proposal-pipeline-operator/issues/93, which discusses the intersection of terse function application and terse function composition.

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

Re: Function composition vs pipeline

Naveen Chawla
In reply to this post by Jordan Harband
The function composition operator composes function pipelines into functions for later use and/or further composition. Those functions still need to be called via the existing `()` syntax, so it doesn't offer a different way of calling functions as such.

The function pipeline operator calls the function pipeline immediately, so it is really only a different way of calling functions.

On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
How is either operator not "a different way of calling functions"?

On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]> wrote:
I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features:

e.g.

They can of course co-exist, but there is overlap only in the respect that both allow function pipelines to be called from left to right (except the input parameter in the case of the composition feature, which requires existing bracket syntax to be used to call it). If one were to be chosen, would say that a function composition operator adds a whole new dimension of expressive power to the language, whereas a pipeline operator only offers a different way of calling functions.

I was wondering about all of your thoughts about whether you'd prefer only the pipeline operator, only the composition operator, or both, or neither to be added to the language (these are pretty much all the possibilities), and why.

_______________________________________________
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: Function composition vs pipeline

Viktor Kronvall
I don’t know the implications but I could easily imagine the pipeline proposal being extended to not taking any input on the left hand side and effectively represent composition in the opposite direction.

For example:
```
let h = |> f |> g
h(2) //g(f(2))
```

That said, the point holds for the proposal in its current state. Being able to compose functions
leads to much more expressivity than if you have
to call the pipeline (and collapse) where it is defined.
2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
The function composition operator composes function pipelines into functions for later use and/or further composition. Those functions still need to be called via the existing `()` syntax, so it doesn't offer a different way of calling functions as such.

The function pipeline operator calls the function pipeline immediately, so it is really only a different way of calling functions.

On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
How is either operator not "a different way of calling functions"?

On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]> wrote:
I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features:

e.g.

They can of course co-exist, but there is overlap only in the respect that both allow function pipelines to be called from left to right (except the input parameter in the case of the composition feature, which requires existing bracket syntax to be used to call it). If one were to be chosen, would say that a function composition operator adds a whole new dimension of expressive power to the language, whereas a pipeline operator only offers a different way of calling functions.

I was wondering about all of your thoughts about whether you'd prefer only the pipeline operator, only the composition operator, or both, or neither to be added to the language (these are pretty much all the possibilities), and why.

_______________________________________________
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: Function composition vs pipeline

Naveen Chawla
That could be a problem for readability.
I agree with the rest of what you said.

On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <[hidden email]> wrote:
I don’t know the implications but I could easily imagine the pipeline proposal being extended to not taking any input on the left hand side and effectively represent composition in the opposite direction.

For example:
```
let h = |> f |> g
h(2) //g(f(2))
```

That said, the point holds for the proposal in its current state. Being able to compose functions
leads to much more expressivity than if you have
to call the pipeline (and collapse) where it is defined.
2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
The function composition operator composes function pipelines into functions for later use and/or further composition. Those functions still need to be called via the existing `()` syntax, so it doesn't offer a different way of calling functions as such.

The function pipeline operator calls the function pipeline immediately, so it is really only a different way of calling functions.

On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
How is either operator not "a different way of calling functions"?

On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]> wrote:
I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features:

e.g.

They can of course co-exist, but there is overlap only in the respect that both allow function pipelines to be called from left to right (except the input parameter in the case of the composition feature, which requires existing bracket syntax to be used to call it). If one were to be chosen, would say that a function composition operator adds a whole new dimension of expressive power to the language, whereas a pipeline operator only offers a different way of calling functions.

I was wondering about all of your thoughts about whether you'd prefer only the pipeline operator, only the composition operator, or both, or neither to be added to the language (these are pretty much all the possibilities), and why.

_______________________________________________
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: Function composition vs pipeline

Peter Jaszkowiak
I'd like to point out the partial application operator: https://github.com/tc39/proposal-partial-application

Sounds like the combination of pipeline + partial application would result in what is essentially the same as function composition operator:

```
const h = ? |> f |> g;
```

Which results in `h` being the composition `g • f`.


On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
That could be a problem for readability.
I agree with the rest of what you said.


On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <[hidden email]> wrote:
I don’t know the implications but I could easily imagine the pipeline proposal being extended to not taking any input on the left hand side and effectively represent composition in the opposite direction.

For example:
```
let h = |> f |> g
h(2) //g(f(2))
```

That said, the point holds for the proposal in its current state. Being able to compose functions
leads to much more expressivity than if you have
to call the pipeline (and collapse) where it is defined.
2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
The function composition operator composes function pipelines into functions for later use and/or further composition. Those functions still need to be called via the existing `()` syntax, so it doesn't offer a different way of calling functions as such.

The function pipeline operator calls the function pipeline immediately, so it is really only a different way of calling functions.

On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
How is either operator not "a different way of calling functions"?

On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]> wrote:
I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features:

e.g.

They can of course co-exist, but there is overlap only in the respect that both allow function pipelines to be called from left to right (except the input parameter in the case of the composition feature, which requires existing bracket syntax to be used to call it). If one were to be chosen, would say that a function composition operator adds a whole new dimension of expressive power to the language, whereas a pipeline operator only offers a different way of calling functions.

I was wondering about all of your thoughts about whether you'd prefer only the pipeline operator, only the composition operator, or both, or neither to be added to the language (these are pretty much all the possibilities), and why.

_______________________________________________
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



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

Re: Function composition vs pipeline

Naveen Chawla
Although it doesn't allow composition with generator functions like the composition proposal does, otherwise it's a pretty good solution.

My only concern with pipeline is that since it offers a different way of calling functions than the `()` syntax, it can lead to mixed and hence slightly more confusing code when both `()` and `|>` are used. For example multi arg and no-arg functions would still use `()`, and single arg functions may or may not use `|>` depending on whether or not they may prospectively use a pipeline. The composition operator doesn't supersede the `()` syntax in any context, and so it could be argued it would lead to more consistent, more readable code.

On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]> wrote:
I'd like to point out the partial application operator: https://github.com/tc39/proposal-partial-application

Sounds like the combination of pipeline + partial application would result in what is essentially the same as function composition operator:

```
const h = ? |> f |> g;
```

Which results in `h` being the composition `g • f`.


On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
That could be a problem for readability.
I agree with the rest of what you said.


On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <[hidden email]> wrote:
I don’t know the implications but I could easily imagine the pipeline proposal being extended to not taking any input on the left hand side and effectively represent composition in the opposite direction.

For example:
```
let h = |> f |> g
h(2) //g(f(2))
```

That said, the point holds for the proposal in its current state. Being able to compose functions
leads to much more expressivity than if you have
to call the pipeline (and collapse) where it is defined.
2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
The function composition operator composes function pipelines into functions for later use and/or further composition. Those functions still need to be called via the existing `()` syntax, so it doesn't offer a different way of calling functions as such.

The function pipeline operator calls the function pipeline immediately, so it is really only a different way of calling functions.

On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
How is either operator not "a different way of calling functions"?

On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]> wrote:
I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features:

e.g.

They can of course co-exist, but there is overlap only in the respect that both allow function pipelines to be called from left to right (except the input parameter in the case of the composition feature, which requires existing bracket syntax to be used to call it). If one were to be chosen, would say that a function composition operator adds a whole new dimension of expressive power to the language, whereas a pipeline operator only offers a different way of calling functions.

I was wondering about all of your thoughts about whether you'd prefer only the pipeline operator, only the composition operator, or both, or neither to be added to the language (these are pretty much all the possibilities), and why.

_______________________________________________
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


_______________________________________________
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: Function composition vs pipeline

Isiah Meadows-2
Just thought I'd point out that the proposal itself entertains the
possibility of a corresponding composition proposal [1]. Also, in my
proposal, one of my "potential expansions" [2] would open a generic
door for "lifting" over a type, addressing the concern of
extensibility. (It's not ideal, and I just filed an issue in my repo
for that, but that's orthogonal.)

[1]: https://github.com/tc39/proposal-pipeline-operator#related-proposals
[2]: https://github.com/isiahmeadows/function-composition-proposal#possible-expansions

-----

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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]> wrote:

> Although it doesn't allow composition with generator functions like the
> composition proposal does, otherwise it's a pretty good solution.
>
> My only concern with pipeline is that since it offers a different way of
> calling functions than the `()` syntax, it can lead to mixed and hence
> slightly more confusing code when both `()` and `|>` are used. For example
> multi arg and no-arg functions would still use `()`, and single arg
> functions may or may not use `|>` depending on whether or not they may
> prospectively use a pipeline. The composition operator doesn't supersede the
> `()` syntax in any context, and so it could be argued it would lead to more
> consistent, more readable code.
>
> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]> wrote:
>>
>> I'd like to point out the partial application operator:
>> https://github.com/tc39/proposal-partial-application
>>
>> Sounds like the combination of pipeline + partial application would result
>> in what is essentially the same as function composition operator:
>>
>> ```
>> const h = ? |> f |> g;
>> ```
>>
>> Which results in `h` being the composition `g • f`.
>>
>>
>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>>
>> That could be a problem for readability.
>> I agree with the rest of what you said.
>>
>>
>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <[hidden email]>
>> wrote:
>>>
>>> I don’t know the implications but I could easily imagine the pipeline
>>> proposal being extended to not taking any input on the left hand side and
>>> effectively represent composition in the opposite direction.
>>>
>>> For example:
>>> ```
>>> let h = |> f |> g
>>> h(2) //g(f(2))
>>> ```
>>>
>>> That said, the point holds for the proposal in its current state. Being
>>> able to compose functions
>>> leads to much more expressivity than if you have
>>> to call the pipeline (and collapse) where it is defined.
>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>>>>
>>>> The function composition operator composes function pipelines into
>>>> functions for later use and/or further composition. Those functions still
>>>> need to be called via the existing `()` syntax, so it doesn't offer a
>>>> different way of calling functions as such.
>>>>
>>>> The function pipeline operator calls the function pipeline immediately,
>>>> so it is really only a different way of calling functions.
>>>>
>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
>>>>>
>>>>> How is either operator not "a different way of calling functions"?
>>>>>
>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> I was just thinking about the relative merits and coexistence (or not)
>>>>>> of function composition operator and function pipeline operator features:
>>>>>>
>>>>>> e.g.
>>>>>>
>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
>>>>>> https://github.com/tc39/proposal-pipeline-operator
>>>>>>
>>>>>> They can of course co-exist, but there is overlap only in the respect
>>>>>> that both allow function pipelines to be called from left to right (except
>>>>>> the input parameter in the case of the composition feature, which requires
>>>>>> existing bracket syntax to be used to call it). If one were to be chosen,
>>>>>> would say that a function composition operator adds a whole new dimension of
>>>>>> expressive power to the language, whereas a pipeline operator only offers a
>>>>>> different way of calling functions.
>>>>>>
>>>>>> I was wondering about all of your thoughts about whether you'd prefer
>>>>>> only the pipeline operator, only the composition operator, or both, or
>>>>>> neither to be added to the language (these are pretty much all the
>>>>>> possibilities), and why.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>
>>
>> _______________________________________________
>> 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: Function composition vs pipeline

kai zhu
my vote is for neither.  exactly what industry painpoint or
problem-space do either of these proposals solve?

rather, they compound an existing industry painpoint; where
ocd-programmers have problems in deciding-and-choosing which es6
style/design-pattern to employ and stick with before coding even
begins. many of us wish there were less choices, like python (and a
more assertive tc39 that makes clear certain proposals are
productivity-negative and not open for debate) so we could get on with
the actual coding-part.

from a senior-engineer / technical-manager perspective, it also
doesn't help in managing an entire web-project; comprised of dozens of
sub-components that you didn't all write yourself; and having to
context-switch for each sub-component's quirky es6/es7/es8/es9
style-guide/design-pattern.

On 3/4/18, Isiah Meadows <[hidden email]> wrote:

> Just thought I'd point out that the proposal itself entertains the
> possibility of a corresponding composition proposal [1]. Also, in my
> proposal, one of my "potential expansions" [2] would open a generic
> door for "lifting" over a type, addressing the concern of
> extensibility. (It's not ideal, and I just filed an issue in my repo
> for that, but that's orthogonal.)
>
> [1]: https://github.com/tc39/proposal-pipeline-operator#related-proposals
> [2]:
> https://github.com/isiahmeadows/function-composition-proposal#possible-expansions
>
> -----
>
> 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
> wrote:
>> Although it doesn't allow composition with generator functions like the
>> composition proposal does, otherwise it's a pretty good solution.
>>
>> My only concern with pipeline is that since it offers a different way of
>> calling functions than the `()` syntax, it can lead to mixed and hence
>> slightly more confusing code when both `()` and `|>` are used. For example
>> multi arg and no-arg functions would still use `()`, and single arg
>> functions may or may not use `|>` depending on whether or not they may
>> prospectively use a pipeline. The composition operator doesn't supersede
>> the
>> `()` syntax in any context, and so it could be argued it would lead to
>> more
>> consistent, more readable code.
>>
>> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]> wrote:
>>>
>>> I'd like to point out the partial application operator:
>>> https://github.com/tc39/proposal-partial-application
>>>
>>> Sounds like the combination of pipeline + partial application would
>>> result
>>> in what is essentially the same as function composition operator:
>>>
>>> ```
>>> const h = ? |> f |> g;
>>> ```
>>>
>>> Which results in `h` being the composition `g • f`.
>>>
>>>
>>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>>>
>>> That could be a problem for readability.
>>> I agree with the rest of what you said.
>>>
>>>
>>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <[hidden email]>
>>> wrote:
>>>>
>>>> I don’t know the implications but I could easily imagine the pipeline
>>>> proposal being extended to not taking any input on the left hand side
>>>> and
>>>> effectively represent composition in the opposite direction.
>>>>
>>>> For example:
>>>> ```
>>>> let h = |> f |> g
>>>> h(2) //g(f(2))
>>>> ```
>>>>
>>>> That said, the point holds for the proposal in its current state. Being
>>>> able to compose functions
>>>> leads to much more expressivity than if you have
>>>> to call the pipeline (and collapse) where it is defined.
>>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>>>>>
>>>>> The function composition operator composes function pipelines into
>>>>> functions for later use and/or further composition. Those functions
>>>>> still
>>>>> need to be called via the existing `()` syntax, so it doesn't offer a
>>>>> different way of calling functions as such.
>>>>>
>>>>> The function pipeline operator calls the function pipeline immediately,
>>>>> so it is really only a different way of calling functions.
>>>>>
>>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
>>>>>>
>>>>>> How is either operator not "a different way of calling functions"?
>>>>>>
>>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> I was just thinking about the relative merits and coexistence (or
>>>>>>> not)
>>>>>>> of function composition operator and function pipeline operator
>>>>>>> features:
>>>>>>>
>>>>>>> e.g.
>>>>>>>
>>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
>>>>>>> https://github.com/tc39/proposal-pipeline-operator
>>>>>>>
>>>>>>> They can of course co-exist, but there is overlap only in the respect
>>>>>>> that both allow function pipelines to be called from left to right
>>>>>>> (except
>>>>>>> the input parameter in the case of the composition feature, which
>>>>>>> requires
>>>>>>> existing bracket syntax to be used to call it). If one were to be
>>>>>>> chosen,
>>>>>>> would say that a function composition operator adds a whole new
>>>>>>> dimension of
>>>>>>> expressive power to the language, whereas a pipeline operator only
>>>>>>> offers a
>>>>>>> different way of calling functions.
>>>>>>>
>>>>>>> I was wondering about all of your thoughts about whether you'd prefer
>>>>>>> only the pipeline operator, only the composition operator, or both,
>>>>>>> or
>>>>>>> neither to be added to the language (these are pretty much all the
>>>>>>> possibilities), and why.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function composition vs pipeline

Peter Jaszkowiak
Oh please,

This is an alternative syntax that's very useful for many people. If you want too simplify syntax yourself you can use a linter to disable alternatives.

On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
my vote is for neither.  exactly what industry painpoint or
problem-space do either of these proposals solve?

rather, they compound an existing industry painpoint; where
ocd-programmers have problems in deciding-and-choosing which es6
style/design-pattern to employ and stick with before coding even
begins. many of us wish there were less choices, like python (and a
more assertive tc39 that makes clear certain proposals are
productivity-negative and not open for debate) so we could get on with
the actual coding-part.

from a senior-engineer / technical-manager perspective, it also
doesn't help in managing an entire web-project; comprised of dozens of
sub-components that you didn't all write yourself; and having to
context-switch for each sub-component's quirky es6/es7/es8/es9
style-guide/design-pattern.

On 3/4/18, Isiah Meadows <[hidden email]> wrote:
> Just thought I'd point out that the proposal itself entertains the
> possibility of a corresponding composition proposal [1]. Also, in my
> proposal, one of my "potential expansions" [2] would open a generic
> door for "lifting" over a type, addressing the concern of
> extensibility. (It's not ideal, and I just filed an issue in my repo
> for that, but that's orthogonal.)
>
> [1]: https://github.com/tc39/proposal-pipeline-operator#related-proposals
> [2]:
> https://github.com/isiahmeadows/function-composition-proposal#possible-expansions
>
> -----
>
> 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
> wrote:
>> Although it doesn't allow composition with generator functions like the
>> composition proposal does, otherwise it's a pretty good solution.
>>
>> My only concern with pipeline is that since it offers a different way of
>> calling functions than the `()` syntax, it can lead to mixed and hence
>> slightly more confusing code when both `()` and `|>` are used. For example
>> multi arg and no-arg functions would still use `()`, and single arg
>> functions may or may not use `|>` depending on whether or not they may
>> prospectively use a pipeline. The composition operator doesn't supersede
>> the
>> `()` syntax in any context, and so it could be argued it would lead to
>> more
>> consistent, more readable code.
>>
>> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]> wrote:
>>>
>>> I'd like to point out the partial application operator:
>>> https://github.com/tc39/proposal-partial-application
>>>
>>> Sounds like the combination of pipeline + partial application would
>>> result
>>> in what is essentially the same as function composition operator:
>>>
>>> ```
>>> const h = ? |> f |> g;
>>> ```
>>>
>>> Which results in `h` being the composition `g • f`.
>>>
>>>
>>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>>>
>>> That could be a problem for readability.
>>> I agree with the rest of what you said.
>>>
>>>
>>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <[hidden email]>
>>> wrote:
>>>>
>>>> I don’t know the implications but I could easily imagine the pipeline
>>>> proposal being extended to not taking any input on the left hand side
>>>> and
>>>> effectively represent composition in the opposite direction.
>>>>
>>>> For example:
>>>> ```
>>>> let h = |> f |> g
>>>> h(2) //g(f(2))
>>>> ```
>>>>
>>>> That said, the point holds for the proposal in its current state. Being
>>>> able to compose functions
>>>> leads to much more expressivity than if you have
>>>> to call the pipeline (and collapse) where it is defined.
>>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>>>>>
>>>>> The function composition operator composes function pipelines into
>>>>> functions for later use and/or further composition. Those functions
>>>>> still
>>>>> need to be called via the existing `()` syntax, so it doesn't offer a
>>>>> different way of calling functions as such.
>>>>>
>>>>> The function pipeline operator calls the function pipeline immediately,
>>>>> so it is really only a different way of calling functions.
>>>>>
>>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]> wrote:
>>>>>>
>>>>>> How is either operator not "a different way of calling functions"?
>>>>>>
>>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> I was just thinking about the relative merits and coexistence (or
>>>>>>> not)
>>>>>>> of function composition operator and function pipeline operator
>>>>>>> features:
>>>>>>>
>>>>>>> e.g.
>>>>>>>
>>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition
>>>>>>> https://github.com/tc39/proposal-pipeline-operator
>>>>>>>
>>>>>>> They can of course co-exist, but there is overlap only in the respect
>>>>>>> that both allow function pipelines to be called from left to right
>>>>>>> (except
>>>>>>> the input parameter in the case of the composition feature, which
>>>>>>> requires
>>>>>>> existing bracket syntax to be used to call it). If one were to be
>>>>>>> chosen,
>>>>>>> would say that a function composition operator adds a whole new
>>>>>>> dimension of
>>>>>>> expressive power to the language, whereas a pipeline operator only
>>>>>>> offers a
>>>>>>> different way of calling functions.
>>>>>>>
>>>>>>> I was wondering about all of your thoughts about whether you'd prefer
>>>>>>> only the pipeline operator, only the composition operator, or both,
>>>>>>> or
>>>>>>> neither to be added to the language (these are pretty much all the
>>>>>>> possibilities), and why.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
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: Function composition vs pipeline

kai zhu
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:

> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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: Function composition vs pipeline

Peter Jaszkowiak
Personally, I'd push my subordinates to learn this new syntax. But if you dislike it, you can blacklist it in your linter: it's one of the main features of a linter. 

On Mar 10, 2018 23:37, "kai zhu" <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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: Function composition vs pipeline

Terence M. Bandoian
In my opinion, one of the more significant advances in the C programming language was the increase in the maximum length of identifiers.  To me, this translates to "less cryptic is better".

-Terence Bandoian


On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote:
Personally, I'd push my subordinates to learn this new syntax. But if you dislike it, you can blacklist it in your linter: it's one of the main features of a linter. 

On Mar 10, 2018 23:37, "kai zhu" <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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: Function composition vs pipeline

Jordan Harband
As someone who does wear the shoes of a senior programmer responsible (along with my team) for overseeing a very very large web project, the super trivial and easy answer to this is "use a linter" - eslint can be configured to restrict any syntax you like, and since surely your CI process is already gating any merges, so too can the linter be used to gate merges, which will prevent anyone from any using any syntax you deem unclean.

Tons of new syntax can be added to JavaScript forever and it need not have a single bit of impact on any of your project's code except a few lines in your eslint configuration.

On Mon, Mar 12, 2018 at 8:26 AM, Terence M. Bandoian <[hidden email]> wrote:
In my opinion, one of the more significant advances in the C programming language was the increase in the maximum length of identifiers.  To me, this translates to "less cryptic is better".

-Terence Bandoian



On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote:
Personally, I'd push my subordinates to learn this new syntax. But if you dislike it, you can blacklist it in your linter: it's one of the main features of a linter. 

On Mar 10, 2018 23:37, "kai zhu" <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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: Function composition vs pipeline

Mark Miller-2


On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband <[hidden email]> wrote:
As someone who does wear the shoes of a senior programmer responsible (along with my team) for overseeing a very very large web project, the super trivial and easy answer to this is "use a linter" - eslint can be configured to restrict any syntax you like, and since surely your CI process is already gating any merges, so too can the linter be used to gate merges, which will prevent anyone from any using any syntax you deem unclean.

Tons of new syntax can be added to JavaScript forever and it need not have a single bit of impact on any of your project's code except a few lines in your eslint configuration.


Hi Jordan, while I agree with some of your overall point, I think this goes way too far. The larger the language, and the more diversity there is in which subset one shop chooses vs another, the more we loose the benefits of having many developers use a common language. No one shop writes all the JS they use. They use libraries written by others whose lint rules are different. They hire programmers from other shops. They read and post to stackOverflow, etc.

Much better is for the language to omit as much as possible, keeping it small. I am glad my "Tragedy of the Common Lisp" post is so widely cited and appreciated. Later in that thread, at https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22 I state a hierarchy of different parts of a language with different pressures towards minimality:


the force of my [minimality] point gets weaker as we move from core language to standardizing libraries. The overall standard language can be seen as consisting of these major parts:
  • fundamental syntax -- the special forms that cannot faithfully be explained by local expansion to other syntax
  • semantic state -- the state than computation manipulates
  • kernel builtins -- built in library providing functionality that, if it were absent, could not be provided instead by user code.
  • intrinsics -- libraries that semantic state or kernel builtins depend on. For example, with Proxies, one might be able to do Array in user code. But other kernel builtins already have a dependency on Array specifically, giving it a privileged position over any replacement.
  • syntactic sugar -- the syntax that can be explained by local expansion to fundamental syntax.
  • global convenience libraries -- could be implemented by unprivileged user code, but given standard global naming paths in the primordial global namespace.
  • standard convenient library modules
I have listed these in order, according to my sense of the costs of growth and the urgency for minimalism. For all of these we still need to exercise discipline. But it is only for the last one that we should consider growth of absolute size to be unbounded; restricting ourselves only to the rate of growth as we wait for candidates to prove themselves first by the de facto process. Ideally, TC39 should stop being the bottleneck on the last bullet anyway, as external de facto and de jure processes should be perfectly capable of independently arguing about and evolving standard convenience modules.


Although syntactic sugar is low on the list, it is still costly and best avoided when there's no compelling need. "Just use a linter" is not a panacea.

 

On Mon, Mar 12, 2018 at 8:26 AM, Terence M. Bandoian <[hidden email]> wrote:
In my opinion, one of the more significant advances in the C programming language was the increase in the maximum length of identifiers.  To me, this translates to "less cryptic is better".

-Terence Bandoian



On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote:
Personally, I'd push my subordinates to learn this new syntax. But if you dislike it, you can blacklist it in your linter: it's one of the main features of a linter. 

On Mar 10, 2018 23:37, "kai zhu" <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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




--
  Cheers,
  --MarkM

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

Re: Function composition vs pipeline

Jordan Harband
All good points :-) I wasn't suggesting there's no cost to adding syntax to a language; I was suggesting that kai's blanket "please don't add new syntax because I don't want to have to deal with it in my project" isn't a useful objection on its own.

On Tue, Mar 13, 2018 at 7:59 AM, Mark Miller <[hidden email]> wrote:


On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband <[hidden email]> wrote:
As someone who does wear the shoes of a senior programmer responsible (along with my team) for overseeing a very very large web project, the super trivial and easy answer to this is "use a linter" - eslint can be configured to restrict any syntax you like, and since surely your CI process is already gating any merges, so too can the linter be used to gate merges, which will prevent anyone from any using any syntax you deem unclean.

Tons of new syntax can be added to JavaScript forever and it need not have a single bit of impact on any of your project's code except a few lines in your eslint configuration.


Hi Jordan, while I agree with some of your overall point, I think this goes way too far. The larger the language, and the more diversity there is in which subset one shop chooses vs another, the more we loose the benefits of having many developers use a common language. No one shop writes all the JS they use. They use libraries written by others whose lint rules are different. They hire programmers from other shops. They read and post to stackOverflow, etc.

Much better is for the language to omit as much as possible, keeping it small. I am glad my "Tragedy of the Common Lisp" post is so widely cited and appreciated. Later in that thread, at https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22 I state a hierarchy of different parts of a language with different pressures towards minimality:


the force of my [minimality] point gets weaker as we move from core language to standardizing libraries. The overall standard language can be seen as consisting of these major parts:
  • fundamental syntax -- the special forms that cannot faithfully be explained by local expansion to other syntax
  • semantic state -- the state than computation manipulates
  • kernel builtins -- built in library providing functionality that, if it were absent, could not be provided instead by user code.
  • intrinsics -- libraries that semantic state or kernel builtins depend on. For example, with Proxies, one might be able to do Array in user code. But other kernel builtins already have a dependency on Array specifically, giving it a privileged position over any replacement.
  • syntactic sugar -- the syntax that can be explained by local expansion to fundamental syntax.
  • global convenience libraries -- could be implemented by unprivileged user code, but given standard global naming paths in the primordial global namespace.
  • standard convenient library modules
I have listed these in order, according to my sense of the costs of growth and the urgency for minimalism. For all of these we still need to exercise discipline. But it is only for the last one that we should consider growth of absolute size to be unbounded; restricting ourselves only to the rate of growth as we wait for candidates to prove themselves first by the de facto process. Ideally, TC39 should stop being the bottleneck on the last bullet anyway, as external de facto and de jure processes should be perfectly capable of independently arguing about and evolving standard convenience modules.


Although syntactic sugar is low on the list, it is still costly and best avoided when there's no compelling need. "Just use a linter" is not a panacea.

 

On Mon, Mar 12, 2018 at 8:26 AM, Terence M. Bandoian <[hidden email]> wrote:
In my opinion, one of the more significant advances in the C programming language was the increase in the maximum length of identifiers.  To me, this translates to "less cryptic is better".

-Terence Bandoian



On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote:
Personally, I'd push my subordinates to learn this new syntax. But if you dislike it, you can blacklist it in your linter: it's one of the main features of a linter. 

On Mar 10, 2018 23:37, "kai zhu" <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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




--
  Cheers,
  --MarkM


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

Re: Function composition vs pipeline

Alexander Jones
In reply to this post by kai zhu
Straw man. The problem is variables named h, f and g, not the use of a composition operator.

On Sun, 11 Mar 2018 at 07:37, kai zhu <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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: Function composition vs pipeline

kai zhu
On Mar 13, 2018, at 10:27 PM, Michael J. Ryan <[hidden email]> wrote:

I'm jumping in late here, but being in that role, I can tell what it's doing mostly by looking at it... It looks like and is a pipeline.  I actually find that less confusing than deeply nested calls...  

a(b(c(d(e), f)))   

which I've seen in real code... vs

e |> d |> (r => c(r,f)) |> b |> a  

Which is a bit easier to reason with even if a little more verbose.  Each step is in order instead of nesting which is reverse order.


@michael, i would argue a simple, magic-free, es5 recursive-callback of the following form is the easiest to read / debug / set-breakpoints-with:

```js
var callbackState, recursiveCallback;
recursiveCallback = function (error, data) {
    // catch-all error-handler
    if (error) {
        ...
        return;
    }
    callbackState += 1;
    console.error('recursive-callback at case ' + callbackState);
    switch (callbackState) {
    case 1:
        dd(ee, recursiveCallback);
        break;
    // combine data with ff
    case 2:
        cc(data, ff, recursiveCallback);
        break;
    case 3:
        bb(data, recursiveCallback);
        break;
    case 4:
        aa(data, recursiveCallback);
        break;
    }
};
callbackState = 0;
recursiveCallback();
```

here's the full, standalone, working example for your use-case (that’s both browser and nodejs compatible) with attached screenshot of it running in browser (and another one showing how easy it is to step-through and debug with only a single breakpoint).

```
/*jslint
    bitwise: true,
    browser: true,
    maxerr: 8,
    maxlen: 256,
    node: true,
    nomen: true,
    regexp: true,
    stupid: true
*/
'use strict’;
var aa, bb, cc, dd, ee, ff, callbackState, recursiveCallback;
ff = 'goodbye world!';
ee = 'hello world!';
dd = function (data, recursiveCallback) {
    console.log('dd(ee) - simulating 300ms io-request with data=' + JSON.stringify(data) + ' ...');
    setTimeout(recursiveCallback, 300, null, data);
};
cc = function (data, data2, recursiveCallback) {
    console.log('cc(dd(ee), ff) - simulating 200ms io-request with data=' + JSON.stringify(data) + ' and data2=' + JSON.stringify(data2) +  ' ...');
    setTimeout(recursiveCallback, 200, null, data + ' ' + data2);
};
bb = function (data, recursiveCallback) {
    console.log('bb(cc(dd(ee), ff)) - simulating 100ms io-request with data=' + JSON.stringify(data) + ' ...');
    setTimeout(recursiveCallback, 100, null, data);
};
aa = function (data, recursiveCallback) {
    console.log('aa(bb(cc(dd(ee), ff))) - printing data ' + JSON.stringify(data));
    // simulate error
    recursiveCallback(new Error('this is a test error'));
};



recursiveCallback = function (error, data) {
    // catch-all error-handler
    if (error) {
        console.error('error occured in recursive-callback at case ' + callbackState);
        console.error(error);
        return;
    }
    callbackState += 1;
    console.error('recursive-callback at case ' + callbackState);
    switch (callbackState) {
    case 1:
        dd(ee, recursiveCallback);
        break;
    // combine data with ff
    case 2:
        cc(data, ff, recursiveCallback);
        break;
    case 3:
        bb(data, recursiveCallback);
        break;
    case 4:
        aa(data, recursiveCallback);
        break;
    }
};
callbackState = 0;
recursiveCallback();

/*
output:

recursive-callback at case 1
dd(ee) - simulating 300ms io-request with data="hello world!" ...
recursive-callback at case 2
cc(dd(ee), ff) - simulating 200ms io-request with data="hello world!" and data2="goodbye world!" ...
recursive-callback at case 3
bb(cc(dd(ee), ff)) - simulating 100ms io-request with data="hello world! goodbye world!" ...
recursive-callback at case 4
aa(bb(cc(dd(ee), ff))) - printing data "hello world! goodbye world!"
error occured in recursive-callback at case 4
Error: this is a test error
    at aa (/private/tmp/example.js:30:23)
    at Timeout.recursiveCallback [as _onTimeout] (/private/tmp/example.js:56:9)
    at ontimeout (timers.js:393:18)
    at tryOnTimeout (timers.js:250:5)
    at Timer.listOnTimeout (timers.js:214:5)
*/
```


On Mar 14, 2018, at 7:19 AM, Alexander Jones <[hidden email]> wrote:

Straw man. The problem is variables named h, f and g, not the use of a composition operator.

On Sun, 11 Mar 2018 at 07:37, kai zhu <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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: Function composition vs pipeline

Michael J. Ryan
And only 50x the amount of code too.

On Mar 14, 2018 16:32, "kai zhu" <[hidden email]> wrote:
On Mar 13, 2018, at 10:27 PM, Michael J. Ryan <[hidden email]> wrote:

I'm jumping in late here, but being in that role, I can tell what it's doing mostly by looking at it... It looks like and is a pipeline.  I actually find that less confusing than deeply nested calls...  

a(b(c(d(e), f)))   

which I've seen in real code... vs

e |> d |> (r => c(r,f)) |> b |> a  

Which is a bit easier to reason with even if a little more verbose.  Each step is in order instead of nesting which is reverse order.


@michael, i would argue a simple, magic-free, es5 recursive-callback of the following form is the easiest to read / debug / set-breakpoints-with:

```js
var callbackState, recursiveCallback;
recursiveCallback = function (error, data) {
    // catch-all error-handler
    if (error) {
        ...
        return;
    }
    callbackState += 1;
    console.error('recursive-callback at case ' + callbackState);
    switch (callbackState) {
    case 1:
        dd(ee, recursiveCallback);
        break;
    // combine data with ff
    case 2:
        cc(data, ff, recursiveCallback);
        break;
    case 3:
        bb(data, recursiveCallback);
        break;
    case 4:
        aa(data, recursiveCallback);
        break;
    }
};
callbackState = 0;
recursiveCallback();
```

here's the full, standalone, working example for your use-case (that’s both browser and nodejs compatible) with attached screenshot of it running in browser (and another one showing how easy it is to step-through and debug with only a single breakpoint).

```
/*jslint
    bitwise: true,
    browser: true,
    maxerr: 8,
    maxlen: 256,
    node: true,
    nomen: true,
    regexp: true,
    stupid: true
*/
'use strict’;
var aa, bb, cc, dd, ee, ff, callbackState, recursiveCallback;
ff = 'goodbye world!';
ee = 'hello world!';
dd = function (data, recursiveCallback) {
    console.log('dd(ee) - simulating 300ms io-request with data=' + JSON.stringify(data) + ' ...');
    setTimeout(recursiveCallback, 300, null, data);
};
cc = function (data, data2, recursiveCallback) {
    console.log('cc(dd(ee), ff) - simulating 200ms io-request with data=' + JSON.stringify(data) + ' and data2=' + JSON.stringify(data2) +  ' ...');
    setTimeout(recursiveCallback, 200, null, data + ' ' + data2);
};
bb = function (data, recursiveCallback) {
    console.log('bb(cc(dd(ee), ff)) - simulating 100ms io-request with data=' + JSON.stringify(data) + ' ...');
    setTimeout(recursiveCallback, 100, null, data);
};
aa = function (data, recursiveCallback) {
    console.log('aa(bb(cc(dd(ee), ff))) - printing data ' + JSON.stringify(data));
    // simulate error
    recursiveCallback(new Error('this is a test error'));
};



recursiveCallback = function (error, data) {
    // catch-all error-handler
    if (error) {
        console.error('error occured in recursive-callback at case ' + callbackState);
        console.error(error);
        return;
    }
    callbackState += 1;
    console.error('recursive-callback at case ' + callbackState);
    switch (callbackState) {
    case 1:
        dd(ee, recursiveCallback);
        break;
    // combine data with ff
    case 2:
        cc(data, ff, recursiveCallback);
        break;
    case 3:
        bb(data, recursiveCallback);
        break;
    case 4:
        aa(data, recursiveCallback);
        break;
    }
};
callbackState = 0;
recursiveCallback();

/*
output:

recursive-callback at case 1
dd(ee) - simulating 300ms io-request with data="hello world!" ...
recursive-callback at case 2
cc(dd(ee), ff) - simulating 200ms io-request with data="hello world!" and data2="goodbye world!" ...
recursive-callback at case 3
bb(cc(dd(ee), ff)) - simulating 100ms io-request with data="hello world! goodbye world!" ...
recursive-callback at case 4
aa(bb(cc(dd(ee), ff))) - printing data "hello world! goodbye world!"
error occured in recursive-callback at case 4
Error: this is a test error
    at aa (/private/tmp/example.js:30:23)
    at Timeout.recursiveCallback [as _onTimeout] (/private/tmp/example.js:56:9)
    at ontimeout (timers.js:393:18)
    at tryOnTimeout (timers.js:250:5)
    at Timer.listOnTimeout (timers.js:214:5)
*/
```


On Mar 14, 2018, at 7:19 AM, Alexander Jones <[hidden email]> wrote:

Straw man. The problem is variables named h, f and g, not the use of a composition operator.

On Sun, 11 Mar 2018 at 07:37, kai zhu <[hidden email]> wrote:
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project.  the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common integration/qa
javascript-bugs).

while trying to figure out what's causing the timeout-issue, you're
debugging i/o code with operators that look like this:

```
const h = ? |> f |> g;
```

maybe it is useful for the small-picture sub-problem you were
originally trying to solve. but now that you're a bigger-fish with
bigger-picture integration i/o issues, doesn't this look alot like
technical-debt that no one will have a clue how to debug once a month
or two has passed?

-kai

On 3/11/18, Peter Jaszkowiak <[hidden email]> wrote:
> Oh please,
>
> This is an alternative syntax that's very useful for many people. If you
> want too simplify syntax yourself you can use a linter to disable
> alternatives.
>
> On Mar 10, 2018 22:56, "kai zhu" <[hidden email]> wrote:
>
>> my vote is for neither.  exactly what industry painpoint or
>> problem-space do either of these proposals solve?
>>
>> rather, they compound an existing industry painpoint; where
>> ocd-programmers have problems in deciding-and-choosing which es6
>> style/design-pattern to employ and stick with before coding even
>> begins. many of us wish there were less choices, like python (and a
>> more assertive tc39 that makes clear certain proposals are
>> productivity-negative and not open for debate) so we could get on with
>> the actual coding-part.
>>
>> from a senior-engineer / technical-manager perspective, it also
>> doesn't help in managing an entire web-project; comprised of dozens of
>> sub-components that you didn't all write yourself; and having to
>> context-switch for each sub-component's quirky es6/es7/es8/es9
>> style-guide/design-pattern.
>>
>> On 3/4/18, Isiah Meadows <[hidden email]> wrote:
>> > Just thought I'd point out that the proposal itself entertains the
>> > possibility of a corresponding composition proposal [1]. Also, in my
>> > proposal, one of my "potential expansions" [2] would open a generic
>> > door for "lifting" over a type, addressing the concern of
>> > extensibility. (It's not ideal, and I just filed an issue in my repo
>> > for that, but that's orthogonal.)
>> >
>> > [1]: https://github.com/tc39/proposal-pipeline-operator#
>> related-proposals
>> > [2]:
>> > https://github.com/isiahmeadows/function-composition-proposal#possible-
>> expansions
>> >
>> > -----
>> >
>> > 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 Sat, Feb 24, 2018 at 5:40 AM, Naveen Chawla <[hidden email]>
>> > wrote:
>> >> Although it doesn't allow composition with generator functions like
>> >> the
>> >> composition proposal does, otherwise it's a pretty good solution.
>> >>
>> >> My only concern with pipeline is that since it offers a different way
>> >> of
>> >> calling functions than the `()` syntax, it can lead to mixed and hence
>> >> slightly more confusing code when both `()` and `|>` are used. For
>> example
>> >> multi arg and no-arg functions would still use `()`, and single arg
>> >> functions may or may not use `|>` depending on whether or not they may
>> >> prospectively use a pipeline. The composition operator doesn't
>> >> supersede
>> >> the
>> >> `()` syntax in any context, and so it could be argued it would lead to
>> >> more
>> >> consistent, more readable code.
>> >>
>> >> On Sat, 24 Feb 2018 at 15:02 Peter Jaszkowiak <[hidden email]>
>> wrote:
>> >>>
>> >>> I'd like to point out the partial application operator:
>> >>> https://github.com/tc39/proposal-partial-application
>> >>>
>> >>> Sounds like the combination of pipeline + partial application would
>> >>> result
>> >>> in what is essentially the same as function composition operator:
>> >>>
>> >>> ```
>> >>> const h = ? |> f |> g;
>> >>> ```
>> >>>
>> >>> Which results in `h` being the composition `g • f`.
>> >>>
>> >>>
>> >>> On Feb 24, 2018 02:21, "Naveen Chawla" <[hidden email]> wrote:
>> >>>
>> >>> That could be a problem for readability.
>> >>> I agree with the rest of what you said.
>> >>>
>> >>>
>> >>> On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall <
>> [hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> I don’t know the implications but I could easily imagine the
>> >>>> pipeline
>> >>>> proposal being extended to not taking any input on the left hand
>> >>>> side
>> >>>> and
>> >>>> effectively represent composition in the opposite direction.
>> >>>>
>> >>>> For example:
>> >>>> ```
>> >>>> let h = |> f |> g
>> >>>> h(2) //g(f(2))
>> >>>> ```
>> >>>>
>> >>>> That said, the point holds for the proposal in its current state.
>> Being
>> >>>> able to compose functions
>> >>>> leads to much more expressivity than if you have
>> >>>> to call the pipeline (and collapse) where it is defined.
>> >>>> 2018年2月24日(土) 14:32 Naveen Chawla <[hidden email]>:
>> >>>>>
>> >>>>> The function composition operator composes function pipelines into
>> >>>>> functions for later use and/or further composition. Those functions
>> >>>>> still
>> >>>>> need to be called via the existing `()` syntax, so it doesn't offer
>> >>>>> a
>> >>>>> different way of calling functions as such.
>> >>>>>
>> >>>>> The function pipeline operator calls the function pipeline
>> immediately,
>> >>>>> so it is really only a different way of calling functions.
>> >>>>>
>> >>>>> On Fri, 23 Feb 2018 at 12:37 Jordan Harband <[hidden email]>
>> wrote:
>> >>>>>>
>> >>>>>> How is either operator not "a different way of calling functions"?
>> >>>>>>
>> >>>>>> On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> I was just thinking about the relative merits and coexistence (or
>> >>>>>>> not)
>> >>>>>>> of function composition operator and function pipeline operator
>> >>>>>>> features:
>> >>>>>>>
>> >>>>>>> e.g.
>> >>>>>>>
>> >>>>>>> https://github.com/TheNavigateur/proposal-pipeline-operator-for-
>> function-composition
>> >>>>>>> https://github.com/tc39/proposal-pipeline-operator
>> >>>>>>>
>> >>>>>>> They can of course co-exist, but there is overlap only in the
>> respect
>> >>>>>>> that both allow function pipelines to be called from left to
>> >>>>>>> right
>> >>>>>>> (except
>> >>>>>>> the input parameter in the case of the composition feature, which
>> >>>>>>> requires
>> >>>>>>> existing bracket syntax to be used to call it). If one were to be
>> >>>>>>> chosen,
>> >>>>>>> would say that a function composition operator adds a whole new
>> >>>>>>> dimension of
>> >>>>>>> expressive power to the language, whereas a pipeline operator
>> >>>>>>> only
>> >>>>>>> offers a
>> >>>>>>> different way of calling functions.
>> >>>>>>>
>> >>>>>>> I was wondering about all of your thoughts about whether you'd
>> prefer
>> >>>>>>> only the pipeline operator, only the composition operator, or
>> >>>>>>> both,
>> >>>>>>> or
>> >>>>>>> neither to be added to the language (these are pretty much all
>> >>>>>>> the
>> >>>>>>> possibilities), and why.
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> _______________________________________________
>> 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
12