Icelandjack
Icelandjack
I haven't tested it much, and the name is up for grabs
It makes sense to add a newtype separate from *base*. `Generically1` doesn't have a configuration parameter anyway. An 'off-topic' question is how parameters should be handled and what your thoughts...
For this ticket we just need to add a single newtype that specifies the `Rep` type. Obviously that only works when the generic representation lines up: eventually users will want...
A similar issue affects `Co` as well. For example, we can only derive `Comonad` when `Rep` is a monoid ```haskell instance (Representable f, Monoid (Rep f)) => Comonad (Co f)...
I don't think a class should decide between implementation and representation, these issues would be solved with the concept of a backend: [Type class backend: how to evolve with class](https://www.reddit.com/r/haskell/comments/pqhivm/type_class_backend_how_to_evolve_with_class/)
That's reasonable, but I wanted to put it out there for posterity
Or some hypothetical `Bipointed`, `Bicopointed`.
If this looks okay I should probably add for `Contravariant` as well.
Does a FD make a difference ```haskell class (Representable f, Rep f ~ rep) => RepresentableOf rep f | f -> rep instance (Representable f, Rep f ~ rep) =>...
You mention the type class `Ixed` with a `Lens`, this page on the wiki [*Varying lens properties by instance*](https://github.com/ekmett/lens/wiki/Varying-lens-properties-by-instance) shows a funny approach ```haskell class Ixed_ xs where type IxedConstraint_...