On Mon, Dec 30, 2013 at 9:21 PM, Ben Kloosterman <[email protected]> wrote:
> > > On Sat, Dec 28, 2013 at 3:55 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> >> So given a notion of method type (as opposed to function type) and the >> ability to express a has-field constraint, it turns out that type classes >> subsume traits *up to* inheritance. Actually, type classes are strictly >> more powerful than traits, because they are type relations. This means that >> they can express *provides* and *requires* constraints across multiple >> types simultaneously. Not sure if that's useful, but from a language design >> perspective it's nice when one thing eliminates the need for another. In a >> language with type classes and object methods, traits are just syntactic >> sugar. >> > > So if you have classes w obj methods what does traits really give us over > just interfaces ? > I've read the original traits paper, but the concept may have evolved since then. On reflection, the description in the original paper is flawed, because a Trait is merely a type declaration. Here's what I *think* the real difference is: - An Interface type IT defines a set of methods that must be supplied by (or on behalf of) an underlying object. Objects of type IT implement all of these methods. - A Trait type TT defines a set of methods that must be supplied by (or on behalf of) an underlying object. These are divided into "provided" and "required" methods. Objects of type TT implement only the *provided* methods. The reason that the required methods are useful is that they allow a Trait type declaration to provide default implementations of the provided methods. Otherwise I'm not really sure that I see the point of them. But I may be missing something here, because that's *such* a small difference that I wonder what I'm not seeing. The other significant difference is that the relationship between Trait methods and the corresponding methods on the underlying objects is always stated explicitly at the trait implementation. But that doesn't strike me as a rocket science kind of a distinction; we could do that for Interfaces as well. They give you "type methods" on the trait type ( which allows an ordered > diamond pattern inheritance for better or worse)... > What do you mean by a "type method"? > The missing piece here is that type classes are not types. Which raises >> the question: well, why are Traits types then? The answer is that Traits >> tacitly assume a 'this type, and the trait itself is effectively an >> existential wrapper of that. But Bruno Oliveira's work suggests that type >> classes can be viewed as types. And if nothing else we can certainly >> recognize those type classes that are equivalent to traits. >> > > Isnt it better to just have the typeclass that has a "this" as the sugar ? > Isnt HasMethod ( not sure on HasField) really a constraint that implies 1) > a type that has this and 2) has a method of that name . > No. A typeclass instance isn't an object. It's a compile-time literal constant. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
