Geoffrey: Good question. One of the problems we have with the BitC mailing list is that these discussions happen on the list and then later we can't search them. I've just revised the robots.txt file on those sites to allow crawling for bing and google. Let's see if that helps.
To answer your question: 1. For a while, I had concluded that type classes flatly didn't work at all at scale. I've since come to a design position that I think will make them workable. 2. Original BitC had both type classes and "capsules" (which were at one point called objects). A capsule is very similar to an interface, except that you can't do a dynamic cast back to the original object. 3. The concern about class support is mainly driven by interoperability. But also, the main *objection* to classes from a type system perspective had been that they push us into a type system similar to F<, with all of the inference issues that carries. The thing is: once we introduce regions, we are pushed into subtype inference in *that* part of the system in any case. At some point it was sort of like "well, in for a penny, in for a US National Debt". At some point the decision was made that some sort of class support > was a more practical route. > I wouldn't say that. It was more that I was feeling pressure to succumb. Also, because classes carry their methods with them, they avoid the resolution issues that plague type classes. > The reason I ask is that (modulo issues of checked upcasts) interfaces > and type class existentials seem isomorphic. Oh no, not at all! For starters, type classes are not types. Second, the resolution rules are *drastically* different. Third: type classes do not address the need for existential where interfaces *are* an existential wrapping mechanism. In fact, it was staring at the capsule mechanism that made me realize that. Type classes with implicits is another thing. Once you can carry around a designator for a particular instance, the type class is the instance of the type. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
