-
Notifications
You must be signed in to change notification settings - Fork 245
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
[ refactor ] Reconcile Relation.Binary.Definitions.Adjoint
and Function.Definitions.Inverse*
#2581
Comments
I think that introducing these concepts is a good idea. What's the definition of |
Against the proposal, @MatthewDaggitt 's comment on #2566 , which offered a similar refactoring for |
If we had "comments as valid code" like was discussed earlier today, then your Another might be to embrace meta-programming even more: have the "developer's source" have I am, naturally, quite partial to that second approach. But the first approach is also quite appealing. |
Else: use `Function.Consequences.*' to relate the two kinds of definitions... rather than insist on definitionally identifying them. Still, I think we should add the |
That seems reasonable. |
Meditating on #2580 (and some other recent PRs, including those which touch
Function.*
), it's hard not to observe the following:Relation.Binary.Definitions.Adjoint
universally quantifies the product of two implications, rather than separating them out as distinct (universally quantified!) implications, and then taking their product, cf.Function.Definitions.Inverse
in terms ofInverseˡ
andInverseʳ
Setoid
s which supply the 'equality' relations...) could, moduloflip
-symmetry, be re-expressed as instances of the corresponding components of the above refactoring ofRelation.Binary.Definitions.Adjoint
Accordingly: propose:
separate out (
naming
?)HalfLeftAdjoint
andHalfRightAdjoint
asby comparison with the current status quo
redefine
by comparison with the current status quo
ie
Inverseˡ
is identical, modulo flipping the argumentsx
andy
, whileInverseʳ
flips each equality by symmetry.Pro: DRY, possible refactoring
Function.Properties.Inverse.HalfAdjointEquivalence
(?), ...Inverse
as a special case ofAdjoint
, hence... (?), ... etc.Con: potentially very
breaking
, and perhaps requires good upside-down-and-backwards spectacles through which to look at everything...The text was updated successfully, but these errors were encountered: