Can we unify Relation.Binary.Morphism.Definitions and Function.Definitions?
Taneb opened this issue · comments
Relation.Binary.Morphism.Definitions
has as module parameters the domain and codomain of the functions over which the definitions are made, whereas Function.Definitions
has them in a variable
block. The former module only contains Homomorphic₂
, which is exactly the same as the latter's Congruent
, and a re-export of Morphism
from Function.Core
, which I think is otherwise unused in the library (and is just a synonym for the function arrow).
Can we deprecate Relation.Morphism.Definitions
in favour of Function.Definitions
?
"Can"? or "Should"?
It seems as though (modulo dependencies/dependency cycles? not sure about this...) we can.
Not obvious to me that we should... partly because of the ergonomics of the whole Algebra
hierarchy... that eventually rests on Relation.Binary
(and IsRelHomomorphism
specifically), and swapping out a Relation.Binary
component in favour of a Function
one, even if semantically equivalent/justified, seems like a rupture (however small) in the design hierarchy? Maybe this is a nonsense argument, but the "what are all the things I need to import to get task X done?" question (allied with the lack of suitable search tools) means that I like not having to look 'outside the box' for functionality if I can avoid it... but this is off the top of my head, without a serious analysis of the situation.
I agree with @jamesmckinna. We absolutely can, but I don't think we should because it would be violating the standard design of hierarchies in the library. Obviously if we could do it for every hierarchy in the library that would be a different question....