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

precedence of let and comma is awkward #1472

Open
cyrus- opened this issue Jan 21, 2025 · 5 comments
Open

precedence of let and comma is awkward #1472

cyrus- opened this issue Jan 21, 2025 · 5 comments
Assignees
Labels

Comments

@cyrus-
Copy link
Member

cyrus- commented Jan 21, 2025

Image

@cyrus- cyrus- self-assigned this Jan 21, 2025
@cyrus- cyrus- added the bug label Jan 21, 2025
@cyrus- cyrus- moved this to Team Editor in Hazel Big Board Jan 21, 2025
@disconcision
Copy link
Member

@cyrus- how do you feel about just moving to obligate parentheses for tuples? would address multiple issues.

@cyrus-
Copy link
Member Author

cyrus- commented Jan 21, 2025

Not sure how the error reporting will work when there aren't parens? There would still need to a parse...

@disconcision
Copy link
Member

outside parens/brackets i would think they should behave like undefined infix operators currently do; highlit in red, parsed as multihole. i think this is possible implementation wise but i might be underthinking it

@disconcision
Copy link
Member

(implementation wise i think a direct fix to this issue is also non-straightforward; i'm not actually sure this is a regression? this seems intrinsic to the way n-ary ops are currently handled)

@disconcision
Copy link
Member

actually nm this is a regression... it also breaks case expressions (if you have a bare tuple in the scrutinee)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Team Editor
Development

No branches or pull requests

2 participants