Proposal: Add Applicative (and Monoid) instances in GHC.Generics
Li-yao Xia
lysxia at gmail.com
Tue Feb 20 23:51:26 UTC 2018
I propose to implement Applicative (and Monoid) instances in
GHC.Generics, where possible.
Note that we already have Applicative instances for most of those types,
with the notable exceptions of sums (:+:) (for good reason), and K1
(which is basically Const).
This would make it possible to easily derive Applicative and Monoid for
generic product types. That can be useful to merge large configuration
records, for example.
For that purpose, the missing Applicative instance for K1 is the actual
limiting factor, as it is sufficient in order to derive the product
Monoid and Applicative via Generic and Generic1, respectively. The
Monoid instances for the GHC.Generics constructors might just be fluff
on top of this.
Current alternatives include: roll your own, semigroups [1], or some
generic programming library (e.g., one-liner). This proposal offers a
more lightweight solution.
To summarize, and to organize bikeshedding, I would split this proposal
in three parts, in order of perceived usefulness:
1. Add an instance (Monoid c => Applicative (K1 i c))
2. Add helpers
gmempty :: (Generic a, Applicative (Rep a)) => a
gmempty = to (pure ())
gmappend :: (Generic a, Applicative (Rep a)) => a -> a -> a
gmappend a b = to (from a <*> from b)
-- also gpure, gap for generic Applicative
3. Add Monoid instances
Regards,
Li-yao
[1]
https://hackage.haskell.org/package/semigroups-0.18.4/docs/Data-Semigroup-Generic.html
More information about the Libraries
mailing list