[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