[Add] Reasoning combinator for semigroup

[jmougeot]

Introduce a new module for equational reasoning in semigroups, providing utilities for associativity reasoning and operations.

[JacquesCarette]

For others: the names are taken from the combinators in agda-categories. Those were inherited from older versions of that library. I do not like them! So please do suggest better ones.

[jamesmckinna]

Introduce a new module for equational reasoning in semigroups, providing utilities for associativity reasoning and operations.

With an explicit callback/reference to #2288 ? This PR alone doesn't 'fix' that issue, but contributes a piece of the jigsaw to such a 'fix'.

[jamesmckinna]

Lots of comments, I'm requesting changes based on a single one, but can be summarised as:

• please give lemmas names that can be remembered without needing a lookup table or other instruction manual to explain what they are/how they behave!
• no need for a new module, we already have the Algebra.Properties.* sub-hierarchy...

[jamesmckinna]

Elsewhere, the library would use lemma names of the form p∧q⇒r, with square brackets for grouping sub-terms, so here:

module Pulls (x∙y≈z : x ∙ y ≈ z) where
  x∙y≈z⇒[w∙x]∙y≈w∙z : (w ∙ x) ∙ y ≈ w ∙ z

NB. also: you have declared x as a variable, so there's no need to have the quantifier! Although here again, we have the problem that in any deployment in a concrete Semigroup the typechecker might not be able to infer w... so there are questions about how the quantifications should be handled.

If you can find examples in eg Data.Rational.Properties which might be simplified by these lemmas, then you might discover whether Agda can (or not) infer the various implicits?

[jamesmckinna]

Also, the use of ⇒ in the lemma names would avoid the need for the submodules here to be named; they could (more) simply be anonymous module _ (hyps) where...

[JacquesCarette]

While x∙y≈z⇒[w∙x]∙y≈w∙z is a logical name, it is also quite long. As these combinators that re-associate are book-keeping things, I'd like to find something shorter / less noisy.

I do hate push/pull. I'm partial to on-right.

[jamesmckinna]

Well, with my suggested notational optimisations, this would/could become...xy≈z⇒wx∙y≈wz, which is about as short as I can make it?!

[jamesmckinna]

As for on-right I'm really not sure what that is supposed to signify, given that the lemma is not cong like, nor is the action obviously happening on the right? (Never mind our ongoing debates about left/right distinctions giving rise to confusion...)

[JacquesCarette]

on-right as in apply this equality on the right, after a re-focus. It's very much cong-like to me, it just has a re-association done first, to put "the right" in focus.

[jamesmckinna]

Indentation is by 2 spaces, not 4 as you have here... see style-guide.

Suggested change

	using (Carrier; _∙_; _≈_; setoid; trans ; refl; sym; assoc; ∙-cong)
	using (Carrier; _∙_; _≈_; setoid; trans ; refl; sym; assoc; ∙-cong; ∙-congˡ; ∙-congʳ)

[jamesmckinna]

Successive appeals to sym suggest that it should be lifted out (permutation of sym through proofs), but in fact doing so quickly reveals the following:

Suggested change

	pushʳ {x = x} = begin
	x ∙ c ≈⟨ sym (∙-cong refl ab≡c) ⟩
	x ∙ (a ∙ b) ≈⟨ sym (assoc x a b) ⟩
	(x ∙ a) ∙ b ∎
	pushʳ = sym (pullʳ ab≡c)

[jamesmckinna]

OK... thanks for the recent commits, but I'm going to carry on nitpicking:

• the Assoc4 proofs miss lots of symmetry, with 5 'independent' lemmas each with their symmetric counterpart, and since Reasoning.Setoid does have the syntax for applying the symmetric equivalent of an equation, we maybe don't even need the 5 equivalents...
  • u∙[[v∙w]∙x]≈[[u∙v]∙w]∙x = sym [[u∙v]∙w]∙x≈u∙[[v∙w]∙x]
  • u∙[v∙[w∙x]]≈[[u∙v]∙w]∙x = sym [[u∙v]∙w]∙x≈u∙[v∙[w∙x]]
  • [u∙v]∙[w∙x]≈[u∙[v∙w]]∙x = sym [u∙[v∙w]]∙x≈[u∙v]∙[w∙x]
  • u∙[v∙[w∙x]]≈[u∙[v∙w]]∙x = sym [u∙[v∙w]]∙x≈u∙[v∙[w∙x]]
  • u∙[v∙w]]∙x]≈[u∙v]∙[w∙x] = sym [u∙v]∙[w∙x]≈u∙[[v∙w]]∙x]
    where this last one, [u∙v]∙[w∙x]≈u∙[[v∙w]]∙x] is defined as a step-by-step proof, rather than the others, just defined in terms of trans, so could instead consider
  • [u∙v]∙[w∙x]≈u∙[[v∙w]]∙x] = trans (assoc u v (w ∙ x)) (sym (∙-congˡ (assoc v w x)))
• similarly, while the Pushes are symmetric equivalents of something in Pulls, not all the Pulls have their counterparts... but as above, maybe (probably) we don't even need the Pushes at all...
• the square brackets do improve things, I think, but you've overdone them, as there's no need to have each innermost group neither bracketed, nor mention the operation explicitly, cf. x∙yz≈xy∙z, so I should apologise for not expressing my suggestion clearly enough (or else falling into the same trap myself!), so eg. [[u∙v]∙w]∙x≈u∙[[v∙w]∙x] could be simplified to [uv∙w]∙x≈u∙[vw∙x] and that would be, I think, much more readable (with less ink!). Or even [[uv]w]x≈u[[vw]x] but that exchanges one character for two, so is perhaps suboptimal. Etc.

[jamesmckinna]

Also:

Introduce a new module for equational reasoning in semigroups, providing utilities for associativity reasoning and operations.

As with previous comments, we don't need a new module (even if it's moved location), these could all go in Algebra.Properties.Semigroup, and should, I think (another instance of Occam's Eraser: don't multiply modules unnecessarily)

[JacquesCarette]

The strong reason to have push/pull defined before these is that they can be used here. You should indeed move those up above Assoc4 and refactor the proofs here to use push/pull.

[JacquesCarette]

The 'new' names in Assoc4 are better. The rest are hideous and make things quite unreadable. It was a nice experiment... which I would call a clear failure. I most definitely prefer push/pull over these.

[jamesmckinna]

The 'new' names in Assoc4 are better. The rest are hideous and make things quite unreadable. It was a nice experiment... which I would call a clear failure. I most definitely prefer push/pull over these.

Again, agree to disagree. No 'clear' failure on my side, but happy to try to find a good outcome to the naming discussion.

[jamesmckinna]

Placeholder review: this will have to wait until at least the weekend before I can return to it.
But I think in the meantime there still seem to be spacing issues, the existing question of where these things should live, as well as those regarding whether explicitly-named proofs of 'symmetric' versions are really necessary.