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

Gilbert B Garza gilbertbgarza at gmail.com
Fri Dec 11 15:23:28 UTC 2015


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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151211/3dfb3ccf/attachment-0001.html>


More information about the es-discuss mailing list