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 grouped together. Scala's implicits [1] 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 [2]. You'll be particularly interested in section 3, since 3.1 is "coherence in the presence of scoped instances". Sandro [1] http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf [2] http://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
