On Wed, Mar 24, 2010 at 8:50 PM, Sandro Magi <naask...@higherlogics.com> wrote: > Type classes are restricted to virtual methods because type classes are > intended purely as a specification of overloadable behaviour.
Yes. But if you were trying to truly unify conventional classes and type classes, this restriction isn't really necessary. It can be preserved as a matter of idiom rather than as a matter of language constraint. >> Now if all of this is the case, then we must ask whether we shouldn't >> just allow fields in [type] class definitions... > > A Haskell data type can have instances for multiple type classes. If > this is not permissible in your framework, then they're not type > classes. If it is permissible, what do you do when two different type > classes have the same field name? Seems like you run into multiple > inheritance issues here. Good point. I wasn't stuck on fields. Just playing with the idea to see where it broke. > I'm not actually convinced the overhead of type classes is really a > problem. A type class is an extreme abstraction mechanism, so employing > it implies the abstraction is needed. Umm. When something as foundational as "Eq 'a" is a type class, it's not an extreme mechanism any more. It's foundational, and it needs to be low-overhead. shap _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
