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

Remove unneeded parenthesis from type printing #202

Open
jfecher opened this issue Aug 11, 2024 · 0 comments
Open

Remove unneeded parenthesis from type printing #202

jfecher opened this issue Aug 11, 2024 · 0 comments
Labels
error reporting For issues related to error message quality or the reporting of diagnostics in general good first issue An issue that doesn't require deep knowledge of the compiler to fix or implement

Comments

@jfecher
Copy link
Owner

jfecher commented Aug 11, 2024

Currently while displaying types we show an unnecessary amount of parenthesis. This can be seen while printing error messages.

E.g. examples/typechecking/completeness_checking.an has the following as its last error message:

completeness_checking.an:25:4	error: This pattern of type ((Int a), (Int b)) does not match the type ((Int a), ((Int b), ((Int c), (Int d)))) that is being matched on
| (1, 2) -> 1

Ideally we would display the following instead:

completeness_checking.an:25:4	error: This pattern of type (Int a, Int b) does not match the type (Int a, (Int b, (Int c, Int d))) that is being matched on
| (1, 2) -> 1

Or even the following since , is right-associative:

completeness_checking.an:25:4	error: This pattern of type Int a, Int b does not match the type Int a, Int b, Int c, Int d that is being matched on
| (1, 2) -> 1

The file to change for this issue would be src/types/typeprinter.rs. I imagine instead of always parenthesizing certain types we'll want to never do so on the type itself, and only parenthesize on certain argument positions. Either by checking the type variant or a check like !type_string.contains_spaces().

@jfecher jfecher added good first issue An issue that doesn't require deep knowledge of the compiler to fix or implement error reporting For issues related to error message quality or the reporting of diagnostics in general labels Aug 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error reporting For issues related to error message quality or the reporting of diagnostics in general good first issue An issue that doesn't require deep knowledge of the compiler to fix or implement
Projects
None yet
Development

No branches or pull requests

1 participant