On Sun, Mar 11, 2018 at 4:44 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
> On Sun, Mar 11, 2018 at 2:36 PM, Peter Jaszkowiak <p.jasz...@gmail.com> 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 |>

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. ^_^

es-discuss mailing list

Reply via email to