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

[wren ng thornton]

On 4/8/12 8:28 PM, Sandro Magi wrote:
> The only problem with this solution is that you lose the natural
> isomorphism with the original Foo, so this requires "wrap/unwrap" at the
> coercion boundary. Two possible solutions to this:

There are a number of facilities to help with that issue. Among them,

 
http://hackage.haskell.org/packages/archive/newtype/0.1/doc/html/Control-Newtype.html

which has the very helpful "ala" function to keep things clean and 
declarative.

For many situations newtypes are indeed sufficient. In fact, they're 
better than allowing multiple instances because they make explicit the 
types involved (and I mean "types" in the colloquial or philosophical 
sense, rather than what compilers see per se). It's far better than the 
C approach of just calling everything "int" simply because it happens to 
be represented by a machine word.

However, there are situations where using newtypes isn't pretty. In 
particular, it's the cases where you want to use multiple instances at 
the same time. With ordering relations, no matter which ordering we have 
in mind for a particular implementation task, by and large we only care 
about one ordering for that particular set of data. In this case, using 
newtypes or named instances is perfectly fine. However, now consider a 
type class for some abstract algebraic concept like Semigroup, Monoid, 
Group, etc. We very often want to combine multiple of these instances 
and use them together; for example, we have two (to four) any time we 
talk about a semiring, ring, field, lattice, etc. Even worse, many times 
we want to use multiple (e.g.) semirings in the same hunk of code; for 
example, switching between the (+,*) semiring and the (max,*) or (min,+) 
semiring when dealing with probabilities or path weights. In these sorts 
of situations both newtype wrappers and explicit passing of named 
instances run into problems (though named instances fare a bit better in 
the multiple semiring example). I've used abstract algebra as the 
example since that's what I'm familiar with, but there are analogous 
problems in any other situation where you have multiple interacting 
instances of the same class.

That all is just in the Haskell context. In the BitC context there's the 
additional constraint about making allocation explicit. I'm not sure 
what sorts of issues that'd introduce for the newtype approach. Does/did 
BitC even have newtypes as such? They're one of my favorite features of 
Haskell, but even Mark Jones dropped them from Habit.

-- 
Live well,
~wren