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 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
