[bitc-dev] Retrospective: The Issues with Type Classes

Jonathan S. Shapiro shap at eros-os.org
Mon Apr 9 10:16:10 PDT 2012

On Sun, Apr 8, 2012 at 8:06 PM, Jeremy Shaw <jeremy at n-heptane.com> wrote:

> On Sun, Apr 8, 2012 at 2:06 PM, Jonathan S. Shapiro <shap at eros-os.org>
> wrote:
> > The first problem is strictly practical and entirely obvious: two groups
> > build libraries, each defines instances of Mumble(char). Years later
> their
> > libraries get linked into a single program, and Kaboom.
> Right. That is why type-class instances are supposed to be declare
> either in the module that defines the type or in the module that
> defines the class. That avoids the problem.

Except that (as you note) it doesn't work at scale. You build a collection
subsystem. I build a type. A third party wants to instantiate a collection
of my type, but lacks source code for either source module. Or simply
doesn't want to change them for support/maintenance reasons.

Now what.

> Both the problems you mention are certainly well-known deficiencies of
> type-classes. But, we continue to use type-classes because they are
> still so darn useful, and the problem cases arise infrequently enough
> that they are not show stoppers.

Perhaps. But I *suspect* (without proof) that the reason these issues
remain "minor" is that languages with type classes have yet to be used at

I'm leaving out a lot of details here.. because I have forgotten them,
> or never knew them in the first place. This is really more of a
> question than an answer.. I have often wondered if Agda's solution
> would ultimately make me happier than Haskell's type-classes.

Their solution sounds a lot like Bob Harper's approach, and (separately)
similar to something I've been considering. I'll look into it. Thanks for
the pointer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20120409/702f74e5/attachment.html 

More information about the bitc-dev mailing list