Can i haz? Part 3: extending the Has pattern
In this post we’ll see how some algebraic considerations help us to discover one more pattern useful with
MonadError (and a
Generic implementation thereof), and we’ll also update our
Has class with one more method that brings it closer to something lens-like and makes it useful with writable environments like
Inverting the arrows
Given some structure, a true algebraist (which I’m not by any means) always wonders what happens if one turns the arrows in that struсture, obtaining a categorical dual.
In this particular case we have a single arrow
extract in the structure
Let’s invert it and prepend
You might already have an intuition about what
CoHas might be, but let’s proceed turning the arrows based on pure formalism for now.
Combine are boring and have no good applicable structure, so we leave them as is.
Search, on the other hand, is more interesting. Recall the definition we used when we built the generic implementation for
Note the next-to-last case, which mentions
f :*: g. The dual of a product is a sum, so the object dual to
Search would be:
GCoHas follows the same pattern:
And so do the instances:
instance GCoHas 'Here corecord (K1 i corecord) where gcoextract _ = K1 instance GCoHas path copart corecord => GCoHas path copart (M1 i t corecord) where gcoextract proxy = M1 . gcoextract proxy instance GCoHas path copart l => GCoHas ('L path) copart (l :+: r) where gcoextract _ = L1 . gcoextract (Proxy :: Proxy path) instance GCoHas path copart r => GCoHas ('R path) copart (l :+: r) where gcoextract _ = R1 . gcoextract (Proxy :: Proxy path)
Note that nothing happens with the position of
Proxy here, which totally makes sense:
Proxy is only used as a hint to the type checker to help deducing the right type, and it doesn’t bear any deep semantics within the structure we’re considering.
The implementation of the type class is obvious given the above:
Now let’s think about the meanings.
recordis some product type,
corecordis dual to it, so it’s some sum type. Indeed,
summight be a better name for it.
partis a field in the
copartis dual to it, so it’s one of the options in the
optionmight be a better name for it.
recordand produces a
coextract, on the other hand, takes
optionand produces a
sum. One obvious interpretation (that also follows the implementation) is that
coextractjust creates a value of the
sumtype given one of the
injectmight be a better name for it.
So, to sum it up:
CoHas option sum means that we can
inject values of type
option into the
sum type. We have
Either as a prime example:
l is not the same as
r, we can create
Either l r out of
l (and out of
r, of course) via the
CoHas class and its
Yes, we also have the same type safety and soundness guarantees: this
CoHas option sum is derivable (via
Generics) iff there is one and only one way to construct
sum set to the
option. So, for example, the following won’t work:
CoHas be useful? One might consider
MonadReader r m, Has FooEnv r to denote that the environment
r contains a value of type
FooEnv. Similarly we might write
MonadError e m, CoHas FooErr e to denote that the error context could be used to report about errors of type
This again might help modularity: assume our good old modules we considered earlier (the DB layer, the web server and the cron scheduler) might each report an error of their own type. Then we could have an application-level error type
that could be used to collect errors from all of the components, just as we used
AppConfig to provide the configuration for all of the components at once.
Bottom line: using purely algebraic considerations, we arrived at yet another useful (and free, in a sense) generalization of our approach!
Alright, back to the
We’ve learned how to extract the values of some type
part out of a
record containing them. What else can we do?
Let’s say we have a function
f :: part -> part. Then we can obtain a function transforming
records “for free”, merely by applying
f to the
part contained in the
If you’re familiar with the concept of the lenses, you’ve quite likely noticed that
update paired with
extract essentially allows defining one’s own lenses, and this is not a coincidence, but we will not delve too deep into that.
Anyway, after all our exercises with
coextract the generic code for
update is a routine.
First we add the
gupdate method to the
GHas helper class. The only real difference is that we get the generic representation back as opposed to a “real” type for
Then we add the implementation of
gupdate to the instances of
GHas we already had, keeping in mind we should produce the appropriate
instance GHas 'Here rec (K1 i rec) where ... gupdate _ f (K1 x) = K1 $ f x instance GHas path part record => GHas path part (M1 i t record) where ... gupdate proxy f (M1 x) = M1 (gupdate proxy f x) instance GHas path part l => GHas ('L path) part (l :*: r) where ... gupdate _ f (l :*: r) = gupdate (Proxy :: Proxy path) f l :*: r instance GHas path part r => GHas ('R path) part (l :*: r) where ... gupdate _ f (l :*: r) = l :*: gupdate (Proxy :: Proxy path) f r
Our final step is to add the corresponding
update method to
Has and write a default implementation for it:
And that’s it! Easy-peasy.
extract has a nice use with
MonadReader: we replace
MonadReader Foo m with
(MonadReader r m, Has Foo r) and use
extract appropriately in the bodies of the corresponding functions. What uses does
Not much with
MonadReader, but there is a very similar monad that supports modifications:
MonadState. So, now instead of
MonadState FooState m we also write
(MonadState s m, Has FooState s), obtaining nice composable and reusable stateful functions!
What we’ve achieved is basically a generalizaton of the
Has pattern to writable environments!
It’s also tempting to reverse the arrows once again and seeing what happens with
update, but that requires some less trivial math, so we’ll leave that out for another post. Stay tuned!