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
