[bitc-dev] Retrospective: The Issues with Type Classes
jeremy at n-heptane.com
Mon Apr 9 14:24:28 PDT 2012
On Mon, Apr 9, 2012 at 12:16 PM, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> 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>
>> > 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.
Well, that is easy. They just create an orphan instance in their code.
It's not a problem until they rely on another library that contains a
conflicting orphan instance. If the conflicting instance does the same
thing as their locally defined instance, then they can just remove
their conflicting instance and go merrily on their way. If your
instance needs to behavior differently, you can hack around it via a
The place where you really run into trouble is when you depend on two
libraries which both contain an orphan instance for the same type.
There is nothing you can do to work around that, AFAIK. And, that is
part of what makes orphan instances risky. On the other hand, that has
never happened to me in 10 years of Haskell programming. So, that is
probably why there isn't much clamoring to do something about it.
The working around in this case is that someone should put the orphan
instance in a new package that everyone can depend on.
> 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 scale.
Possibly. Also, I can't think of any closed source Haskell libraries.
Almost all the code is open-source, BSD3 licensed, and on Cabal.
Generally, when people need an instance, they send a patch to the
appropriate author, and then the instance is added. Or they create an
orphan package and upload it to hackage. As a result, the community is
able to route around a language deficiency problem.
The only time I have ever had problems with orphan instances is when I
add an instance in my app because some library didn't think to, and
then later they add an instance. And, the fix then is to just delete
my instance. Sure, my code broke because they added an instance. But,
my code could have just as easily broken because they change the type
signature for some function I am calling.
In any case, the conclusion is the same. type-classes are broken in
theory, but for the time being, they work well enough that only a few
people are burning with desire to fix it.
More information about the bitc-dev