Closed sjoerdvisscher closed 7 years ago
While this is morally correct, Representable
forces users to commit to a specific Rep
, which becomes part of their public API. They may not be ready to do that yet.
Also note that the annoyance of the GHC.Generics
representation types not having Distributive
instances will be resolved in the next version of distributive
(which reminds me, I should try and push out a new release sometime soon...)
Those (aside from sums, of course) should also have reasonable Representable instances. The most obvious thing would be
instance (Representable f, Representable f) => Representable (f :: g) where type Rep (f :: g) = Either (Rep f) (Rep g) index (fa :: ) (Left x) = index fa x index ( :: ga) (Right y) = index ga y
but I fear the type family may loop when deriving the instance for an infinite stream.
On Nov 29, 2016 7:28 PM, "Ryan Scott" notifications@github.com wrote:
Also note that the annoyance of the GHC.Generics representation types not having Distributive instances will be resolved in the next version of distributive (which reminds me, I should try and push out a new release sometime soon...)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ekmett/adjunctions/pull/13#issuecomment-263745184, or mute the thread https://github.com/notifications/unsubscribe-auth/ABzi_eAjZ4-A16JSzmO-_VtBNviGk6d2ks5rDMMVgaJpZM4EDvEY .
distributive-0.5.1
has been released, which includes Distributive
instances for the datatypes in GHC.Generics
.
I think we should drop the
Distributive
superclass constraint, and make it just Functor.Any code that needs
distribute
givenRepresentable f
can just usedistributeRep
, and get no performance penalty, because indexing under fmap and then tabulating is the only way to implementdistribute
anyway.So the
Distributive
superclass constraint is just an annoyance. Removing it will also make it easier to merge the TH and Generics pull requests by @bgamari.