Closed
Description
Every other property in the algebraic (not to mention in Relation.Binary
etc.) structures are simply named assoc
/comm
etc. unless the structure contains two operators in which case they are prepended with the operator name(s).
The exception to this rule is the congruence proof which is incongruously named ∙-cong
.
agda-stdlib/src/Algebra/Structures.agda
Line 36 in b09525c
We should have a discussion about whether we should rename this to simply cong
in version 2.0.
As I see it:
Pros
- More consistent
- Easier to type (frequently get confused about whether it's
\.
\cdot
or\bub
in certain fonts)
Cons
- May clash with
cong
fromRelation.Binary.PropositionalEquality
a lot.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
JacquesCarette commentedon Jul 11, 2021
That con could be a really big one. So I headed over to
Algebra.Properties
to find out how bad it would be... and it would be fine. They are not used together there!So I started writing this comment being quite against it (because of the con), and when I went digging for data... didn't find it. This could be worse in code bases "out there", I don't know. But internally to the library itself, this doesn't look like a big deal.
MatthewDaggitt commentedon Jul 11, 2021
Anecdotally, I also rarely use them together. As I'm very keen on having small modules that do one thing, either I'm working with setoid based equality from some algebraic structure or I'm working with propositional equality. However, it may have a greater impact on people who tend to throw everything together in bigger files...
jamesmckinna commentedon Oct 24, 2022
Middle ground: why not
cong₂
? Won't you also need a unary version (cong₁
?) as well? And yes, I know the contra above would still be a potential problem, but much less common than that arising forcong
itself (it's a pity about the pre-existingcong₂
)?jamesmckinna commentedon Jan 4, 2023
What happens in your proposed scheme to the properties
∙-congˡ
and∙-congʳ
?SelfInverse
operations onAlgebra
s and their properties #1914MatthewDaggitt commentedon Apr 26, 2023
They would become
congˡ
andcongʳ
jamesmckinna commentedon Sep 26, 2023
v2.0
?jamesmckinna commentedon Sep 28, 2023
For whatever reason (but see numbers below), I'm going to press on my proposal to rename to
cong₂
(andcong₁
where appropriate, along with @MatthewDaggitt 's left-/right- names). The definitions inAlgebra.Definitions
have no compunction about the subscripting, and relative toPropositionalEquality
, we (appear to) have∙-cong
, relative to 250 uses ofcong₂
, compared to 2500+ uses ofcong
[figures approximate, based on rubbish
grep
ping; and these are merely occurrences, rather than attempting to track actual/potential clashes, but clearly the potential clash rate is already reduced by an order of magnitude by the proposal... ;-)]jamesmckinna commentedon Oct 21, 2023
Opening a related issue for v2.0-rc1...
•
: in•-cong : Congruent₂ _•_
inAlgebra.Consequences.Setoid
#2178jamesmckinna commentedon Jul 30, 2024
Revisiting this, I am (now) conscious that the opposite choice is already made regarding the name of the homomorphism property in
Algebra.Morphism.Structures.IsMagmaHomomorphism
, which for whatever reason, is calledhomo
, whereas all the subsequent field names for such properties are tagged by the associated piece of syntax, viz.ε-homo
forIsMonoidHomomorphism
, etc.Correspondingly, congruence for
⁻¹_
is⁻¹-cong
in the definition ofAlgebra.Structures.IsGroup
... etc.So I'm tempted to conclude that we should, in fact, retain the name
∙-cong
, and moreover renameAlgebra.Morphism.Structures.IsMagmaHomomorphism.homo
to∙-homo
...?This seems to arise from the v1.5 deprecations in
Algebra.Morphism
, some of whose definitions (moreover ofsyntax
!) nevertheless still appear in egData.Nat.Properties
(thanks to suppression of the deprecation warnings... sigh)UPDATED: seemingly only 15 uses of such
homo
in the library needing to be updated?homo
name in algebra hierarchy? #2458jamesmckinna commentedon Aug 31, 2024
Should we close this now, in favour of #2458 / #2464 ?
Or is this issue sufficiently 'orthogonal' to be left open?
JacquesCarette commentedon Sep 1, 2024
I do believe we should close this one, since it is about going in the 'wrong' direction.
MatthewDaggitt commentedon Dec 9, 2024
Yup agreed