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
