es-discuss Digest, Vol 106, Issue 30

John Gardner gardnerjohng at gmail.com
Fri Dec 11 16:12:52 UTC 2015


Hah! What's wrong with APL? We could bring back the ol' typeballs and call
'em ECMABalls.

Seriously though, I find the |> operator echoes the traditional Unix pipe
quite well (obviously we can't use the bitwise | for self-explanatory
reasons). I think most users would find it the easiest to familiar with.

Also don't forget that the "OR" operator can also be used for bitwise
assignments (variable |= 20, etc). How much of an issue is it if it shares
a character with a non-bitwise (bitunwise?) operator?

On 12 December 2015 at 03:08, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: The "Pipeline" Operator - Making multiple function calls
>       look      great (Alexander Jones)
>
>
> ---------- Forwarded message ----------
> From: Alexander Jones <alex at weej.com>
> To: Gilbert B Garza <gilbertbgarza at gmail.com>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Fri, 11 Dec 2015 16:08:24 +0000
> Subject: Re: The "Pipeline" Operator - Making multiple function calls look
> great
> 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
>>
>>
>
> _______________________________________________
> 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/20151212/68c8efd2/attachment-0001.html>


More information about the es-discuss mailing list