Details of draft specification

[littledan]

In PR #51 , I wrote some spec text. I'd be interested in feedback on the details here. In particular:

• The right argument of |> is treated directly as a function; even if it is a |CallExpression|, the result of evaluating that |CallExpression| is treated as the function, rather than slotting the left argument into the arguments list. That is x |> y(z) is similar in semantics to y(z)(x). (see Alternate syntax #4)
• The precedence of |> sits between the ternary operator and ||. It is left-associative. (see Operator Precedence - Higher or Lowest? #23)
• All calls to eval through pipeline are indirect eval.
• The pipeline operator is eligible for proper tail calls, when appropriate.
• The left argument to |> is evaluated before the right one.
• If the right argument to |> has a receiver, it is used for the call, with rules similar to a method call. That is x |> y.z gets y as a receiver, just as if it were written y.z(x).

Any thoughts?

Note to positive or negative reacts: tell me why in this thread!

[js-choi]

I haven’t looked at the spec proper yet, but everything in this summary looks great to me—though part of me wonders if it's worth bothering to handle eval, heh. It’s a big enough bomb that any use of it ought to be prominent and not hidden in a |> chain.

That last point about preserving the binding for object methods is an especially nice touch.

[bmeck]

Is there a way to spread an array into the RHS? Given:

const str = 'hello world!\r\n';
[/\r\n/g, '\n'] |> str.replace.apply;

Would have a this value of String.prototype.replace.

[littledan]

@bmeck That almost works, except the first argument to apply is the receiver. You'd have to do the uglier

const str = 'hello world!\r\n';
[/\r\n/g, '\n'] |> str.replace.apply.bind(str);

(Cue an angry mob saying "Why isn't this proposal doing the entire bind operator, which would solve this!)

You could also use this proposal in conjunction with the partial application proposal:

const str = 'hello world!\r\n';
[/\r\n/g, '\n'] |> str.replace(...);

cc @rbuckton

[littledan]

cc @claudepache

[bmeck]

@littledan seems fine, can also use a lambda

[0,1,2] |> $ => console.log(...$)

[littledan]

Kinda; I think you need parens around the arrow function in this grammar, unfortunately (and the above would be a SyntaxError).

[claudepache]

An issue, if we support arrow function on the RHS without parens around it, is the semantics of

x  |>  _ => 2 * _
   |>  f

Because the body of an arrow function may be an Assignment Expression like a = b, we can't make the above expression mean f(2 * x), unless we give |> a lower precedence than assignment (which is probably not a good idea).

[littledan]

@claudepache I believe this specification doesn't support un-parenthized arrow functions, and that example would be a SyntaxError. What do you think of that as a resolution?

[claudepache]

@littledan Yes, a SyntaxError is probably the best outcome in such a case. The proposed spec text of PR #51 seems fine.

[gilbert]

@claudepache @littledan I'm not an expert on JS grammar... could you explain why @claudepache's example does not parse to the following?

x  |>  (_ => 2 * _ |>  f)

[littledan]

@gilbert Because |> expects a LogicalORExpression on as the right argument, and arrow functions are not that type (unless you put parens around them).

[gilbert]

What would be the implications of adding ArrowFunction as a valid righthand argument?

[littledan]

@gilbert I know if that would be the syntax you want, since the body of the arrow function would include any following pipeline operators. But maybe that would all work out reasonably anyway; I need to think about it more.

[littledan]

Thanks for your feedback here. I merged this draft specification.