If generator composition isn't directly supported somehow, then I'd have to say I personally find the function composition proposal more compelling on its own, even in the absence of a pipeline operator.
On Mon, 12 Mar 2018 at 05:56 Tab Atkins Jr. <[email protected]> wrote: > On Sun, Mar 11, 2018 at 4:44 PM, Tab Atkins Jr. <[email protected]> > wrote: > > On Sun, Mar 11, 2018 at 2:36 PM, Peter Jaszkowiak <[email protected]> > wrote: > >>> optionally preceded by `new` or `await` > >> > >> This seems very arbitrary and _not_ forwards-compatible. > > > > I agree with arbitrary, tho I think new/await ends up being > > reasonable. What part of it do you think isn't forwards-compatible? > > Afaict, we can definitely add new bare-style forms in the future, as > > attempts to use them today would be a syntax error. > > Actually, I'd like to elaborate here, as I think the inclusion of > new/await is actually very important for understanding the motivations > of bare style as JS has proposed, versus the "arbitrary topic-less > expression that evaluates to a function" form that Dan's original has. > > Ultimately, bare style is just a syntax nicety. Anything you can > write in bare style (either one), you can write in topic style with a > few more characters; it adds no additional power. As such, we should > think about it in terms of what it allows vs what it disallows, and > how useful each category would be. > > In Dan's "arbitrary expression" form, you get: > 1. easy pipelining of variables holding functions: `x |> foo |> bar` > 2. easy pipelining of point-free expressions, or auto-curried > functions: `x |> flip(foo)` or `xs |> filter(pred)` > > You do *not* get: > 3. easy construction of new objects: `x |> new Foo` will call `Foo()` > and then try to call the result with x, when you probably wanted it to > call `new Foo(x)`; you need to instead write `x |> new Foo(#)` > 4. easy awaiting of function results - `x |> await bar` will await the > bar variable and then try to call the result with x, when you probably > wanted it to call `await bar(x)`; you need to instead write `x |> > await bar(#)` or `x |> bar |> await #` > 5. easy method calls!!!: `x |> foo.bar` pulls `bar` off of `foo`, then > calls it with `x`, *without* `foo` being bound to `this`! You probably > wanted it to call `foo.bar(x)`, so you instead you need to write `x |> > foo.bar(#)` > > JS's bare-form, on the other hand, gets you 1, 3, 4, and 5, and only > misses out on 2; you need to write `xs |> filter(pred)(#)` or `xs |> > filter(pred, #)` instead, depending on how the function is defined. I > think that cases 3/4/5 are dramatically more important and common than > case 2. > > What's worse, in the "arbitrary expression" form, if you accidentally > leave off the #, you get a *runtime* error (hopefully) when your > expression is misinterpreted, and have to track down why something is > acting weird. (And each of the three possible mistakes acts weird in a > unique way - an object constructed without its argument, or a promise > showing up unexpectedly, or `this` being `undefined` unexpectedly.) > > In JS's form, if you leave off the # you get a *syntax* error > immediately, pointing you straight to where the problem is. > > So overall I think JS's bare-form is *very* well motivated and > shouldn't be changed. ^_^ > > ~TJ > _______________________________________________ > 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
