Fix right precedence of Hack pipes

[nicolo-ribaudo]

Q	A
Fixed Issues?
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

Spec: http://jschoi.org/21/es-hack-pipes/#sec-pipe-operator

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/48595/

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit b984f7e:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[jridgewell]

Was this intentional, or just an oversight? I think every other operator is left associative (with the exception of **), which would make this a weird divergence.

[js-choi]

@jridgewell: Yeah, Hack pipes should be right-associative, not left-associative.

Currently, Hack pipes are functionally bidirectionally associative, so (x |> (f(%) |> g(%)) always evaluates to the same thing as ((x |> f(%)) |> g(%). However, Hack pipes are more similar to => than to other operators: both |> and => create a binding over their right-hand body, and => (and by analogy |>) are therefore right-associative to support nested binding contexts.

In fact, after taking with @nicolo-ribaudo, I plan to loosen the precedence of Hack pipes in the specification to AssignmentExpression, to match => further.

Of course, for % bindings this does not matter, since a % binding is shadowed by each inner nested % binding. So currently Hack pipes are functionally bidirectionally associative. However, future extensions to Hack pipes might support binding the topic to a named identifier, à la Haskell’s do syntax, which would make right-associativity essential.

[nicolo-ribaudo]

Let's keep this PR only for the associativity, to give some time for the discussion at tc39/proposal-hack-pipes#11.

[js-choi]

This pull request could probably now be updated to the new changes as per tc39/proposal-hack-pipes#11 and tc39/proposal-hack-pipes#12:

• The left-hand side is now ShortCircuitExpression.
• The right-hand side is still AssignmentExpression, but the right-hand side must not cover an unparenthesized operation with the same precedence (ArrowFunction, AsyncArrowFunction, YieldExpression, ConditionalExpression, or an assignment operation). This check probably should be added to checkHackPipeBodyEarlyErrors.
• The PipeBodyIsTighter error should be removed if it would not break backwards compatibility.

[nicolo-ribaudo]

Updated to reflect the precedence currently defined in the proposal.

[js-choi]

Thanks for continuing to work on this, @nicolo-ribaudo. Once we merge these in, I can work on support for ^ as the topic token.

[JLHwung]

Consider hoist this object to top level so it doesn't have to be re-created in parseHackPipeBody().

[JLHwung]

Could leave a todo item here that invalidBodies currently does not handle TS extensions such as TSAsExpression, they will be supported after TypeScript supports hack pipes.

[nicolo-ribaudo]

I added a todo, but I don't think that it will be a problem because:

• a = b as c is an AssignmentExpression
• a => b as c is an ArrowFunctionExpression
• a ? b : c as d is a ConditionalExpression
• yield as a is a syntax error

[JLHwung]

Oh I was meant to the plain as expression a as c. The precedence of as and |> are unclear before TS supports pipes.

[JLHwung]

We can transform invalidBodies to a map so it comes with .has(), and it's also faster than objects.