[bitc-dev] Instance coherence: the shape of a solution
naasking at higherlogics.com
Mon Apr 16 12:18:52 PDT 2012
On 16/04/2012 2:22 PM, Jonathan S. Shapiro wrote:
> And there's actually an advantage to the procedure approach, because it
> /doesn't/ bind the choice of ordering into the type of the BTree. This
> leaves us free to implement a merge function that doesn't care about the
> orderings of the input and update trees.
There are numerous advantages to function parameter approaches, namely
that functions are first-class and type classes are not. That said, if
you support both type classes and functions, you end up with a lot of
duplication, ie. Haskell's "sort" and "sortBy" variants.
"Objects to Unify Type Classes and GADTs" went a long way to eliminating
this duplication. The reason type classes are so attractive is twofold:
1. Implicit instantiation.
2. Sets of overloaded methods whose invariants must be coherent are
Scala's implicits  might give you #1 with the scoping you desire. #2
still seems like an attractive property as well, however #2 is within
the domain of a module system. So then you're faced with a choice of
whether to create a type class or a module signature.
If that's going to be a concern for you down the road, then you'll be
interested in the work to provide the implicit resolution of type
classes as an idiomatic use of modules . You'll be particularly
interested in section 3, since 3.1 is "coherence in the presence of
More information about the bitc-dev