Stream: beginners

Topic: ✔ Error in pattern matching a tuple

Hristo (Apr 05 2024 at 20:14):

Apologies in advance about the not very good context!

The following file (PatternMatch.roc in the second code block below) is supposed to be a minimum reproducible example (it's practically an equivalent code excerpt of what I'm currently prototyping as part of a larger use-case) of this error:

── TYPE MISMATCH in PatternMatchError.roc ───────────────────────────────────────

The branches of this when expression don't match the condition:

101│>      when List.get ranges 0 is
102│           OK range ->
103│               if range == (0, List.len result) then
104│                   []
105│               else
106│                   result
107│           Err OutOfBounds ->
108│               []

The when condition is:

    Result Range [OutOfBounds]

But the branch patterns have type:

    [
        Err [OutOfBounds],
        OK *,
    ]

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

────────────────────────────────────────────────────────────────────────────────

The attempt at reproducing the issue:

# PatternMatch.roc

interface PatternMatch
    exposes []
    imports []

Range : (U64, U64)

getRanges : {} -> List Range
getRanges = \{} -> [(0, 0)]

processRanges : {} -> List Range
processRanges = \{} ->
    ranges = getRanges {}
    when List.get ranges 0 is
        Ok range ->
            if range == (0, List.len ranges) then
                []
            else
                [(0, 0)]
        Err OutOfBounds ->
            []

expect
    expected = [(0, 0)]
    actual = processRanges {}
    actual == expected

However, the compiler is happy with the second code block, but complains in the first case.
I haven't been able to come up with a minimal reproducible example (as mentioned, the one which is practically equivalent passes the test OK), and was hoping I might get some pointers, even in the absence of such an example.

Thank you!

Isaac Van Doren (Apr 05 2024 at 20:16):

The first block has OK instead of Ok which should be the culprit

Isaac Van Doren (Apr 05 2024 at 20:16):

I think there was a thread about this same thing a while back but it seems like a good case for a tailored error message

Notification Bot (Apr 05 2024 at 20:17):

Hristo has marked this topic as resolved.

Hristo (Apr 05 2024 at 20:17):

Indeed, that's the case - fixed! Thank you so much!

Hristo (Apr 05 2024 at 20:19):

I think there was a thread about this same thing a while back

Yes, I think I did run into it back when I joined Roc's ZulipChat instance, when I was exploring different streams and topics. It's embarrassing that I couldn't spot it, nor remember about the topic I'd read :man_facepalming:

it seems like a good case for a tailored error message

I'm slightly biased, as I've just fallen for this trap, but I'd say it'd be definitely worth associating a more concrete error message with this class of error cases.

Richard Feldman (Apr 05 2024 at 22:03):

if anyone wants to try implementing that, I'd be happy to give pointers on how to do it!

Hristo (Apr 06 2024 at 08:18):

I'll be definitely happy to contribute along these lines at some point after I've produced an end-to-end first draft of my book chapter, if that's Ok (no pun intended :sweat_smile:).
Currently, extremely short on non-primary-job programming time, as there's been an unusual extremely busy stretch of work for about 2 months now.

Anton (Apr 06 2024 at 08:56):

I made #6630 for this.

Hristo (Apr 06 2024 at 11:32):

Would it make sense for the corresponding ticket to be a bit more general than just OK/Ok? For instance, handling also other possible capitalisation mismatches such as Err/ERR? I suppose those haven't been reported to have occurred yet, and would probably not be as common, but it might be useful to have a fuzzy similarity check along the lines of "Did you mean <one or more options> instead?", which already applies in some other Roc error cases.

Anton (Apr 06 2024 at 11:40):

Good idea! I've added a checkbox to the issue to evaluate that possibility once the specific OK<->Ok case is handled.

Hristo (Apr 06 2024 at 11:53):

Thank you!

Richard Feldman (Apr 06 2024 at 12:13):

oh yeah I was thinking of it in terms of capitalization in general :big_smile:

Richard Feldman (Apr 06 2024 at 12:14):

and for that matter we can do edit distance to suggest tag names like we do variable names in case there's a misspelling there

Hristo (Apr 06 2024 at 13:45):

Yes, that's what I meant by "fuzzy similarity check", thanks @Richard Feldman! (I hadn't checked that part of the codebase to have known how that's implemented in Roc. Perhaps "fuzzy" and "similarity" were a bit too redundant terms to have put together in this context haha :sweat_smile:)

Last updated: Jul 06 2025 at 12:14 UTC