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

Adapt to MC#1319 #106

Closed
wants to merge 1 commit into from
Closed

Adapt to MC#1319 #106

wants to merge 1 commit into from

Conversation

Tragicus
Copy link
Contributor

math-comp/math-comp#1319 generalizes 1 to pzSemiRingType, which means that we need to generalize things here too.

@Tragicus Tragicus force-pushed the mc1319 branch 3 times, most recently from 7c4be5b to 3d7ed71 Compare January 17, 2025 11:37
Comment on lines +181 to +186
pred sring->pzsring i:term, o:term.
sring->pzsring U V :-
if (coq.locate-all "pzSemiRingType" [loc-gref PzSemiRingType| _ ])
(coq.elaborate-skeleton U (global PzSemiRingType) V ok)
(V = U).

Copy link
Member

Choose a reason for hiding this comment

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

Calling this predicate every time we process a ring operator looks a bit costly. Isn't it possible to define compatibility notations (or constants) for GRing.SemiRing.sort, GRing.ComSemiRing.sort, GRing.Ring.sort, and GRing.ComRing.sort and replace their occurrences in common.elpi?

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, Cyril raised the same issue. He figured that we could make the code more robust to the changes that are happening in mathcomp by precomputing the coercions that coq.elaborate-skeleton would insert, see #108).

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.

2 participants