I would like to implement what I discussed here: https://coq.discourse.group/t/generalizing-coercions-to-infer-typeclass-arguments/1241/4?u=cohencyril and tried to impulse one day here: https://coq.zulipchat.com/#narrow/stream/237656-Coq-devs.20.26.20plugin.20devs/topic/Reverse.20coercions
@Enrico Tassi
Hello, is this the same thing as https://arxiv.org/abs/1103.3320
Can we meet in breakout room 2 and talk about it?
Did you implement it in Matita ?
ok for room two
Hacking session on this topic tomorrow at 10:20 AM
Great @Enrico Tassi , you mind updating the schedule in the wiki too?
FYI We are starting hacking coercions in room 1
https://github.com/coq/coq/pull/15693
We resumed working with @Enrico Tassi. We noticed a failure in mathcomp when trying out the PR when replacing the old def of {poly R}
by a simpler one.
We are in Room 1
The problem was that we immediately encounter an occurrence of predArgType >-> Type <-< ringType
The solution for now is to deal only with types which have coercions either to Sortclass
or Funclass
What are reverse coercions? / what's the idea?
@Jason Gross Here is the original discussion
The paper I wrote a long ago is in topic. We did open a draft pr with a few examples.
Thanks! And sorry, I missed the earlier messages. I guess I should narrow streams more to see the context.
We did push a bunch of commits cleaning up a lot and kind of implementing the search for a common point to which the inferred and expected type can be coerced, on coercion path must be reversible (although the check for reversibility is still dummy).
Last updated: Jun 10 2023 at 23:01 UTC