[TYPES] A show-stopping problem for modular type classes?

Brian Hulley brianh at metamilk.com
Mon Oct 12 21:11:00 EDT 2009


Derek Dreyer wrote:
> Now, coming back to the modular type class scenario, you're completely
> right that the Haskell approach of defining Set.insert to be
> parameterized over an Ord class constraint doesn't work properly in
> the presence of scoped instances.  The reason, as you said, is
> precisely that the type "Set a" doesn't make sense if there can be
> more than one ordering in the program.  What you really should do is
> parameterize the Set type constructor over (some static representation
> of) the ordering on the element type a.  Of course, that's exactly
> what a correct (i.e. "non-bug-friendly") implementation of applicative
> functors would do as well.
> 
> Unfortunately, the original modular type class paper (POPL'07) only
> supports generative functors, but for the reasons given above I think
> an applicative functor extension of it would be useful.  For more
> detail, I would refer you to the slides from a talk I gave a couple
> years ago, in which I simultaneously proposed modular type classes as
> a good motivation for non-bug-friendly applicative functors, and also
> sketched how an applicative functor extension to the MTC paper would
> look:
> 
> http://www.iai.uni-bonn.de/~ralf/WG2.8/24/slides/derek.pdf

Hi Derek,

Thanks for the above explanation and the slides, which I think offer deeply satisfying solutions to all the issues I've been talking about.

Best regards,
Brian.












More information about the Types-list mailing list