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
