[bitc-dev] Explaining inheritance vs. type classes
naasking at higherlogics.com
Tue Mar 23 12:47:42 PDT 2010
On 23/03/2010 3:03 PM, Jonathan S. Shapiro wrote:
> The fact that they are open does not inherently prevent them from
> being types, and the "object" definition mechanism in Oliveira and
> Sulzmann does create instances of a previously declared class (though
> there is an existential component in the closed-over state).
> What has me puzzled is that I cannot tell from the Oliveira/Sulzmann
> class declaration whether a class type will be inhabited. We don't
> know whether the class is instantiable until we see the constructor on
> the associated object definition. Though perhaps the presence of the
> so-called implicit instantiations is sufficient, and of course if the
> type is fully uninhabited in a given program it will never be
> instantiated and then we don't care very much in the context of that
> particular program.
Consider the "class" in this paper as an enhanced C# interface. As you
say, where you only see "Set 'a", you don't really care what specific
instantiation was used, you only care at the point of instantiation.
You can view the class as a type by considering it as an implicit
existential paired with its dictionary. The focus on interface-style
abstraction is very good for reuse, as compared to traditional OOP
> And yet, Oliveira/Sulzmann treat these classes as types.
> Okay. I finally think that I see it. They state that classes always
> attached to a dictionary variable (and I might add that the facility
> to *name* the dictionaries is very useful). In this view:
> - The class definition is, in effect, a structure definition for
> that dictionary.
> - The object definition instantiates a new copy of that dictionary type, whose
> elements are closed over some state.
> The resulting model lies very strongly in the "objects are defined by
> behavior, not representation" camp, which has good points and bad
> Their scheme remind me of one of my early confusions about type
> classes. When type classes take only a single variable, it is tempting
> to think that "Set 'a" is a type. Only when they take multiple
> variables does it become clear that this is not a good view (or when
> you start applying multiple classes). It was confusing mainly because
> I was starting from the C++/Java intuition about classes.
Yes, and this paper brings that view very closely in line with that
intuition, but with better defaults. This type system is very close in
spirit to Scala in fact.
More information about the bitc-dev