[bitc-dev] Explaining inheritance vs. type classes
rick.richardson at gmail.com
Mon Mar 22 15:16:03 PDT 2010
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
> 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
> 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"
"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
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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev