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

Unary minus binds more tightly than exponentiation #1322

Closed
brianhuffman opened this issue Feb 7, 2022 · 3 comments · Fixed by #1367
Closed

Unary minus binds more tightly than exponentiation #1322

brianhuffman opened this issue Feb 7, 2022 · 3 comments · Fixed by #1367
Assignees
Labels
language Changes or extensions to the language low-hanging fruit For issues that should be easy to fix parser Issues with lexing or parsing.

Comments

@brianhuffman
Copy link
Contributor

According to usual math conventions, - x ^^ y should parse as - (x ^^ y).

However, in Cryptol this is parsed instead as (- x) ^^ y, which surprising, inconsistent, and not useful, especially when used with an even exponent. It is inconsistent because the binary minus operator binds more loosely than exponentiation, so that e.g. w - x ^^ y parses as w - (x ^^ y).

@brianhuffman brianhuffman added parser Issues with lexing or parsing. language Changes or extensions to the language labels Feb 7, 2022
@brianhuffman
Copy link
Contributor Author

Note that ghci gets this right, unlike Cryptol:

Prelude> -2^8 :: Integer
-256
Cryptol> -2^^8 : Integer
256

@yav
Copy link
Member

yav commented Feb 7, 2022

OK, this is because sometime ago we decided to treat - and ~ as normal prefix application. I guess this is a good example of why this is not always a good idea. It seems that the solution would be have a special node in the AST for prefix operator, and then when we do fixity rewrite have special rules to adjust fixity as needed (i.e., prefix operators can also have fixities)

I looked in the GHC source code, and that's what it does also, so there's a precedent that this might be the right solution here.

@jldodds jldodds added the low-hanging fruit For issues that should be easy to fix label Feb 28, 2022
@jldodds
Copy link
Contributor

jldodds commented Feb 28, 2022

When we fix this we should have a way to record if the behavior has changed and raise it in a warning

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language Changes or extensions to the language low-hanging fruit For issues that should be easy to fix parser Issues with lexing or parsing.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants