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

Rick Waldron waldron.rick at gmail.com
Fri Dec 11 14:07:03 UTC 2015


Has anyone tried writing grammar for this? The "|>" token requires a a
lookahead to disambiguate the bit wise OR operator `|`


- Rick



On Sun, Dec 6, 2015 at 6:38 PM Gilbert B Garza <gilbertbgarza at gmail.com>
wrote:

> > 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
>>>
>>>
>>>
>>
>>
> _______________________________________________
> 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/20151211/28831be6/attachment-0001.html>


More information about the es-discuss mailing list