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, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Gilbert B Garza <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 <[email protected]> > 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 < >> [email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected] >>>>> > wrote: >>>>> >>>>>> >>>>>> >On Dec 6, 2015, at 4:51 PM, Gilbert B Garza <[email protected]> >>>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Inline >>>>>>>>> >>>>>>>>> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith < >>>>>>>>> [email protected]> 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 >>>>>>>>> > [email protected] >>>>>>>>> > 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 >>>>>>> [email protected] >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
