On 04/04/2011 2:21 AM, Jonathan S. Shapiro wrote: > Second, it's important to note that no current language defines any > interface notion on structs (as opposed to classes). This means that an > interface object, and the class instance that it wraps, are reference > types. This has *huge* implications for compilation.
Haskell supports unboxed types, but I'm not clear whether this extends to type classes. If it doesn't, this would be an artificial limitation, not an intrinsic one. The same representation issues are at work in any OO/interface abstraction you're going to introduce. > The real question is inheritance. In what ways is inheritance > useful? From what I can see, it's most useful application are > default implementations of methods. But this can be provided by type > classes as well. Subtyping too. > > Q1: How is this provided by type classes when there is more than one > level of derived class? What's meant by level? Do you mean class/interface inheritance? Haskell sports many levels of inheritance among its standard type classes. > Q2: How is subtyping provided by type classes? Type classes support inheritance, and if I understand correctly, are implicitly coercible to super types when required. That's a subtyping relation at the level of the interface/overloads. Perhaps you have a specific subtyping relation in mind? This certainly isn't a nominal subtyping relation, but I haven't heard any convincing arguments for nominal *subtyping* (nominal typing at the module level is needed). What subtyping properties are you after, specifically? > So type classes are strictly more general than inheritance and > interfaces. Only downcasting/upcasting isn't provided by default, > but has been provided by libraries. > > > Pointer to papers on "provided by libraries"? http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Data-Typeable.html See also all the papers published on generics and dynamics for Haskell. Data.Typeable isn't the most flexible, but perhaps the most common being in the standard library. Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
