Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] "Core" Coq typeclasses

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] "Core" Coq typeclasses


Chronological Thread 
  • From: "Benjamin C. Pierce" <bcpierce AT cis.upenn.edu>
  • To: coq-club AT inria.fr
  • Subject: Re: [Coq-Club] "Core" Coq typeclasses
  • Date: Wed, 28 Jun 2017 14:06:20 -0400
  • Authentication-results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=bcpierce AT cis.upenn.edu; spf=Pass smtp.mailfrom=bcpierce AT cis.upenn.edu; spf=None smtp.helo=postmaster AT fox.seas.upenn.edu
  • Ironport-phdr: 9a23:+uq6XR2EnQshFI3bsmDT+DRfVm0co7zxezQtwd8Zse0TL/ad9pjvdHbS+e9qxAeQG96KtLQc06L/iOPJYSQ4+5GPsXQPItRndiQuroEopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZvJuTyB4Xek9m72/q89pDXYQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfMQA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4KdxUBLnlCgIOSM5/m7VhMJ+j6xbrgymqRFk2YHYfISVOeB+fq/Bf94XQ3dKUMZLVyxGB4Oxd4UDAvcfMuZerYnyvV4OrRq4BQKxGu7j0CJDiGX33aIkyeQuDR/J0AI9FN8Jq3vbsM31NKYMXuCv0KbH0y7OYO9X2Tfm8oTIbwghru+KXbJ2a8be11QgFx7cg1iWtIfrPCuV2/wQv2Wb7OdsT/+jhmA7pw1roDWj290ghpTXio8R0lzI6CV0zYUvKdGlRkN3fcSoHIZRuiyVLYd6X8wvTmFutS0n0LMJo4S7czIPyJk/xx7QdfiHc4+Q7xLtU+aQLi10hGl7d72lnBa+61WgyvXiWcmy1lZGtDRKncTRtnwV1hzT7NaISudl80u82TuC1Brf5vxKLEwoj6bWKYMtzqQtmpYNtUnPBir2l1/3jK+SeEUk4O+o6+H/b7r9upCcL450hR/kMqsyhMOyGvg3MgkVX2SB5OS8zKPs/Uv/QLlQkPI5j7TZvIjAJcsHvq65HxNV0oE75hmjCDemyc0UkmUDLFJYYx2KlJPpOlHLIPDgF/izmVWskDFxx/DHJLLtGJvNLmKQ2IvmKL168gtXzBc55dFZ/ZNdTL8bc9zpXUqk/vbVCB0wNg2yi82hQO1825kVVCjHVqWSKKLfq1SFzukuOK+RfIITvnDwJ+VztK2mtmMwhVJIJfrh5pAQcn3tRvk=

Do let me know if you dig up the examples you had in mind — I’d love to be able to show people a simple comparison of the three approaches (and I’d love to understand it myself!)…

   - B

On Jun 19, 2017, at 11:23 AM, Soegtrop, Michael <michael.soegtrop AT intel.com> wrote:

for pointing out the differences and similarities between type classes, modules and canonical instances to beginners with various backgrounds, order relations might be good choice. It is a topic everybody basically understands, but on which one can show some interesting effects.
An example I sometimes use for explaining this is a red black tree example from Andrew Appel extended to arbitrary types with an order relation. To handle comparison of keys in tree boundary cases, I extend the type and its order relation to a type with a bottom and top element. This can be done with modules, type classes and canonical instances. I think one can the see the advantages and disadvantages of the various techniques best when one has a few levels of abstraction – in the above cases basic order relations – the order relations extended with bot/top and the red black tree using the order relations.
 
What I had most problems with initially is that some type classes have implicit parameters. This works quite well when the nesting level of these parameters is small, but when the nesting of parameters gets deeper one can have the issue that unification takes long, that error messages are hard to understand and that later in a proof one might require certain relations between different parameters of a type class which are not explicit when the initial resolution was done and that an instance is chosen which is not compatible with these requirements, although there is one which would be compatible. The solution is typically to explicitly specify some of the implicit parameters, especially their relation to each other. Another advantage of stating certain things explicitly is that it is easier to understand what actually happens. Let me see if I can find a few examples.





Archive powered by MHonArc 2.6.18.

Top of Page