On Tue, Mar 23, 2010 at 10:57 AM, Rick Richardson
<[email protected]> wrote:
>>
>> 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.
>
> I see what you're saying. I would argue that no class in their system is a
> type. None can have instances. They are open. They are a collection of traits
> to be ascribed to whatever values an object would see fit.
> Sealed classes, on the other hand, are closed, they can also imply additional
> constraints in their methods/objects. They should be directly instantiable.
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.
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
points.
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.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
