Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] Coq 8.6 typeclasses behavior change

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] Coq 8.6 typeclasses behavior change


Chronological Thread 
  • From: Matthieu Sozeau <mattam AT mattam.org>
  • To: coq-club AT inria.fr
  • Subject: Re: [Coq-Club] Coq 8.6 typeclasses behavior change
  • Date: Wed, 16 Nov 2016 15:21:54 +0000
  • Authentication-results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=mattam AT mattam.org; spf=Pass smtp.mailfrom=matthieu.sozeau AT gmail.com; spf=None smtp.helo=postmaster AT mail-wm0-f47.google.com
  • Ironport-phdr: 9a23:/jN6nR2ZG3JJqkTEsmDT+DRfVm0co7zxezQtwd8Zse0WIvad9pjvdHbS+e9qxAeQG96KsLQd16GJ7ejJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fdbghMijexe65+IRq5oQjTt8QdnJdvJLs2xhbVuHVDZv5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3so5MLwrhnMURGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RTKv5LptRRT1iikIKiQ5/XnYhcx+jq1VoByvqR9izYDKfI6YL+Bxcr/HcN4AWWZNQsRcWipcCY28dYsPCO8BMP5foYbnu1sOsRu+BQiyC+Py1zRGm3j23Kwk3Os7DAHNwQstH9cUv3TIsNX6LqISXPuwzKbS0TXDc+lZ2TLn5IjPaBAhruiBULRtesTS0UkiDwHIg1qKpYD4IT+Y1v4BvmuF4+Z6Wu+iiWgqoBxrrDe13McjkIzJi5oVyl/a8SV5x544JdiiR056Zd6oCZVRtySGO4dvTMMvTGNltDw1yr0Bvp67cywKx4o9yxHDbPyHdpCE4hPlVOmPPTd1nHBodb2lixqv70StyvfwW8qq3FpQoSdIkMHAtnUX2BzS7siHROF9/kCk2TuX0gDc8P1EIVw0laraNZEh36Q8loEUsUXCACD5glj2gbSZdkUh4Oeo6uDnbq/6qZ+bMo94khv+Pbg2msyjHeQ4NRADUHSc+eSlzbHs4Un5QKhRgfAtianYsJXaJdwBqaKjAg9V1Jwj6xelADu83tQYhypPEFUQcxWeyoPtJlvmIfbiDP75jU7/vi1swqXjN6H9ApTAMzD4l6XsdKs1v0tV1BY6yPha7o5IA7RHJ+j8DByi/OfEBwM0ZlTni93sD89wg9sT

Just to be clear, I'm not advocating for eq to become a class in general (although it might have uses), I'd rather have people use wrapping classes like Enrico suggested to delimit cleanly the goals the are left to resolution. Another idea to correct this issue of classification is to tag the holes/premisses rather than relying on the types. Anyway, it seems this change has more far reaching consequences than expected (due to globality of Existing Class declarations for example) and we'll need some time to settle on a design, so we'll revert that change in 8.6. Thanks for the quick feedback, everyone!

On Wed, Nov 16, 2016 at 2:47 PM Matthieu Sozeau <mattam AT mattam.org> wrote:
I'm curious about the actual use cases of using such non-class premises around, I'd be happy to hear about others. We can still go back on this cleanup.
-- Matthieu

On Wed, Nov 16, 2016 at 2:40 PM Matthieu Sozeau <mattam AT mattam.org> wrote:
The goal is to be able to recognize what is and what isn't a class goal from its type.
When doing resolution during refinement we need that information.
One can also argue that if you put Hint Extern (_ = _) => reflexivity : typeclass_instances
in your file then you can expect Definition foo : 0 = 0 := _. to typecheck.
-- Matthieu


On Wed, Nov 16, 2016 at 2:33 PM Enrico Tassi <enrico.tassi AT inria.fr> wrote:
On Wed, Nov 16, 2016 at 01:23:04PM +0000, Matthieu Sozeau wrote:
> This is a deliberate change to avoid "wrong" instances which generate
> non-class goals from polluting search.
> You just need to declare the head as a class using Existing Class eq for
> example here, because you're really
> treating it as a class. Sorry for not updating the CHANGES yet, the refman
> has been updated though.

What you propose seems a bit too drastic, Existing Class marks
Eq as class "forever".  A lighter work around could be the following

  Class Foo (x : nat).
  Class TCPremise (P : Prop).
  Instance foo x : TCPremise (x = 2) -> Foo x.
  Hint Extern 0 (TCPremise (_ = _)) => reflexivity : typeclass_instances.

But frankly the use case of Ralf seems reasonable, and the contortion
above pretty ugly.

Can you explain what you mean by "wrong" instances, exactly?

Best,
--
Enrico Tassi



Archive powered by MHonArc 2.6.18.

Top of Page