[bitc-dev] Explaining inheritance vs. type classes
Jonathan S. Shapiro
shap at eros-os.org
Mon Mar 22 19:41:40 PDT 2010
On Mon, Mar 22, 2010 at 3:16 PM, Rick Richardson
<rick.richardson at gmail.com>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.
> 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.
> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev