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_...