Updates for 0.12

[garyb]

No description provided.

[hdgarrood]

Are we not doing #23 then?

[garyb]

I think not for now - it's a nice to have rather than something that is a common problem, and needs quite a bit of library rearrangement to work (functors having to move above bifunctor).

I'm still not really pro-Functor1 either - the quantified constraint version I'd be fine with with rmap = map if we really wanted to keep that function though (another reason to prefer map at the moment is it's more efficient since it's not implemented via dimap or bimap).

[hdgarrood]

Ah ok, I see. It seems a little odd to me to object to Functor1 given that we have eg Eq1, Ord1, already, though; is there something which is different about Functor1?

[garyb]

Eq1 is required for some instances to be usable (like Eq for Free) or for some types to have Eq at all (Mu), but Functor1 doesn't give us anything that isn't already covered by Functor , aside from the ability to use it as a superclass of Bifunctor and Profunctor.

I could be wrong about the second part of that though... I'm perhaps not imaginative enough to come up with something like either of those Eq1 cases I mentioned 😄. I see your point though, perhaps it's just bias on my part because I know places I needed Eq1 so can see past the gross-ness of its necessity.