On Thu, Feb 3, 2011 at 3:22 AM, Ben Kloosterman <[email protected]> wrote:
> Firstly I dont think Type-class as a relation between types is the correct > definition for things like Ord or Eq while you could bang them in that box > , since they list what a type must implement to be a member these seem more > like a abstract base class or an interface for the type. > That's one view, but that view is persuasive primarily because these are single-variable type classes. If we conclude that all "interesting" type classes are single variable, then the universe devolves into exactly what you suggest. Further, I'm coming to think that a (seemingly) independent issue may push in this direction as well. We've concluded that the notion of "readonly" and "mutable" on objects are integrity issues rather than access issues. The inference is that we need some sort of permission system that distinguishes "caller" procedures from procedures tasked with maintenance of integrity (which are generally member functions). What will happen if we head down this path is that the mere *existence* of member functions will, in effect, push us in the direction of single-variable type classes. And that, in my view, is mostly okay. It resolves an awful lot of the overloading mess, for example. But if we go down this path exclusively, there are some things that we lose: 1. The ability to establish mixin-like classes retrospectively. As a third-party developer, it is hard to extend your class to accept my trait, even if I am prepared to explain the extension. This is something that type classes do very well. 2. We lose the ability to deal with the fact that virtual functions don't really solve some problems. As a classic example, I'ld identify the SmallTalk Number hierarchy, where Number is a common base class that defines +/-/... and the subclasses implement it. The problem with this is that you end up forced to implement an all-pairs solution for arithmetic. What does it mean to add complex to bounded-precision integer, exactly? So at a minimum, I think that the notion of Interfaces/Traits is essential. So with that said, it also has to be said that when I look at the multi-variable type classes that actually work in practice, almost all of them are compiler-derived properties: HasField, CopyCompat, and so forth. The one exception that stands out in my mind is the future handling of Array<T, Nat>, but that's really a type constructor rather than a type class. But even if we restrict ourselves to single-variable classes, issue [1] above will remain alive. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
