Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grammar rules in proposed spec text seem incomplete #290

Open
sethbrenith opened this issue Jan 22, 2023 · 2 comments
Open

Grammar rules in proposed spec text seem incomplete #290

sethbrenith opened this issue Jan 22, 2023 · 2 comments

Comments

@sethbrenith
Copy link

sethbrenith commented Jan 22, 2023

Based on the description in README.md, it seems that the pipeline operator is intended to be left-associative: a |> b |> c is equivalent to (a |> b) |> c. The proposed spec text defines the following production:

    PipeExpression[In, Yield, Await] :
      ShortCircuitExpression[?In, ?Yield, ?Await] |> PipeBody[?In, ?Yield, ?Await]

However, the proposed text does not include any rules for how ShortCircuitExpression can be a PipeExpression, which I assume would be necessary for parsing a |> b |> c.

Furthermore, in order for the grammar to be unambiguous, the right side of the PipeExpression production should be something which can't be a PipeExpression. If we assume ShortCircuitExpression can be a PipeExpression, then PipeBody can also be a PipeExpression with the current production rules, which causes ambiguity. I expect the production to be of the form:

    PipeExpression :
      SomethingWhichCanBeAPipeExpression |> SomethingWhichCannotBeAPipeExpression

I expect it will be somewhat difficult to define unambiguous grammar rules for a new left-associative operator which is at the same precedence level as a bunch of existing right-associative operators; this may be indicative of a fundamental problem with the currently proposed precedence level.

@tabatkins
Copy link
Collaborator

It actually doesn't matter whether the pipe is left- or right-associative; either associativity gives identical evaluation results.

I'm not sure if that affects your point, just saying.

@sethbrenith
Copy link
Author

Oh, excellent point! If it works as right-associative, then I'm no longer concerned about the proposed operator precedence. Thanks.

In that case, I think we just need the proposed spec to include a modification to the expansion rules for AssignmentExpression to indicate that it can be a PipeExpression.

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

No branches or pull requests

2 participants