Skip to content
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

Add some type relations and isomorphisms #2419

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

Conversation

WhatisRT
Copy link
Contributor

Upstreaming some functions that I've used to prove things about sets (not the Agda kind).

src/Data/Product/Function/Dependent/Propositional.agda Outdated Show resolved Hide resolved
src/Function/Related/TypeIsomorphisms.agda Outdated Show resolved Hide resolved
-- primed variants are more level polymorphic

×-distribˡ-⊎′ : (A × (B ⊎ C)) ↔ (A × B ⊎ A × C)
×-distribˡ-⊎′ = Σ-distribˡ-⊎
Copy link
Contributor

Choose a reason for hiding this comment

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

Following the convention of Function.Base then the primes should be on the less polymorphic lemmas rather than the more polymorphic lemmas?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I wasn't sure about backwards compatibility. If you think it's fine I'll swap the two. Do you think ×-distrib-⊎ should also be primed for consistency, even though it probably doesn't make sense to add a non-primed version?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think ×-distrib-⊎ should stay as is because it is already non-dependent because it uses _×_ rather than . The additional advantage is that this doesn't have backward compatibility problems!

Copy link
Contributor

@jamesmckinna jamesmckinna Sep 28, 2024

Choose a reason for hiding this comment

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

Apologies for the recent flurry of (now deleted) suggestions here. I realise that I wasn't quite understanding how this PR adds more polymorphic versions, and reimplements the prior functionality in these terms, but I'd be tempted to suggest that we 'just' take the more polymorphic versions... would this be a breaking change? Or potentially give rise to unsolved metas?

@MatthewDaggitt MatthewDaggitt added this to the v2.2 milestone Jun 25, 2024
@MatthewDaggitt
Copy link
Contributor

Ah, and a CHANGELOG entry would be great!

@WhatisRT
Copy link
Contributor Author

I'll add the CHANGELOG once 2.1 is out.

@jamesmckinna
Copy link
Contributor

@WhatisRT any progress on the suggested changes? This should be easy to merge once you've done that...

@WhatisRT
Copy link
Contributor Author

I've added the changes to the CHANGELOG. I don't really understand what's the final verdict on the naming, should I change some of the names or not?

@JacquesCarette
Copy link
Contributor

JacquesCarette commented Sep 1, 2024

Yes, some of the names do need changing from what's in your PR. But some of the name changes you did do were not necessary!

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Sep 24, 2024

I think that it would be good to try to merge this sooner rather than later, and AFAICT, it's down to agreeing names for the new additions... can we converge on mutually agreeable suchl!?

@JacquesCarette
Copy link
Contributor

Looks like the master merge broke the build?

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Sep 24, 2024

Looks like the master merge broke the build?

Nope... (I think) it's a CI thing... the rebuild of alex and happy which fails even before the attempted master merge is tested...

@MatthewDaggitt
Copy link
Contributor

Reading the comments, it looks like we have got consensus on the names?

@jamesmckinna
Copy link
Contributor

Reading the comments, it looks like we have got consensus on the names?

Yes, I'd been waiting on @WhatisRT to update this PR, but if you're keen to merge now (and for sure, this PR prompted me to think harder about some other type isos which might usefully be added downsream, esp. as regards refactoring Data.List.Relation.Binary.BagAndSetEquality (again!)), I'd be happy to push updates from my end...

CHANGELOG.md Outdated Show resolved Hide resolved
@WhatisRT
Copy link
Contributor Author

Sorry, I think I missed some of the naming suggestions. But it seems you all have way stronger opinions about that than I do so I'd rather let you do the final adjustments.

@jamesmckinna
Copy link
Contributor

I think if @JacquesCarette or @MatthewDaggitt can resolve the questions about level polymorphism and its impact on names (I managed to confuse myself too much over this to do so :-() then following @WhatisRT 's most recent comment, then you should make those changes yourselves and merge!

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Sep 30, 2024

Looking again at all this: the less/insufficiently polymorphic versions of the distributive laws are also present in Data.Product.Algebra, so it's tempting to argue for making the (possibly) breaking change of making Function.Related.TypeIsomorphisms carry only the more polymorphic version, and re-implement the less polymorphic versions in Data.Product.Algebra using that functionality? (Or vice versa?)

Also (but separate from this PR): in each module, assoc for each of sum and (non-dependent) product are less/insufficiently polymorphic... suggesting that the library design might benefit from larger scale rethinking of these questions... or have I misunderstood something fundamental to what's going on here? UPDATED Issue #2489

@jamesmckinna
Copy link
Contributor

How should we proceed with this? Merge as is, and refactor later?

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

Successfully merging this pull request may close these issues.

4 participants