The "Pipeline" Operator - Making multiple function calls look great

Gilbert B Garza gilbertbgarza at gmail.com
Sun Dec 6 23:37:47 UTC 2015


> It doesn’t look like there is any redeeming quality about this change, it
doesn’t introduce convenience

I think you may have missed the GitHub repo [1]; it outlines benefits and
convenience about the change. Also see this user's comment [2] on its
significance.

[1] https://github.com/mindeavor/es-pipeline-operator
[2] https://news.ycombinator.com/item?id=10686596

I argue that the syntax transformation is so simple that it would not
introduce any pain points for JavaScript authors. It is arguably more
intuitive than its alternative. JS programmers who are partial to FP
certainly agree [3][4].

[3] https://twitter.com/markdalgleish/status/673581814028492800
[4]
https://www.reddit.com/r/javascript/comments/3vox7x/es7_proposal_the_pipeline_operator/

> Anything involving “placeholders arguments” is especially bad because it
introduces an extra thing to reason about

I agree; I still prefer the original proposal.

> The bind operator may at least have the benefit of providing some out of
the box support for classic FP style

It does not, unfortunately. FP devs avoid the keyword `this`, but the bind
operator requires its use. If I'm not mistaken, the "chaining" part of the
bind operator is only a minor point, and isn't the main purpose of the
proposal.



On Sun, Dec 6, 2015 at 4:56 PM, Caitlin Potter <caitpotter88 at gmail.com>
wrote:

>
> >On Dec 6, 2015, at 4:51 PM, Gilbert B Garza <gilbertbgarza at gmail.com>
> wrote:
> >
> >Confusing and horrible are subjective, but I do agree that it's not as
> nice as the original proposal.
> >Although I prefer the original, it's also important to discuss objections
> that people bring up, as well as
> >the alternatives that might solve said objections :)
>
> Even with the original solution, it just creates a new (and less obvious)
> way of writing something that is already possible in the language,
> and easier to understand. There is a narrow scope of times where it even
> makes sense to use the original (or enhanced) version of the
> proposal, and this requires authors to be vigilante about knowing when to
> pick one form over the other. It also requires code reviewers
> to be vigilante in knowing when to say “know, this is a bad idea, stop”.
>
> It doesn’t look like there is any redeeming quality about this change, it
> doesn’t introduce convenience, and does introduce new pain points
> for authors. Anything involving “placeholders arguments” is especially bad
> because it introduces an extra thing to reason about, but the issue
> with introducing a new syntax to pick and be aware of for limited gains is
> also problematic, growing the language and increasing complexity
> for a less than substantial reason.
>
> The bind operator may at least have the benefit of providing some out of
> the box support for classic FP style, so it’s got that going for it (but
> really,
> the language doesn’t need three distinct syntaxes/idioms for this pattern,
> the complexity budget is already running thin)
>
>
> Gilbert
>
> On Sun, Dec 6, 2015 at 2:18 PM, Caitlin Potter <caitpotter88 at gmail.com>
> wrote:
>
>> These examples only make this language extension look like a confusing
>> and horrible thing. How is this an improvement, in any way?
>>
>> On Dec 6, 2015, at 3:13 PM, Gilbert B Garza <gilbertbgarza at gmail.com>
>> wrote:
>>
>> Status update: The JS community has shown [lots of excitement](
>> https://twitter.com/markdalgleish/status/673581814028492800) for the
>> idea of this proposal, but the syntax is still being debated. I outlined
>> two alternatives [in this GitHub issue](
>> https://github.com/mindeavor/es-pipeline-operator/issues/4), one of
>> which I will post here since it is my current favorite:
>>
>> ## Placeholder Arguments
>>
>> The alternative is to have a new syntax for "placeholder arguments" –
>> basically, slots waiting to be filled by the next function call. For
>> example:
>>
>> ```js
>> //
>> // Placeholder style
>> //
>> run("hello") |> withThis(10, #);
>> // is equivalent to
>> withThis( 10, run("hello") );
>>
>> //
>> // More complicated example
>> //
>> run("hello") |> withThis(10, #) |> andThis(#, 20);
>> // is equivalent to
>> andThis( withThis( 10, run("hello") ), 20 );
>> ```
>>
>> ### Pros / Cons
>>
>> - [pro] Very explicit (no surprises)
>> - [pro] Less function calls
>> - [pro] Compatible with even more of the JavaScript ecosystem
>> - [con] Requires more new syntax
>> - [con] Usage of the hash operator (#) would probably be hard to define
>> outside coupled use with pipeline operator (this problem could be avoided
>> by simply making it illegal)
>>
>>
>> On Tue, Nov 10, 2015 at 4:44 PM, Gilbert B Garza <gilbertbgarza at gmail.com
>> > wrote:
>>
>>> Ah, sorry for being unclear. You're right, in the case of manual
>>> currying, the closure can not and should not be optimized away.
>>>
>>> I was talking about the case where you have arrow function literals. For
>>> example:
>>>
>>> ```js
>>> var bounded = 750
>>>     |> s => Math.max(100, s)
>>>     |> s => Math.min(0, s);
>>> ```
>>>
>>> I imagine if the compiler sees arrow functions used in this specific
>>> manner, it could automatically optimize to the following:
>>>
>>> ```js
>>> var bounded = Math.min( 0, Math.max(100, 750) )
>>> ```
>>>
>>> Semantically, they are equivalent; no closures nor scopes were
>>> effectively used in the intermediary arrow functions.
>>>
>>>
>>> On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows <isiahmeadows at gmail.com>
>>> wrote:
>>>
>>>> Not with your semantics. It has to generate a closure each time,
>>>> because of the possibility it can't be used elsewhere. That's impossible to
>>>> know ahead of time if the variable is ever used outside of its closure or
>>>> as a value. In the case below, it should only log thrice. Otherwise, it's
>>>> unexpected behavior.
>>>>
>>>> ```js
>>>> function add(x) {
>>>>   console.log("Hit!");
>>>>   return y => x + y;
>>>> }
>>>>
>>>> let inc = add(1);
>>>>
>>>> 1 |> inc |> inc |> add(2) |> add(3);
>>>>
>>>> // Hit!
>>>> // Hit!
>>>> // Hit!
>>>> ```
>>>>
>>>> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza <gilbertbgarza at gmail.com>
>>>> wrote:
>>>>
>>>> Normally yes, but since the pipeline operator is a pure function, I
>>>> think it's possible for the compiler to optimize away
>>>> the intermediate arrow functions. I mention this in the "Functions with
>>>> Multiple Arguments" section https
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>> ://
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>> github.com
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>> /
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>> mindeavor
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>> /
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>> ES7-pipeline-operator#functions
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>> -with-multiple-arguments
>>>> <https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments>
>>>>
>>>>
>>>> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows <isiahmeadows at gmail.com>
>>>> wrote:
>>>>
>>>> Inline
>>>>
>>>> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith <zenparsing at gmail.com>
>>>> wrote:
>>>> >> - I don't like the requirement to use the keyword `this` to compose
>>>> >> functions. JS already has many features to support the keyword
>>>> `this`:
>>>> >> prototypes, method invocations, function binding, arrow functions,
>>>> and
>>>> >> probably others. I prefer a feature that assists the other side of
>>>> the
>>>> >> spectrum.
>>>> >
>>>> >
>>>> > Yep - a well documented critique.  It depends on your point of view, I
>>>> > think.  If you view these things as "extension methods", then using
>>>> `this`
>>>> > makes more sense.
>>>> >
>>>> >> - The fact that there are new semantics to what looks like a normal
>>>> >> function call (e.g. `->map(...)`) doesn't set well with me. You
>>>> could argue
>>>> >> that it's something to get used to. Even in that case, I would
>>>> expect the
>>>> >> first argument I give to `map` to stay the first argument.
>>>> >
>>>> >
>>>> > This is a reasonable objection, I think.
>>>>
>>>> Not to mention it's still a point of contention:
>>>> https
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> ://
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> github.com
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> /
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> zenparsing
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> /
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> es-function-bind
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> /issues/26#issuecomment-154130932
>>>> <https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932>
>>>> (from here, down)
>>>>
>>>> >
>>>> >> With the pipeline operator, partial application is left to the
>>>> developer.
>>>> >> They can choose to use arrow functions, or to curry their functions.
>>>> I think
>>>> >> this is the best option since it keeps things simple (no new
>>>> semantics), and
>>>> >> remains readable – see the "Function with Multiple Arguments"
>>>> section in the
>>>> >> GitHub link https
>>>> <https://github.com/mindeavor/ES7-pipeline-operator>://
>>>> <https://github.com/mindeavor/ES7-pipeline-operator>github.com
>>>> <https://github.com/mindeavor/ES7-pipeline-operator>/
>>>> <https://github.com/mindeavor/ES7-pipeline-operator>mindeavor
>>>> <https://github.com/mindeavor/ES7-pipeline-operator>/
>>>> <https://github.com/mindeavor/ES7-pipeline-operator>
>>>> ES7-pipeline-operator
>>>> <https://github.com/mindeavor/ES7-pipeline-operator>
>>>> >
>>>> >
>>>> > I agree that your proposal wins points for simplicity (both semantic
>>>> and
>>>> > syntactic), but having to create an arrow function to pass more than
>>>> one
>>>> > argument feels a bit awkward and seems to defeat some of the
>>>> readability
>>>> > benefit.
>>>>
>>>> Not to mention it would be pretty slow. That's going to be creating a
>>>> closure each call. Engines still struggle with making closures fast.
>>>> It's non-trivial at runtime to create a closure that's performant.
>>>>
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > es-discuss mailing list
>>>> > es-discuss at mozilla.org
>>>> > https <https://mail.mozilla.org/listinfo/es-discuss>://
>>>> <https://mail.mozilla.org/listinfo/es-discuss>mail.mozilla.org
>>>> <https://mail.mozilla.org/listinfo/es-discuss>/
>>>> <https://mail.mozilla.org/listinfo/es-discuss>listinfo
>>>> <https://mail.mozilla.org/listinfo/es-discuss>/
>>>> <https://mail.mozilla.org/listinfo/es-discuss>es-discuss
>>>> <https://mail.mozilla.org/listinfo/es-discuss>
>>>> >
>>>>
>>>> --
>>>> Isiah Meadows
>>>>
>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151206/4fe51eeb/attachment-0001.html>


More information about the es-discuss mailing list