Jasper Woudenberg (Mar 10 2024 at 12:47): Jasper Woudenberg (Mar 10 2024 at 12:47):What's the best place to report error messages that might be improved? Is there a list somewhere?
I ran into a small bit of confusion when attempting to use ... in a list pattern match (three dots instead of two):
» when [1,2,3] is
… [a,b,...] -> "hi!"
── UNFINISHED LIST PATTERN ─────────────────────────────────────────────────────
I am partway through parsing a list pattern, but I got stuck here:
5│ [a,b,...] -> "hi!"
^
I was expecting to see a closing square brace before this, so try
adding a ] and see if that helps?
Maybe not super important/urgent, but it seems like the kind of mistake folks new to the language might make, and where the compiler could be more "I see what you're trying to do, here's the correct syntax in Roc".
Jasper Woudenberg (Mar 10 2024 at 12:48):Similar but related error when trying to use a pattern like ..rest:
» when [1,2,3] is
… [a,b,..rest] -> "hi!"
── UNFINISHED LIST PATTERN ─────────────────────────────────────────────────────
I am partway through parsing a list pattern, but I got stuck here:
5│ [a,b,..rest] -> "hi!"
^
I was expecting to see a closing square brace before this, so try
adding a ] and see if that helps?
GitHub issues. Though if it is a complex improvement, might be worth chatting about on zulip
Brendan Hansknecht (Mar 10 2024 at 19:43):Those definitely would be great to track and improve
Anton (Mar 11 2024 at 18:39):Tangent: there's a whole group of errors like this that require a good bit of work to improve the error message for if you "treat" each case independently. I think it would be useful to develop a tool (mostly for beginners) that compares the Roc code the user is currently writing to a database of up-to-date, high quality Roc code. It could show you several snippets of Roc that are most similar to what you are currently writing, thereby helping you prevent the whole group of beginner syntax errors.
Anton (Mar 11 2024 at 18:44):It could also alert you if for example ... or <| does not occur anywhere in the dataset.
Jasper Woudenberg (Mar 11 2024 at 19:16):Thanks, I created an issue here.
Tangent: there's a whole group of errors like this that require a good bit of work to improve the error message for if you "treat" each case independently. I think it would be useful to develop a tool (mostly for beginners) that compares the Roc code the user is currently writing to a database of up-to-date, high quality Roc code.
This sounds like it could be super useful! I do think there's a bit of a tension between this being an extra tool someone would need to install/run, and it's intended audience being beginners. Typically I imagine folks might build up their tool belt as they get more experience.
Anton (Mar 12 2024 at 09:38):True, if we ever set up an extensive Roc learning experience with exercises we could introduce the tool somewhere in the middle to prevent overwhelming people at the start.
Greg Wilson (Mar 12 2024 at 15:00):I can see the value of the tool that @Anton suggests, but I think that better/slimmer error messages should be the priority. In particular, I think what I'm seeing (as a novice) is cascading error messages: if there's a way to say, "we spotted four other problems but we think they're all related to the one we showed you first", that would be very helpful for newcomers.
Richard Feldman (Mar 12 2024 at 15:22):yeah I definitely think we should start by improving individual error messages!
Richard Feldman (Mar 12 2024 at 15:23):in this particular case, what we could do is:
TOO MANY DOTS and just explain that the syntax is 2 dots in a row Anton (Mar 12 2024 at 15:23):I think that better/slimmer error messages should be the priority.
I'd love that too, but the way I see it we can't make a few changes to our compiler frontend to achieve that.
It seems like there are hundreds of error-types, where each type requires between 1 to 30 hours of work to significantly improve the error message for. This approach would try to address every deviation from correct Roc code individually, whereas the proposed tool could help you prevent any deviation.
"we spotted four other problems but we think they're all related to the one we showed you first"
I absolutely understand that desire, it does seems like this relating of problems is one of those those things that is easy for experienced programmers but hard to put into an algorithm.
Richard Feldman (Mar 12 2024 at 15:23):in general, the most common way to make parse errors nicer is for the parser to consume things that are syntactically invalid and write down what it saw (and then keep going), because then it can give special-cased messages depending on what the problem was
Jasper Woudenberg (Mar 12 2024 at 16:58):This is probably 100x more difficult to put in practice then it is to come up with, but the think the error for my ... mistake made me think of is the nice error messages you get in Elm (and I think I've already seen them in Roc too) when you have a typo in a variable name or record field name. The kind where the error message says: "you types X, did you maybe intend to write Y?". Would be nice if that somehow worked for keywords and special syntax as well.
Anton (Mar 12 2024 at 17:52):Totally, "you typed X, did you maybe intend to write Y?" is a statistical question, which is why I think it's worth it to experiment with a statistical tool.
Last updated: Jul 26 2025 at 12:14 UTC