WIP: Group heirarchy

[endgame]

Add InverseSemigroup above Group, and RegularSemigroup above that.

There are a few things that I think need resolving before this gets merged:

1. Is there enough of a use for the superclasses to justify making everyone else write two extra instances to get to Group? The main one I was toying with was (borrowing some bits from semialign):

newtype Pointwise f a = Pointwise (f a)

instance (Semialign f, Semigroup a) => Semigroup (Pointwise f a) where
  (Pointwise fa) <> (Pointwise fb) = salign fa fb

instance (Semialign f, RegularSemigroup a) => RegularSemigroup (Pointwise f a) where
  inv (Pointwise fa) = Pointwise (inv <$> fa)

And then using this to compute diffs. But it didn't pay out into anything ergonomic. I probably need to think more about whether this should be done with Zip or Semialign.

Ed mentioned:

I'm currently poking at the use of inverse semigroups to better model something like the underlying theory for "nominal renaming sets" and if not if i can use the pattern from nominal sets for other inverse semigroups i happen to be interested in that i'd like to be able to act on sets with.

(Did this pay out?)

2. Should the inverse operation be called inv, or something else? (Bikeshedding)

3. If pseudoinverses in RegularSemigroup are not unique, should there be a function invs :: g -> NonEmpty g, with no guarantee that it returns every pseudoinverse (too expensive to calculate otherwise)?

4. Where should pow sit in the hierarchy? If you have unique inverses (InverseSemigroup) you can compute sensible pow for any nonzero integer power, but zero would have to be x <> inv x or inv x <> x, and I don't think you have a guarantee that those are the same.

[Taneb]

I'm going to leave question 1 open for the time being.

2: 🤷‍♀️ I'm happy with inv.

3: I don't think invs with that type really gains us much, although I'd be open to including it if we can come up with a use case (comes under the same header as 1)

4: I don't really like saying "Don't pass 0 as the argument to this function" when we're in an additive world. (pow a x <> pow a y == pow a (x + y)) so I would prefer that to continue to live in Group

[endgame]

Re: 1. I think we hold the PR until we have a good usecase.

Re: 2. OK, this give a good deprecation pathway for invert: release once with inv and deprecated invert, then remove invert in a future release.

Re: 3. Agreed.

Re: 4. Agreed.

[ekmett]

I don't have firm opinions here.

That said, pseudo-inverses are not necessarily countable, so giving back a list of them seems a doomed endeavor; at best you can get isPseudoInverse :: a -> a -> Bool

[Taneb]

@endgame thinking about it (and double-checking what the existing is), I'd rather keep the current name, invert.

[endgame]

OK, pushed.