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

Alexander Jones alex at weej.com
Fri Dec 11 16:08:24 UTC 2015


I wonder whether we've reach that point in the language where trying to
reuse the same old tokens over and over again in new combinations is
getting untenable. It's a long road to APL...

On 11 December 2015 at 15:23, Gilbert B Garza <gilbertbgarza at gmail.com>
wrote:

> Rick: I would imagine some sort of lookahead is already in the parser,
> considering JavaScript supports both bitwise OR `|` and boolean OR `||` –
> unless this is accomplished some other way?
>
> Gilbert
>
> On Fri, Dec 11, 2015 at 8:52 AM, Felipe Nascimento de Moura <
> felipenmoura at gmail.com> wrote:
>
>> What about a backslash instead?
>> Like escaping a function call, such as:
>>
>> foo("some string")\bar\baz;
>>
>> Or
>>
>> `some ${data}` \ foo \ bar \ console.log;
>>
>>
>>
>>
>> On Fri, Dec 11, 2015 at 12:07 PM, Rick Waldron <waldron.rick at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> *Felipe N. Moura*
>> Senior Web Developer and System Analyst.
>>
>> Website:  http://felipenmoura.com
>> Twitter:    @felipenmoura <http://twitter.com/felipenmoura>
>> LinkedIn: http://goo.gl/qGmq
>>
>> Meet some of my projects:
>> BrazilJS Conference <http://braziljs.com.br/>  |  BrazilJS Foundation
>> <http://braziljs.org>
>> ---------------------------------
>> *Changing  the  world*  is the least I expect from  myself!
>>
>
>
> _______________________________________________
> 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/bec42bdc/attachment-0001.html>


More information about the es-discuss mailing list