`Pattern match(es) are non-exhaustive` error

[RobertFischer]

I am getting errors like this when I am using the pgSQL quasiquoter.

      INSERT INTO milestone_tasks (milestone_id,task_id)
      VALUES
      ( (SELECT ms.id FROM milestones ms WHERE ms.external_id = ${msId})
      , (SELECT t.id FROM tasks t WHERE t.external_id = ${taskId})
      )
      ON CONFLICT DO NOTHING

        Pattern match(es) are non-exhaustive
        In a lambda abstraction: Patterns not matched: _ (_:_)

      SELECT t.external_id
      FROM tasks t
      INNER JOIN milestone_tasks mt ON (mt.task_id = t.id)
      INNER JOIN milestones m ON (m.id = mt.milestone_id)
      WHERE m.external_id = ${msId}
      ORDER BY mt.ordering ASC

        Pattern match(es) are non-exhaustive
        In a lambda abstraction:
            Patterns not matched:
                _ []
                _ (_:_:_)

Any idea why this is being caused, or how to address it?

[dylex]

These are normally warnings, and even then often turned on, so I presume you're compiling with -Wall -Werror or similar. They should be safe to ignore (they're matching the result columns coming back from the database, so should always be the right number). Just to avoid the warning, I've switched these matches to be irrefutable, which should be safe.

[RobertFischer]

It's part of -Wall, and I'm generally pretty sensitive to those particular errors, because it usually implies that I've changed a type that I've got a case statement over, so I need to handle a new case. Unfortunately, GHC doesn't give me a way to disable warnings for only part of a file. :(

Thanks for the change. I appreciate it!

[RobertFischer]

Still seeing this, even though I should be using your updated library. This is the relevant part of my stack.yaml:

flags: {}
extra-package-dbs: []
packages:
- .
extra-deps:
- git: git@github.com:dylex/postgresql-typed.git
  commit: 734f8742f387bc8cc29d287fae72d8362d872007

compiler-check: newer-minor
resolver: lts-11.5
require-stack-version: ! '>=1.6'

flags:
    postgresql-binary:
        hdbc: false

But I'm still getting lots of warnings like these when -Wincomplete-uni-patterns is turned on:

        Pattern match(es) are non-exhaustive
        In a pattern binding:
            Patterns not matched:
                []
                (_:_:_)
        |
    471 |     qry id = [pgSQL|$ SELECT video_id FROM vimeo_sections WHERE id = ${id} |]

[RobertFischer]

Yup. Just confirmed in my ./.stack-work folder that the TH.TildeP addition on line 216 is there. So I am, in fact, using that code.

[dylex]

Ah, there's probably another one. Sorry was only looking in lambdas since that's what the original error was. I'll check. You can also build with -ddump-splices if you want to see the generated code.

[dylex]

Or maybe I'm wrong about the tilde semantics with the new warnings in ghc 8.2. Do you actually have -Weverything on, which includes -Wincomplete-uni-patterns? You could add -Wno-incomplete-uni-patterns but I'll try to find a way to avoid it.

[RobertFischer]

I run with -Wincomplete-uni-patterns, but I'm disabling it on the files where I'm using postgresql-typed.

[dylex]

That explains why I haven't noticed this before, since it's not part of -Wall. I think I just have to restructure the code not to use a lambda at all to avoid triggering incomplete-uni-patterns.

[RobertFischer]

Really? Wow. I didn't realize that was going to be so involved!

On Tue, Apr 17, 2018, 17:58 Dylan Simon notifications@github.com wrote:

That explains why I haven't noticed this before, since it's not part of -Wall. I think I just have to restructure the code not to use a lambda at all to avoid triggering incomplete-uni-patterns.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dylex/postgresql-typed/issues/13#issuecomment-382167786, or mute the thread https://github.com/notifications/unsubscribe-auth/AABO1_jxmJNZeK_vfaSeuRdcDDJ1S-skks5tpmV9gaJpZM4TT6ar .

[dylex]

It's not really that involved, it's just in template haskell so it's a bit verbose. But basically there's some code like (\[x,y] -> ...) <$> ... generated for every query for which you want to avoid the incomplete-uni-patterns warning. The only option I see is to turn it into (\l -> case l of { [x,y] -> ... ; _ -> error }) <$> .... If there's an easier option I'm missing that'd be great.

[RobertFischer]

Can you use LambdaCase? That's kinda what it's there for, but I don't know TH at all, so I don't know if that kind of syntactic sugar translates.

Short of that, the other trick I'll often do is to use zip, which truncates lists to the shorter of the two lists.

Tuples are really a pain in the butt here in general. It almost makes me think that what we really want is an HList....

~~ RCF.

Dylan Simon:

It's not really that involved, it's just in template haskell so it's a bit verbose. But basically there's some code like (\[x,y] -> ...) <$> ... generated for every query for which you want to avoid the incomplete-uni-patterns warning. The only option I see is to turn it into (\l -> case l of { [x,y] -> ... ; _ -> error }) <$> .... If there's an easier option I'm missing that'd be great.

[dylex]

Okay, that should do it.

I have consider HLists for this, but they seem like overkill. Regardless, they wouldn't solve this problem because at some point you have to unpack the untyped results coming from the database over the network into typed values.

[RobertFischer]

Wow. Thank you very much!