generic-match: First class pattern matching

[ data, library, mit ] [ Propose Tags ]

First class pattern matching.

[Skip to Readme]
Versions [faq],,,,
Change log
Dependencies base (>=4.12 && <4.15) [details]
License MIT
Copyright 2020 Samuel Schlesinger
Author Samuel Schlesinger
Category Data
Source repo head: git clone
Uploaded by sgschlesinger at 2020-08-24T02:33:29Z
Distributions NixOS:
Downloads 270 total (6 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Hackage Matrix CI
Docs available [build log]
Last success reported on 2020-08-24 [all 1 reports]


[Index] [Quick Jump]


Maintainer's Corner

For package maintainers and hackage trustees

Readme for generic-match-

[back to package description]


When I'm writing Haskell code, often I write things like:

x <- doThing >>= either errorHandler pure
y <- doOtherThing >>= maybe (throwIO Shriek) pure

This comes up in more places than error handling, but I think this is a sufficient example. There is a compromise one makes with their API, where they either offer a specific error type, and force you to deconstruct it and fiddle with it on your own, but usually the names are more descriptive. On the other hand, with Either or Maybe, we can use all of the standard functions available for operating on them, such as either and maybe. This package is getting rid of the cost of entry for deconstructing your own types in this same style. Now we can write:

data DatabaseAccess a =
    ConnectionFailure String
  | InvalidRowCount Int
  | Successful a
  deriving Generic
x <- doThing >>= \g -> match g error (error . show) pure

This is the motivating case, but there are many others! For instance, you can also replace your use of either and maybe with the more "Generic" (heh) match.

x <- doThing >>= \g -> match g errorHandler pure
y <- doOtherThing >>= \g -> match g (throwIO Shriek) pure