I'll try to add my take, forgive me but I don't know enough of BitC's syntax to translate into its terms. Also, I tend to think to think of their classes as typeclasses, and and I tend to interchange the idea of a typeclasses contstraints and a classes interface.
> Following up on this, I have some further confusion about Bruno and > Martin's work. > > Let's go back to the definition of "Set 'a". Conceptually, I do not believe > that it is possible to define a correct "Set 'a" for which 'a does not > satisfy "Eq 'a". The type as stated clearly works fine, but one of the > conceptual points of "Set 'a" is that no set contains two distinct but equal > elements. > > If this is so, then I think the correct declaration must be: > > Eq 'a => class Set 'a where ... > I tend to agree, but I think they omitted that for purposes of showing how it is mixed in later. > > Initially, I wrote an (incorrect) alternative: > > class Set 'a :: Eq 'a where ... > > which (syntactically, at least) suggests the possibility of class > derivation. In general, if we have something of the form: > > class A 'a :: B 'a where ... > > I think the important thing to keep in mind is that the first line of object is the definition of a value constructor. It seems easiest to read "object ListSet :: Eq 'a => ['a] -> Set 'a" as "ListSet is a type of Set 'a where 'a is in the typeclass Eq" But I think that's incorrect. The coupling is actually more loose than that, we're saying: "ListSet constructs an instance of Set 'a where 'a is in the typeclass Eq" The definition goes on to describe additional methods which are closed around the result of the constructor. > then we are saying that all things of type A 'a must also be things of type > B 'a. But we are left with a deficiency in the specification of "object", > because we have no way to discharge this requirement within the constructor. > Also, we don't really know (given Bruno and Martin's syntax) whether B is an > explicitly instantiable class. > I believe that their model states that no class is explicitly instantiable. The classes simply describe 'traits' which would be present in any object which includes them. This is similar to 'traits' in Scala, and marginally related to 'categories' in smalltalk or obj-c. > Perhaps equally interesting, we would like a way to say that sets should be > comparable for equality, in which case we might want to be able to say > > class A 'a provides Eq A 'a where ... > I think that this could be part of the typeclass system, but the authors seem to omit this. 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. If I needed to specify such an arrangement, I would write: object Matrix :: Eq (Set a), Eq a => [[a]] -> Set Set a That seems easy enough. The fun part comes next, not where I'm describing constraints, but implementing the Set methods. Could I just state my constructor as ... => [ListSet a] -> Set ListSet a then utilize the ListSet methods? I would assume so, since I've stated that the input to my object conforms to the same constraints as required by ListSet. > Presumably the implementation supplied in any instance of A must satisfy > the requirements of both classes. > > I'm obviously making up a syntax here, but this gets me to a tricky point. > Suppose we have two classes A and B in this sort of relationship, both of > which demand some method "meth". What are the simultaneous requirements in > this case? Have we just re-invented derivation and (perhaps) virtual > functions? > I took a different route in my interpretation, but I think that my interpretation circles around to address these issues. That is to say that there should never actually end up in such a scenario where a type depends on another type. Instead we simply aggregate constraints as we define objects. If we need to rely on the presence of methods, then we do it in objects, not typeclasses. That's my take at least. I could be way off. Rick Richardson
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
