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

wrapper mixin step0 #370

Draft
wants to merge 64 commits into
base: master
Choose a base branch
from
Draft

wrapper mixin step0 #370

wants to merge 64 commits into from

Conversation

ptorrx
Copy link
Collaborator

@ptorrx ptorrx commented Jun 19, 2023

No description provided.

@CohenCyril CohenCyril marked this pull request as draft June 19, 2023 15:14
Fail Record Monoid_enriched_quiverN1 := {
ObjN: Type;
iQ: isQuiver ObjN;
hsM: forall A B, hom_isM_ty (@hom iQ)
Copy link
Member

Choose a reason for hiding this comment

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

This fails because hom expects a Quiver.type not a isQuiver. You can try to use HB.pack here.

Copy link
Member

Choose a reason for hiding this comment

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

Comment on lines +147 to +148
HB.instance Definition funQ_isMon (A B: Type) : isMon (hom A B) :=
funQ_isMonF A B.
Copy link
Member

Choose a reason for hiding this comment

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

One thing we missed here was that this instance should not be created.
We should replace by an instance of the wrapper mixin.
Indeed the wrapper mixin projection private has already been declared as an instance of isMon on hom.

@CohenCyril
Copy link
Member

@ptorrx I recommend never merging in a PR, but only rebasing.

CohenCyril and others added 22 commits July 6, 2023 14:31
…reaks the compilation of the Coq code. Included call to derive-wrapper-instances in declare-all, but not really sure about it. Commented out funQ_isMon in monoid_enriched_cat.v because it should be derivable, once funQ_hom_isMon is available. But actually I can't see where HB learns about funQ_isMonF, except in the funQ_hom_isMon definition (the one we should actually generate)
…plicates in the association list (which was broken in DCIFF with std.forall)
…tory-based example in monoid_enriched_cat_factory.v
…ompilation glitch (it will compile only the first two of them, regardless of which you put first; so all the examples compile, but not together)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants