On Mon, Mar 22, 2010 at 12:55 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Mon, Mar 22, 2010 at 10:57 AM, Pal-Kristian Engstad > <[email protected]> wrote: > > In this context, I'd highly recommend reading: Objects to Unify Type > Classes > > and GADTs, by B. Oliviera and M. Sulzmann. It might provide the answer to > > your question. > 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 ... 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 ... 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. 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 ... 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? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
