incomplete-uni-patterns

[ckoparkar]

There are a few incomplete-uni-patterns in this library. Since this warning will soon be enabled by -Wall, we should either a) use -Wno-... , or b) case+error.

(1) Data.Sequence.Internal:L3692

    Pattern match(es) are non-exhaustive
    In a pattern binding: Patterns not matched: EmptyLTree
     |
3692 |     f' ms = let ConsLTree node m' = viewLTree ms in
     |             

(2)

Data.Sequence.Internal:L3707

    Pattern match(es) are non-exhaustive
    In a pattern binding: Patterns not matched: EmptyRTree
     |
3707 |     f' ms =  let SnocRTree m' node = viewRTree ms in
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(3)

Data.IntMap.Internal:L1049

    Pattern match(es) are non-exhaustive
    In a lambda abstraction:
        Patterns not matched:
            (Bin _ _ _ _) _
            (Tip _ _) (Bin _ _ _ _)
            (Tip _ _) Nil
            Nil _
     |
1049 |   = mergeWithKey' Bin (\(Tip k1 x1) (Tip _k2 x2) -> Tip k1 (f k1 x1 x2)) id id m1 m2
     |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(4)

Data.IntMap.Internal:L1246

    Pattern match(es) are non-exhaustive
    In a lambda abstraction:
        Patterns not matched:
            (Bin _ _ _ _) _
            (Tip _ _) (Bin _ _ _ _)
            (Tip _ _) Nil
            Nil _
    |
715 |   = mergeWithKey' bin (\(Tip k1 x1) (Tip _k2 x2) -> Tip k1 $! f k1 x1 x2) (const Nil) (const Nil) m1 m2
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(5) Data.IntMap.Internal:L1292

Pattern match(es) are non-exhaustive
    In a lambda abstraction:
        Patterns not matched:
            (Bin _ _ _ _) _
            (Tip _ _) (Bin _ _ _ _)
            (Tip _ _) Nil
            Nil _
     |
1292 |         combine = \(Tip k1 x1) (Tip _k2 x2) ->
     |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

[treeowl]

Thanks for pointing these out. I would very much prefer to get rid of these altogether where possible. For example: how is performance affected if we implement intersectionWithKey using merge instead of mergeWithKey'? For Data.Sequence.{inits,tails}, I'm pretty sure it should be possible to avoid any hint of partiality. Is it worth the extra complication? How does it affect performance? Until that's been worked out, I suppose it would be best to use case and error.

[ckoparkar]

@treeowl ah, good points to keep in mind. Should we also record this comment in it's own ticket? It'll be easy to forget after these warnings are suppressed. Or we can just leave this open.