On Mon, Mar 22, 2010 at 3:16 PM, Rick Richardson <[email protected]>wrote:
> 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" > That's how I read it, though it took me a few reads to see that. > The definition goes on to describe additional methods which are closed > around the result of the constructor. > Yes. > 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. > Yes. I mis-spoke. What I meant was a class whose instances are explicitly instantiable (as opposed to the implicit objects). 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. > > >> 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. > Yes. > 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. > 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. > But in the context where I'm thinking about implementing single inheritance, we **want** the ability for a type to depend on another type... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
