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
