This repository was archived by the owner on Jun 15, 2023. It is now read-only.
Treat await as an almost-unary operator. #711
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Making pipe behave like application seems pretty unlikely. First `->` has deep binary operator behavior, including associating to the left on a->b->c, and mixes in specific ways with other operators. Instead application lives on a different level entirely with no issues of how to treat specially the right-hand-side which is enclosed in parens. The await operator is essentially a unary operator. After all it takes on argument. It is also treated as such in JS. Some expected behaviours are that `await 2 + await 3` just like `-2 + -3` is expected to mean `(await 2) + (await 3)`. The issue raised is with pipe: the desired outcome is that `await a->b` is parsed as `await a->b`. However notice that `- a->b` is parsed as `(-a)->b`. So on one side, one would like to have `await` behave like other unary operators. On the other side one wouldn't. As a compromise, this PR treats `await` as an almost-unary operator. In the sense that it binds more tightly than any "real" binary operator such as `+` and `**`, but not more than `->` and `.`. This introduces some lack of uniformity, and requires special-casing parts of parsing and printing.
cristianoc changed the title 
| @cknitt this should be ready to go. Take a look: it should address the last comment on printing. |
mununki approved these changes Oct 31, 2022
| | ||
| let lazyOrAssertOrAwaitExprRhs expr = | ||
| let binaryOperatorInsideAwaitNeedsParens operator = | ||
| ParsetreeViewer.operatorPrecedence operator |
There was a problem hiding this comment.
Is there a behind history? it seems different from Res_token.precedence.
57 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Making pipe behave just like application seems pretty unlikely. First
->has deep binary operator behavior, including associating to the left ona->b->c, and mixes in specific ways with other operators. Instead application lives on a different level entirely with no issues of how to treat specially the right-hand-side which is enclosed in parens (and lives in a radically different place in the call stack of the parser).The await operator is essentially a unary operator. After all it takes one argument. It is also treated as such in JS. Some expected behaviours are that
await 2 + await 3just like-2 + -3is expected to mean(await 2) + (await 3). Or:await getName() ++ await getSurname().The issue raised by people who have tried
awaitis in combination with pipe: the desired outcome is thatawait a->bis parsed asawait (a->b). However notice that- a->bis parsed as(-a)->b, so that's a difference.So on one side, one would like to have
awaitbehave like other unary operators. On the other side one wouldn't.As a compromise, this PR treats
awaitas an almost-unary operator. In the sense that it binds more tightly than any "real" binary operator such as+and**, but not->and..This introduces some lack of uniformity, and requires special-casing parts of parsing and printing.