> > What I think I was really saying is that in some peculiar sense, those > classes whose instances do *not *close over something aren't quite types, > but it isn't clear from the class declaration which ones are which. >
I see what you're saying. I would argue that no class in their system is a type. None can have instances. They are open. They are a collection of traits to be ascribed to whatever values an object would see fit. Sealed classes, on the other hand, are closed, they can also imply additional constraints in their methods/objects. They should be directly instantiable. They made classes more general than Haskell's typeclasses. And they made objects more general than instances or datatypes. This was, IMO, to make GADTs a more natural fit for the language. In Haskell they are wedged in and rather restricted, since they have the generality of typeclasses, but are dictionaries. My assumption that the additional constraints would be added via >> aggregation instead of inheritance, and do so at the object level. If I >> understand you correctly, this should address the heart of your confusion. >> > > You can't do this at the object level. It has to be a property of the > result type, therefore of the class. > Sure you can. It doesn't have to be a property of the result type, it just has to be accessible at the point that the parametric types are realized. The constraint of Eq a specified by the constructor guarantees that an instance of Eq for type a must exist or it won't type check. The resulting instance would close around both the methods described in the object as well as any implicit (or explicit) object instances required to fufill the constraint(s). If we specified the object as: object ListSetPlus :: Eq a, Eq (Set a) => [a] -> Set a then in order to compile, there must be an accessible implicit object EqSet :: Eq(Set a)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
