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

Bad error message for missing parenthesis in the if condition #1427

Open
bugarela opened this issue Apr 10, 2024 · 2 comments
Open

Bad error message for missing parenthesis in the if condition #1427

bugarela opened this issue Apr 10, 2024 · 2 comments
Labels
error messages Collects issues steming from poor error messages language design Language specification

Comments

@bugarela
Copy link
Collaborator

If the if statement is inside an operator call (or probably anything), the parser loses track of the missing parenthesis error, and the reported error is almost meaningless:

module test {
  val foo = Set(1, 2).map(x => if x > 0 { 1 } else { 2 })
}
test.qnt:2:26 - error: [QNT000] extraneous input '(' expecting {'}', 'const', 'var', 'assume', 'type', 'val', 'def', 'pure', 'action', 'run', 'temporal', 'import', 'export', DOCCOMMENT}
2:   val foo = Set(1, 2).map(x => if x > 0 { 1 } else { 2 })
                            ^

test.qnt:2:47 - error: [QNT000] extraneous input 'else' expecting {<EOF>, 'module', DOCCOMMENT}
2:   val foo = Set(1, 2).map(x => if x > 0 { 1 } else { 2 })
                                                 ^^^^

error: parsing failed
@bugarela bugarela added the error messages Collects issues steming from poor error messages label Apr 10, 2024
@eras
Copy link

eras commented Apr 17, 2024

I realize this is only tangentially related, but might it be possible to get rid of the paren requirement altogether?

Rust and OCaml do it :), though OCaml has the benefit of using the then keyword. Rust doesn't need one, though.

@bugarela
Copy link
Collaborator Author

One thing to consider is that rust requires the curly braces for the blocks, while we currently don't (which I like). I think my personal preference is to use then, rather than mandating either parenthesis or curly braces.

@bugarela bugarela added the language design Language specification label Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error messages Collects issues steming from poor error messages language design Language specification
Projects
None yet
Development

No branches or pull requests

2 participants