can-i-haz: Generic implementation of the Has and CoHas patterns

[ bsd3, control, library ] [ Propose Tags ] [ Report a vulnerability ]

Please see the README on GitHub at https://github.com/0xd34df00d/can-i-haz#readme


[Skip to Readme]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1.0.0, 0.1.0.1, 0.2.0.0, 0.2.0.1, 0.2.1.0, 0.3.0.0, 0.3.1.0, 0.3.1.1
Change log ChangeLog.md
Dependencies base (>=4.7 && <5) [details]
License BSD-3-Clause
Copyright 2019 Georg Rudoy
Author Georg Rudoy
Maintainer 0xd34df00d@gmail.com
Category Control
Home page https://github.com/0xd34df00d/can-i-haz#readme
Bug tracker https://github.com/0xd34df00d/can-i-haz/issues
Source repo head: git clone https://github.com/0xd34df00d/can-i-haz
Uploaded by 0xd34df00d at 2019-10-11T01:34:43Z
Distributions LTSHaskell:0.3.1.1, NixOS:0.3.1.1, Stackage:0.3.1.1
Reverse Dependencies 1 direct, 0 indirect [details]
Downloads 3173 total (19 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2019-10-11 [all 1 reports]

Readme for can-i-haz-0.2.0.1

[back to package description]

can-i-haz

Build Status Hackage Stackage LTS Stackage Nightly

Generic implementation of the Has-pattern (mostly useful with MonadReader).

Motivation

Assume there are two types representing the MonadReader environments for different parts of an app:

data DbConfig = DbConfig { .. }
data WebConfig = WebConfig { .. }

as well as a single type containing both of those:

data AppEnv = AppEnv
  { dbConfig :: DbConfig
  , webConfig :: WebConfig
  }

What should be the MonadReader constraint of the DB module and web module respectively?

  1. It could be MonadReader AppEnv m for both, introducing unnecessary coupling.
  2. Or it could be MonadReader DbConfig m for the DB module and MonadReader WebConfig m for the web module respectively, but combining them becomes a pain.

Or, it could be MonadReader r m, Has DbConfig r for the DB module, where Has class allows projecting DbConfig out of some r, and similarly for the web module! This approach keeps both modules decoupled, while allowing using them in the same monad stack.

The only downside is that now one has to define the Has class and write tediuos instances for the AppEnv type (and potentially other types in case of tests).

The solution

This library saves you from this unnecessary boilerplate! The only thing you have to do is to append the deriving-clause:

data AppEnv = AppEnv
  { dbConfig :: DbConfig
  , webConfig :: WebConfig
  } deriving (Generic, Has DbConfig, Has WebConfig)

and use ask extract instead of ask (but this is something you'd have to do anyway).

Reversing the arrows: CoHas

There is a dual (but arguably less frequent) problem of combining different parts of an application living in different MonadError environments. The duality is due to us now wanting to inject values of a type into a "wider" sum type (as opposed to projecting values out of some product type). The CoHas class serves exactly this purpose.

Documentation

Perhaps the best source is the Haddock docs.

Acknowledgements

Thanks lyxia @ #haskell for the type families-based derivation of the GHas instance.