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

[DRY] Refactor algebraic properties of types #2489

Open
jamesmckinna opened this issue Oct 1, 2024 · 0 comments
Open

[DRY] Refactor algebraic properties of types #2489

jamesmckinna opened this issue Oct 1, 2024 · 0 comments

Comments

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Oct 1, 2024

There's (a lot of) duplication between Function.Related.TypeIsomorphisms and Data.(Product|Sum).Algebra (and possibly elsewhere: eg the duplication of True↔ between the first of these, and Relation.Nullary.Decidable...).

This might be bad enough to want to deprecate whole modules, but there is a subtle problem exposed by #2419 , namely that not all the lemmas are as level-polymorphic as they might be, esp. those in Data.Product.Algebra, where the use of Algebra.Definitions imposes a homogeneous level restriction.

So a refined refactoring might be to makeFunction.Related.TypeIsomorphisms home for the heterogeneous level-polymorphic definitions (the direction in #2419 ), while making Data.*.Algebra home for the homogeneous/algebraic versions?

This feels as though it might be a useful clean-up, but potentially breaking wrt possibly unresolved Level metas and/or name clashing which no obvious (or at least: sensible) deprecation strategy can comfortably accommodate... cf #2421

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

No branches or pull requests

1 participant