Bundles for `Algebra.*Homomorphism`, and their algebra: `Hom`-'sets' for `Algebra`

[jamesmckinna]

[cf. #1962 where there's the beginnings of a possible design for this, so that I could properly define a left adjoint to the forgetful functor Magma -> Setoid, witnessed on objects by Magma.setoid, but not really properly on morphisms. ]

Algebra.Morphism.Structures defines all the properties eg isMagmaHomomorphism of being a MagmaHomomorphism, but there's nowhere (?) in stdlib where those properties are bundled with their morphisms between the underlying Setoids.

Correspondingly, identity and composition for such things are distributed between Relation.Binary.Morphism.Construct and Algebra.Morphism.Construct, and which again operate only on the underlying proofs of properties.

Proposal: we add actual bundled homomorphisms for all the algebraic Structures in the library, on a 'one structure, one module' basis, to which we also package the Identity and Composition structures. UPDATED: bundled homomorphisms now under Algebra.Morphism.Bundles, with their Identity and Composition now handled under Algebra.Morphism.Construct

Now, this may already all be done (nicely, better, ...?) in agda-categories, and if so, then a plea to merge in this stuff.

[Taneb]

I support this idea but not the concrete details. It's not currently done better in agda-categories, or indeed at all. I'm working on that on the agda-categories side but was just planning to use Data.Product

[Taneb]

I'm not convinced we should have one module per structure but not strongly against it. I'd be interested to hear your justification of that over one file with all the bundles in it, which matches closer what we do elsewhere in the algebra hierarchy

[jamesmckinna]

but was just planning to use Data.Product
Is this because all the bundling/unbundling gets to painful?

[Taneb]

but was just planning to use Data.Product
Is this because all the bundling/unbundling gets to painful?

No, it's simply because the bundles didn't exist. It works a little better with some subcategory machinery in agda-categories but it's still not a perfect match

[jamesmckinna]

Re: one module per one algebra vs. how it is currently done now:
I think I managed to get confused as to whether all the various instances of identity and compose would share the same namespace happily? But if so, then indeed, consistency with current practice demands such an approach.

[Taneb]

I'd certainly be happy to see some experimentation with the design here

[JacquesCarette]

Strongly agree with

Proposal: we add actual bundled homomorphisms for all the algebraic Structures in the library,

as I ended up having to define some of these myself in a current project.

While I'm a huge fan of small files and small modules, right now we should stay consistent with the rest of Algebra and produce another monster (sigh).