-
Notifications
You must be signed in to change notification settings - Fork 10
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
Unusual syntax for tuple patterns #192
Comments
@alicelogos Thanks a lot for spotting this inconsistency! I believe, this problem is unintentional, just slipped past me somehow (I think, it was because we only tested with 3-tuples). The
There are other possible fixes, but I think the one above might be the simplest. Would you be interested in making a PR with a fix along these lines? |
Thank you for clarifying. I believe you mean the following fix:
This approach doesn’t introduce new types or constructors, so no changes are needed in the Haskell code. I tested this fix with the example code I provided earlier and it works. However, I’m not familiar with the full codebase, so I’m unsure if other code need modification or if this fix is the optimal solution. If you think this fix is good, I’m happy to create a pull request with it. Additionally, I want to mention the error message Rzk without the fix reports on
And the error message Rzk with the fix reports on
These messages don’t provide hints about the reason of the syntax error or possible fixes. When I encountered a syntax error with something like I suspect that this lack of clarity in error messages might be related to Emily’s report on a “weird error message” in #141, though I’m not sure because I don’t know the exact error message Emily encountered. (The message “expected a pattern” was different with what I encountered, but I think was more informative than what I encountered.)
I’m not familiar with BNFC, so I’m unsure if adding hints should be addressed there or within Rzk. I understand that implementing better hints may require significant effort and isn’t critical since users can refer to |
Excellent! Too bad I haven't thought of this myself :) Your PR is most welcome, of course!
This is very true. I do not think that BNFC (at least in its current form) facilitates good error messages. I also think that at the grammar level we actually might not want to split expressions and patterns. Keeping expressions and patterns as one syntactic group, BNFC has more chances to parse user's input without issues and we then have the opportunity to produce a nicer error message when going from such loose syntax to something more strict. Basically, the idea is to parse "preterms" (with a high chance of successful parsing) and check well-formedness when converting into more strict terms (or directly into the scope-safe AST). If conversion fails, we can give a much better response to the user compared to a stock parser generator.
I think better error messages and localization is in fact critical to the usability of the tool (alongside performance and feature set). Also, I wouldn't want (regular) users to go to However, as you say, for the prototype (which Rzk still is), this was of low priority due to extra effort in the implementation. Still, thanks to @aabounegm we were able to hook VS Code extension to at least try to highlight exactly the correct places in the code the error messages we get. That said, a future rewrite of Rzk should definitely have better error message support in mind, since there are tons of nuances to hit, especially for beginners. |
The current syntax for tuple patterns is defined as follows in Syntax.cf:
The next line defines the separator for patterns:
As a result, tuple patterns are written like
(a , b , c d e)
. In my opinion, this syntax is unusual and potentially confusing.(a, b, c, d, e)
or(a , b , c , d , e)
.I would prefer a syntax where the elements are consistently separated by commas, such as
(a , b , c , d , e)
.I couldn’t find any discussion in #183 justifying the current design choice. Could you provide a rationale for this design choice? Alternatively, would you consider revising the syntax?
Example code:
Using the current syntax, the following code type-checks successfully:
Using the proposed syntax, however, results in a syntax error at
( a , b , c , d , e)
:The text was updated successfully, but these errors were encountered: