-
Notifications
You must be signed in to change notification settings - Fork 110
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
Cleanup phantom types #1046
Cleanup phantom types #1046
Conversation
37390a3
to
498bb9f
Compare
I agree for merging this only with 8.18... |
Note that we should also remove phantoms in HB itself.
That's what the current PR does, the notations remain as parsing only and are deprecated. |
Some benchmarks:
(common to all three: coq-elpi coq-master + merge master (8be42fa), HB coq-master + batch-accumulation (6d81cdf)) So there doesn't seem to be any dramatic slowdown. |
498bb9f
to
c37f71f
Compare
c37f71f
to
094f9ca
Compare
094f9ca
to
91379dd
Compare
This should be backward compatible
Do you have any blockers in merging this PR? (Just asking because I wanted to do the same for multinomials.) |
We were waiting for 8.18 to be out (because printing is only reasonnable since 8.18) but it should be good now, I guess it's just a matter of rebasing and merging, let's discuss this during the next meeting. |
91379dd
to
f506320
Compare
This should be backward compatible
9962404
to
b51c39c
Compare
1e903ad
to
ddea82e
Compare
ddea82e
to
90b9b58
Compare
365f200
to
e4718ec
Compare
@pi8027 yes, I'm just fixing the changelog (and waiting for CI) before clicking on |
@@ -324,12 +322,13 @@ End UnitsGroup. | |||
|
|||
Module Import UnitsGroupExports. | |||
Bind Scope group_scope with unit_of. | |||
Arguments unit_of R%type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the presence of reverse coercions, I think it makes sense to do
Bind Scope type_scope with finUnitRingType.
(and the same for every structure whose carrier is a Type
).
Then we can get rid of this kind of Arguments
declarations (but it can be done in a separate PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, let's do that in another PR.
In fact, we should probably implement this in HB rather than putting Bind Scope
manually everywhere. Cc @CohenCyril
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do this systematically, the rule of thumb would be that a structure should inherit the Bind Scope
declaration from the carrier. For example, a morphism structure should inherit it from its carrier _ -> _
(whose scope is fun(ction)_scope
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there are already three cases in HB depending on coercion class of the key (SortClass, FunClass and globref), this should guide the binding (to type_scope, fun_scope and ? respectively).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm taking care of doing this by hand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if the interface for binding scopes exists in coq-elpi, it's probably just as easy to improve HB.
e4718ec
to
5128a91
Compare
@@ -1580,7 +1580,7 @@ Definition cfIsom := | |||
locked_with cfIsom_key (cfMorph \o 'Res[G1] : 'CF(G) -> 'CF(R)). | |||
Canonical cfIsom_unlockable := [unlockable of cfIsom]. | |||
|
|||
Lemma cfIsomE phi x : x \in G -> cfIsom phi (f x) = phi x. | |||
Lemma cfIsomE phi (x : aT : finType) : x \in G -> cfIsom phi (f x) = phi x. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need : finType
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember the details but it's needed to keep the type of the lemma unchanged (otherwise, we get x : aT
whereas it was x : finGroupType_to_finType aT
before removing the phantoms).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
strange that finGroupType_to_finType
is displayed ... we should investigate (we can merge first and investigate later)
5128a91
to
475c9f7
Compare
475c9f7
to
c78ea08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few questions are left (see my review comments above), but any of them can be addressed in a separate PR. So, this PR seems good enough to merge.
@proux01 @CohenCyril Shall we merge this one? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@proux01 amazing work, thank you.
Thanks @pi8027 for the careful review! |
Note about the odd-order overlay: math-comp/odd-order#52 it required the addition of a few rewrite patterns, They looked like the usual issue with rewrite not selecting the first occurence, as already encountered when porting MC to HB (for instance with associativity lemmas). |
About the CoqEAL overlay: there was some strange exploit of the duplicated phantom canonical instances, this seems to hint to the fact that the dvdRing structure there should be included in the main MC algebraic hierarchy, which would hopefully avoid that terrible hack. |
Motivation for this change
Cleanup phantom types now that reverse coercions make them useless.
We probably want to wait for 8.18 to be out before merging this, in order to get a better interactive experience with nicer printing.
Things done/to do
CHANGELOG_UNRELEASED.md
Compatibility with MathComp 1.X
I added the label(while this would be possible, I'm not sure we want to backport that)TODO: MC-1 port
to make sure someone ports this PR tothe
mathcomp-1
branch or I already opened an issue or PR (please cross reference).Automatic note to reviewers
Read this Checklist and put a milestone if possible.
Overlays (to be merged before the current PR)