Correcting myself: this would be a Punctuator Rick
On Fri, Dec 11, 2015 at 9:07 AM 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
