Skip to content

[Add] Consequences of associativity for Semigroups #2688

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 31 commits into
base: master
Choose a base branch
from

Conversation

jmougeot
Copy link
Contributor

@jmougeot jmougeot commented Apr 1, 2025

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

@jmougeot jmougeot changed the title Add reasoning combinator for semigroup [Add] Reasoning combinator for semigroup Apr 1, 2025
@JacquesCarette
Copy link
Contributor

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
Copy link
Contributor

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

Copy link
Contributor

@jamesmckinna jamesmckinna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines 76 to 77
module Pulls (ab≡c : a ∙ b ≈ c) where
pullʳ : ∀ {x} → (x ∙ a) ∙ b ≈ x ∙ c
Copy link
Contributor

@jamesmckinna jamesmckinna Apr 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@jamesmckinna jamesmckinna Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd tried to reply, but my comment (seems to have) got lost: if you're wedded to an ASCII/prefix-Lisp name for these things, then I'd much prefer refocus-on-right, or even refocus-right (the -on isn't then doing much work), or even refocusʳ... in the style of other lemmas in the library.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to make some proposal on naming as a full comments instead of inline.

Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
module Algebra.Reasoning.Semigroup {o ℓ} (S : Semigroup o ℓ) where

open Semigroup S
using (Carrier; _∙_; _≈_; setoid; trans ; refl; sym; assoc; ∙-cong)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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ʳ)

Comment on lines 109 to 112
pushʳ {x = x} = begin
x ∙ c ≈⟨ sym (∙-cong refl ab≡c) ⟩
x ∙ (a ∙ b) ≈⟨ sym (assoc x a b) ⟩
(x ∙ a) ∙ b ∎
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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
Copy link
Contributor

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)

Copy link
Contributor

@jamesmckinna jamesmckinna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@MatthewDaggitt MatthewDaggitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with a lot of what @jamesmckinna is saying.

  • This doesn't need it's own module, i.e. Algebra.Properties.Semigroup is fine.
  • I much prefer the current set of names.

CHANGELOG.md Outdated
@@ -123,6 +123,8 @@ New modules

* `Data.Sign.Show` to show a sign

* `AlgebraPropreties.Semigroup.Reasoning` adding reasoning combinators for semigroups
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of typos in the name?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And indeed, if we do as I have suggested several times, and not make this a new module, but under additions to existing modules, then it should be under Algebra.Properties.Semigroup...

CHANGELOG.md Outdated
@@ -123,6 +123,8 @@ New modules

* `Data.Sign.Show` to show a sign

* `AlgebraPropreties.Semigroup.Reasoning` adding reasoning combinators for semigroups

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also not sure whether we should refer to these as reasoning combinators. The Reasoning terminology has quite a specific use in the library for syntax that chains together nicely. I'm not sure these lemmas qualify?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We won't need CHANGELOG text if it moves to Additions to..., but the opening comment block should be rephrased...

Copy link
Contributor

@jamesmckinna jamesmckinna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of comments and suggestion, but mostly a do-over of things I have already commented on before, and were not (yet) changed. TL;DR:

  • move all the lemmas to Algebra.Properties.Semigroup
  • anonymous modules
  • fix implicit/explicit quantification

It would be better for you to do (all) this, but if you are having problems with it, it's easy enough for me to take a copy of your branch and push the various changes to it...

CHANGELOG.md Outdated
@@ -123,6 +123,8 @@ New modules

* `Data.Sign.Show` to show a sign

* `AlgebraPropreties.Semigroup.Reasoning` adding reasoning combinators for semigroups
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And indeed, if we do as I have suggested several times, and not make this a new module, but under additions to existing modules, then it should be under Algebra.Properties.Semigroup...

CHANGELOG.md Outdated
@@ -123,6 +123,8 @@ New modules

* `Data.Sign.Show` to show a sign

* `AlgebraPropreties.Semigroup.Reasoning` adding reasoning combinators for semigroups

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We won't need CHANGELOG text if it moves to Additions to..., but the opening comment block should be rephrased...

@jamesmckinna jamesmckinna changed the title [Add] Reasoning combinator for semigroup [Add] Consequences of associativity for Semigroups Apr 10, 2025
@jamesmckinna
Copy link
Contributor

Following @MatthewDaggitt 's comment about 'reasoning combinators', I've taken the liberty of renaming the PR to hopefully better reflect the intention of the contribution(s) here.

Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
@jmougeot
Copy link
Contributor Author

I moved everything into Semigroups and made the variables explicit. I tried to address all the comments, but I probably missed some. Sorry for not taking these changes into account earlier

Copy link
Contributor

@jamesmckinna jamesmckinna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last round of changes, I hope, because I've looked at this to many times now... law of diminishing returns...

NB if you adopt my suggestions, there will no doubt be knock-on consequences (wrt parametrisation) which you should fix before committing... for the sake of any other reviewers!

UPDATED: and you still have a 4-space indentation for all the definitions, instead of the mandated 2... PLEASE FIX, along with the CHANGELOG formatting, which has now broken.

uv≈w⇒x∙wy≈x∙[u∙vy] : x ∙ (w ∙ y) ≈ x ∙ (u ∙ (v ∙ y))
uv≈w⇒x∙wy≈x∙[u∙vy] = sym (uv≈w⇒x[uv∙y]≈x∙wy uv≈w _ _)

module _ {u v w x : Carrier} where
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These will need to be explicit... for the usual reasons, but there's no need to make Carrier explicit:

Suggested change
module _ {u v w x : Carrier} where
module _ u v w x where

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why this was marked as resolved?

u[v∙wx]≈[u∙vw]x : u ∙ (v ∙ (w ∙ x)) ≈ (u ∙ (v ∙ w)) ∙ x
u[v∙wx]≈[u∙vw]x = sym [u∙vw]x≈u[v∙wx]

module _ {u v w x : Carrier} (uv≈wx : u ∙ v ≈ w ∙ x) where
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally, here:

Suggested change
module _ {u v w x : Carrier} (uv≈wx : u ∙ v ≈ w ∙ x) where
module _ (uv≈wx : u ∙ v ≈ w ∙ x) where

because the variable declarations take care of the initial implicit prefix...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nor this, because it hasn't been fixed yet.

jmougeot and others added 8 commits April 14, 2025 14:36
Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
Co-authored-by: jamesmckinna <31931406+jamesmckinna@users.noreply.github.com>
@@ -126,6 +126,8 @@ New modules
Additions to existing modules
-----------------------------

* In `Algebra.Properties.Semigroup` adding consequences for associativity for semigroups

Copy link
Contributor

@jamesmckinna jamesmckinna Apr 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to insert here all the new names, once we have (eventually) agree them...

Suggested change
```agda
uv≈w⇒xu∙v≈xw : u ∙ v ≈ w → ∀ x → (x ∙ u) ∙ v ≈ x ∙ w
...

etc.

@JacquesCarette
Copy link
Contributor

As I've indicated, I'm not a big fan of push/pull because they are not very mnemomic; the superscripts don't help either. Indeed, if one looks at

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

what it really does is

  1. refocus on the right
  2. apply an equality there.

So that's what I'd like the naming to reflect. Now, I quite like the 'synonym' _⟩∙⟨_ for ∙-cong (hoping to introduce that synonym too.) So then if we take to be refocus (on the right), then the above could be ⭆∙⟨_. We would similarly have a refocus on the left then act on that side as ⭅⟨_∙. I would be fine with putting in a marker for where "nothing happens". So we could have:

  • ⭆-I∙⟨_ : refocus right then apply equation there
  • ⭅-_⟩∙I : refocus left then apply equation there
  • I∙_⟩-⭅ : apply equation on right then refocus left
  • _⟩∙I-⭆ : apply equation on left then refocus right

Note that these are meant to have the 3 variables be implicit, on purpose: if they cannot be figured out by Agda, then it's probably better to use the 'long form' of the reasoning (i.e. explicit calls to assoc).

@jamesmckinna
Copy link
Contributor

As I've indicated, I'm not a big fan of push/pull because they are not very mnemomic; the superscripts don't help either. Indeed, if one looks at

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

what it really does is

1. refocus on the right

2. apply an equality there.

So that's what I'd like the naming to reflect. Now, I quite like the 'synonym' _⟩∙⟨_ for ∙-cong (hoping to introduce that synonym too.) So then if we take to be refocus (on the right), then the above could be ⭆∙⟨_. We would similarly have a refocus on the left then act on that side as ⭅⟨_∙. I would be fine with putting in a marker for where "nothing happens". So we could have:

* `⭆-I∙⟨_` : refocus right then apply equation there

* `⭅-_⟩∙I` : refocus left then apply equation there

* `I∙_⟩-⭅` : apply equation on right then refocus left

* `_⟩∙I-⭆` : apply equation on left then refocus right

Note that these are meant to have the 3 variables be implicit, on purpose: if they cannot be figured out by Agda, then it's probably better to use the 'long form' of the reasoning (i.e. explicit calls to assoc).

OK, I guess it is/was good to see how far apart the various contributors are on how to think about these naming issues, and their intended semantic underpinnings. But I have to say that I find the gap between the symbolic names you propose ((NB in my Firefox font for GitHub, your symbol doesn't even display!) and those intended meanings so large that I simply cannot imagine ever using these principles except via uncomprehending cut-and-paste from the module, and with the above explanation by my side as user manual.

In the face of this, I am going to suggest

  • either that we roll back to a text-based name, with your clear desire to inject 'refocus' as an idiom as a basis for the name (and I even suggested names based around that above)...
  • or that we redraw the 'implicational' forms I suggested to make the x∙y≈z⇒prefix implicit as an infix argument position, with eg.
    • x∙y≈z⇒[w∙x]∙y≈w∙z : (w ∙ x) ∙ y ≈ w ∙ z becoming [wx]y≈[_]wz or [wx]y≈⟨_⟩wz, but again, we have up until now avoided making operators for equational proofs into infixes/mixfixes... except in the 'equation over equation' presentation of equality-modulo-cast in Data.Vec.Relation.Binary.Equality.Cast
  • or simply that I withdraw from even expressing a view about this (much less merge the PR), other than to say that adopting such a change as you propose would mark such a meta-level breaking change from existing practice in stdlib that... I am completely lost for words!

Barn-burning.

@JacquesCarette
Copy link
Contributor

My firefox displays them all just fine!

I would be fine with a name that involves refocus instead of symbology. We could use superscripts for indicating left/right refocusing. The one thing I don't know how to make nice: refocus-then-cong vs cong-then-refocus.

Your mixfix suggestion might have legs. In fact, by eliding the common prefix entirely, using it as a purely prefix operation might result in a name that's close to readable.

If my mnemonic symbology is not acceptable, I would think a text-based name based around 'refocus' is probably better than other unicode soup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants