Stream: beginners

Topic: error messages when pattern matching on a function


view this post on Zulip Jeffrey Mudge (Feb 02 2025 at 22:35):

May I suggest a change to the when pattern matching error messages to aid beginners?

For example in the basic cli when Stdin.line! has not been given ({}) and the programmer tries to pattern match on the "input". I spent longer than I'd like to admit banging my head against errors like this:

This input value is a:

    {} => Result Str [
        EndOfFile,
        StdinErr [
            AlreadyExists,
            BrokenPipe,
            Interrupted,
            NotFound,
            Other Str,
            OutOfMemory,
            PermissionDenied,
            Unsupported,
        ],
    ]

But the branch patterns have type:

    [
        Err *,
        Ok *,
    ]

The branches must be cases of the when condition's type!

I realize that a more experienced programmer would immediately recognize that unit on the left side of the function arrow, but as a relative newcomer it wasn't clicking.

Could an "it looks like you are trying to" style message be added when that happens? Right now, the error message's final line is correct, but misleading and led me to spend a long time trying to change my when statement branches, even though they were fine for dealing with the Result, I just wasn't pattern matching on the Result because I didn't realize that I had to give the Stdin a {}.

There may be good reasons why someone would want to pattern match the function itself in the when statement, but I expect people doing that won't have any issue reading these error messages, where as those doing it by accident, intending to work on a Result, are more likely to struggle. Anyways, just an idea where a beginner might get tripped up that a different error message could quickly resolve.

view this post on Zulip Sam Mohr (Feb 02 2025 at 22:55):

We can definitely say in the compiler that if one of the types is a function and the other is a value, print a message saying "did you forget to call that function?"

view this post on Zulip Sam Mohr (Feb 02 2025 at 22:55):

That would be a good addition

view this post on Zulip Sam Mohr (Feb 02 2025 at 22:56):

Could you help out in making a GitHub issue? Then we can throw this at someone who wants to start contributing! https://github.com/roc-lang/roc/issues/new?template=Blank+issue

view this post on Zulip Jeffrey Mudge (Feb 02 2025 at 23:03):

Sure. Here you go: https://github.com/roc-lang/roc/issues/7570 Thanks!

view this post on Zulip Jeffrey Mudge (Feb 02 2025 at 23:05):

I do think that might still be confusing, since it looks to a novice like they've called it and are operating on a result. Since not all languages require an argument to all functions, I think an additional comment about that might be helpful if the type is {} => ...

view this post on Zulip Sam Mohr (Feb 02 2025 at 23:16):

That makes sense. Feel free to extend the issue you created with that info

view this post on Zulip Sam Mohr (Feb 02 2025 at 23:17):

For context, we just decided to rewrite the compiler in Zig, so this will need to be kept around for a few months while we do that rewrite first

view this post on Zulip Sam Mohr (Feb 02 2025 at 23:18):

Because if we implement this now in the current compiler impl, it could get lost in the rewrite, though of course we'd hope that wouldn't happen


Last updated: Jul 05 2025 at 12:14 UTC