Sounds like a good question for LtU. One of the paper's authors replied in that thread, so you could get a fairly authoritative answer.
For me, the compelling aspect of that paper is the unification of algebraic types, explicit and implicit overloading expressed with a straightforward syntax. I rather dislike all the different typing mechanisms that have grown in Haskell, so this is a nice step towards a more refined typing mechanism that operates along a continuum, rather than disjointed mechanisms forcing an (often poorly informed) choice early in the design process. Refactoring a codebase with type refinements thus seems easier in this unified framework. The easier migration it provides for programmers coming from other OO languages is icing on the cake. Sandro On 11/03/2010 3:51 PM, Jonathan S. Shapiro wrote: > So I've now read the "Objects to Unify Type Classes and GADT" paper > twice, and gone back to review several earlier GADT papers as well. > > Most of what is here appears to be expressable in BitC already. We have > a notion of a sealed type class, for example. We don't currently handle > GADTs, but that's a straightforward extension that clearly needs to be > done eventually. > > I think what I am struggling with is the implicit vs. explicit object > notion. So far as I can tell, the difference is that explicit objects > instantiate their class's type variables, and in doing so, form a > representation. Implicit objects instantiate *none* of their class's > type variables, and thereby serve as constraints only, wherein the > ability to instantiate an object of the appropriate class type (which is > stateless and therefore costs nothing to instantiate) serves as witness > of membership in the class relation. > > Is there something here that is more complicated that this? If not, why > isn't this just syntactic sugar for things we already have? Not bad > syntactic sugar, and worth considering from that perspective, but is > there something new here? > > I feel like I'm missing something important. > > > shap > > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
