Skip to content
This repository has been archived by the owner on Jan 26, 2022. It is now read-only.

Left precedence of pipeline #12

Closed
jridgewell opened this issue Aug 13, 2021 · 4 comments
Closed

Left precedence of pipeline #12

jridgewell opened this issue Aug 13, 2021 · 4 comments

Comments

@jridgewell
Copy link
Member

Spinning this out of #11:

On the left, |> is as tight as assignment operators. This allows parsing x = y |> z as x = (y |> z), and x ? y : z |> w as (x ? y : z) |> w.

That ternary example is super confusing, and it's different than how arrows are parsed:

// arrow:
x ? y : z => w;

// parsed as
x ? y : (z => w);

The spec seems to say arrows and pipelines would bind at the same level, so I'd think the ternary example would be x ? y : (z |> w)

When I load this into AST explorer, I actually get the same results for pipeline and arrow, but maybe that's just because babel hasn't fixed the right-associativity of the operator yet.

/cc @nicolo-ribaudo

@js-choi
Copy link
Collaborator

js-choi commented Aug 13, 2021

Yeah, x ? y : z |> w does break parallelism with x ? y : z => w—because x ? y : z is an invalid left-hand side for =>, it does not group in the same way that |> would.

I’m not sure what the best way to tackle this would be. That’s a fundamental difference between the left-hand sides of => and |>. (The right-hand sides’ grouping remains the same, as far as I can tell.)

That AST Explorer behavior is probably due to its using Babel 7.14, before Hack pipes were actually introduced.

@nicolo-ribaudo
Copy link
Member

When trying to think about "what's confusing", always also consider the example with the syntax in the middle:

a |> % ? b : c |> % + 1

Should it be a |> (% ? b : c) |> % + 1 or a |> (% ? b : (c |> % + 1)?

On the other hand, a ? b |> % + 1 : c |> % + 2 is really confusing.


Fyi, I opened fkling/astexplorer#599 for ASTExplorer.

@js-choi
Copy link
Collaborator

js-choi commented Aug 17, 2021

After more thought, I think we should require all conditionals to be parenthesized in pipe heads/bodies after all.

I’m thinking that the most desirable behavior might be to ban any any other assignment-level operation without parentheses as a pipe head or body. (The other assignment-level operations are =>, =, +=, etc., ? :, and yield.)

In contrast, pipe expressions would be allowed at any place in other assignment-level operations. So x ? y : z |> w would be parsed as x ? y : (z |> w)—parallelism with => would be maintained.

I put a table with this behavior in #11 (comment). I plan to edit the explainer and spec soon.

@js-choi
Copy link
Collaborator

js-choi commented Aug 17, 2021

After 6c458b5, the left side of a |> PipeExpression is now ShortCircuitExpression, while its right side remains AssignmentExpression. The behavior should match that in #11 (comment). This should be less confusing and address this confusing mismatch with =>’s grouping. Thanks, @jridgewell, for pointing it out; let me know if you still have a concern.

Conditional then arrow/pipe
x ? y : z => w x ? y : (z => w)
x ? y : z |> % x ? y : (z |> %)
Arrow/pipe then conditional
w => x ? y : z w => (x ? y : z)
w |> % ? y : z SyntaxError
w |> (% ? y : z) w |> (% ? y : z)
(w |> %) ? y : z (w |> %) ? y : z

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants