Documentation

Instances of this class provide means to talk about constraints, both at compile-time, using AllB, and at run-time, in the form of Dict, via baddDicts.

A manual definition would look like this:

data T f = A (f Int) (f String) | B (f Bool) (f Int)

instance ConstraintsB T where
  type AllB c T = (c Int, c String, c Bool)

  baddDicts t = case t of
    A x y -> A (Pair Dict x) (Pair Dict y)
    B z w -> B (Pair Dict z) (Pair Dict w)

Now if we given a T f, we need to use the Show instance of their fields, we can use:

baddDicts :: AllB Show b => b f -> b (Dict Show Product b)

There is a default implementation of ConstraintsB for Generic types, so in practice one will simply do:

derive instance Generic (T f)
instance ConstraintsB T

Barbie-types that can be mapped over. Instances of FunctorB should satisfy the following laws:

  bmap id = id
  bmap f . bmap g = bmap (f . g)

There is a default bmap implementation for Generic types, so instances can derived automatically.

Every type b that is an instance of both ProductB and ConstraintsB can be made an instance of ProductBC as well.

Intuitively, in addition to buniq from ProductB, one can define buniqC that takes into account constraints:

buniq :: (forall a . f a) -> b f
buniqC :: AllB c b => (forall a . c a => f a) -> b f

For technical reasons, buniqC is not currently provided as a method of this class and is instead defined in terms bdicts, which is similar to baddDicts but can produce the instance dictionaries out-of-the-blue. bdicts could also be defined in terms of buniqC, so they are essentially equivalent.

bdicts :: forall c b . AllB c b => b (Dict c)
bdicts = buniqC (Dict @c)

There is a default implementation for Generic types, so instances can derived automatically.

Barbie-types that can be traversed from left to right. Instances should satisfy the following laws:

 t . btraverse f   = btraverse (t . f)  -- naturality
btraverse Identity = Identity           -- identity
btraverse (Compose . fmap g . f) = Compose . fmap (btraverse g) . btraverse f -- composition

There is a default btraverse implementation for Generic types, so instances can derived automatically.

Product types without named fields can't be addressed by field name (for very obvious reason), so we instead need to address them with their "position" index. This is a one-indexed type-applied natural:

>>> import Control.Lens ((^.))

>>> :t mempty @(HKD (Int, String) []) ^. position @1
mempty @(HKD (Int, String) []) ^. position @1 :: [Int]

As we're using the wonderful generic-lens library under the hood, we also get some beautiful error messages when things go awry:

>>> import Data.Generic.HKD.Construction
>>> deconstruct ("Hello", True) ^. position @4
...
... error:
... The type HKD
... ([Char], Bool) f does not contain a field at position 4
...

When we work with records, all the fields are named, and we can refer to them using these names. This class provides a lens from our HKD structure to any f-wrapped field.

>>> :set -XDataKinds -XDeriveGeneric -XTypeApplications
>>> import Control.Lens ((&), (.~))
>>> import Data.Monoid (Last)
>>> import GHC.Generics

>>> data User = User { name :: String, age :: Int } deriving (Generic, Show)
>>> type Partial a = HKD a Last

We can create an empty partial User and set its name to "Tom" (which, in this case, is pure "Tom" :: Last String):

>>> mempty @(Partial User) & field @"name" .~ pure "Tom"
User {name = Last {getLast = Just "Tom"}, age = Last {getLast = Nothing}}

Thanks to some generic-lens magic, we also get some pretty magical type errors! If we create a (complete) partial user:

>>> import Data.Generic.HKD.Construction (deconstruct)
>>> total = deconstruct @Last (User "Tom" 25)

... and then try to access a field that isn't there, we get a friendly message to point us in the right direction:

>>> total & field @"oops" .~ pure ()
...
... error:
... The type HKD User Last does not contain a field named 'oops'.
...