Re: Proposal: Add Applicative (and Monoid) instances in GHC.Generics
In response to each of your proposals:
1. Add an instance (Monoid c => Applicative (K1 i c))
This seems like a no-brainer to me. +1
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
I'm weakly -1 on this. I don't think GHC.Generics should be a place where we collect combinators for generically implementing various type class methods. I'd prefer that these be left to downstream libraries, especially since they're usually extremely straightforward to implement and wouldn't cross the Fairbairn threshold for me.
3. Add Monoid instances
I think I support this idea. But just to be sure we're on the same page: can you say which instances in particular you're adding, and how you'd implement them? Ryan S.
For helpers see `semigroups` package, Data.Semigroup.Generic module [1] I indeed don't see strong argument for moving them into `base`, only if we want to provide default `Generic` implementations for `Semigroup` & `Monoid`. I'm not sure we do? Oleg [1] http://hackage.haskell.org/package/semigroups-0.18.4/docs/Data-Semigroup-Gen... On 21.02.2018 20:16, Ryan Scott wrote:
In response to each of your proposals:
1. Add an instance (Monoid c => Applicative (K1 i c)) This seems like a no-brainer to me. +1
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 I'm weakly -1 on this. I don't think GHC.Generics should be a place where we collect combinators for generically implementing various type class methods. I'd prefer that these be left to downstream libraries, especially since they're usually extremely straightforward to implement and wouldn't cross the Fairbairn threshold for me.
3. Add Monoid instances I think I support this idea. But just to be sure we're on the same page: can you say which instances in particular you're adding, and how you'd implement them?
Ryan S. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
+1 for adding the instances.
I'm fairly neutral on the helpers.
-Edward
On Wed, Feb 21, 2018 at 1:16 PM, Ryan Scott
In response to each of your proposals:
1. Add an instance (Monoid c => Applicative (K1 i c))
This seems like a no-brainer to me. +1
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
I'm weakly -1 on this. I don't think GHC.Generics should be a place where we collect combinators for generically implementing various type class methods. I'd prefer that these be left to downstream libraries, especially since they're usually extremely straightforward to implement and wouldn't cross the Fairbairn threshold for me.
3. Add Monoid instances
I think I support this idea. But just to be sure we're on the same page: can you say which instances in particular you're adding, and how you'd implement them?
Ryan S. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Thanks everyone. So there is agreement on having Applicative and Monoid instances, and on not having additional helpers for generic deriving. That's fine to me. Replying to Ryan:
3. Add Monoid instances
I think I support this idea. But just to be sure we're on the same page: can you say which instances in particular you're adding, and how you'd implement them?
The main Monoid instances would be: Monoid (f p) => Monoid (M1 i c f p) -- newtype-derived Monoid a => Monoid (K1 i a p) -- newtype-derived (Monoid (f p), Monoid (g p)) => Monoid ((f :*: g) p) -- product monoid Monoid (U1 p) -- unit-like No instance for (:+:). Now that you mention it, I'm not sure about adding Monoid instances for the type constructors involved in Generic1, they would be (all newtype-derived): Monoid p => Monoid (Par1 p) Monoid (f p) => Monoid (Rec1 f p) Monoid (f (g p)) => Monoid ((f :.: g) p) Is ther an opinion against that? I forgot to mention Semigroup instances. They would follow the same structure, and for completeness we can also have Semigroup (V1 p) This enables a more general "generic semigroup" than via Applicative. Li-yao
participants (4)
-
Edward Kmett -
Li-yao Xia -
Oleg Grenrus -
Ryan Scott