On Wed, Oct 26, 2005 at 03:54:35PM -0400, Rob Kinyon wrote:
: > So maybe we can define our terms like this:
: >
: > type: a completely generic metaterm for any of the following,
: > and then some.
: >
: > class: a mutable interface object that manages instances in the
: > "classical" way, with covariant derivational properties.
: >
: > role: an immutable and possibly generic interface class, with
: > covariant compositional properties.
: >
: > kind: the abstract, often unnamed type of an actual instance
: > or storage location, abstracted from any of its machinery or
: > degree of definedness. You should not generally declare a "kind",
: > they just happen.
: >
: > subtype: a potentially contravariant type based on any of the
: > previous types, allowed to impose constraints that are more
: > selective than a kind is allowed to be.
: >
: > Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks
: > if two objects are of the same type, but $x.kind isn't a class-like
: > object, only an identity of some sort. $x.meta returns the Class
: > instance, or whatever.
:
: A few questions:
: 1) Where does prototype-style OO fit into all of this? I hope it's not
: through repeated eigenclasses (or whatever they're called this week)
: ... that just sounds too heavy.
I don't profess to be an expert on prototype style, but I think even
if we do it with eigenclasses it's not too heavy as long as we find
a way to share structurally identical eigenclasses. Copy on write
would get some sharing benefit, though wouldn't coalesce eigenclasses
that just happened to converge on the same definition.
On the other hand, I think we can abstract out kindness sufficiently
well that, for the prototype kind of object, the machinery can just
clone the method refs along with the attributes.
: 2) Isn't Dog|Cat kinda declaring a kind?
If it resolves to a set of types, it can be *used* as a kind. But if
you insist on the ORness of it, then it's really a subtype, because
a kind supports all of its member roles, not just one of them.
: Thus, can't you say "my Dog|Cat $catdog;" and be talking about a kind?
No, that merely asserts that the kind of $catdog must support those
two interfaces, assuming | just constructs a set.
But it's not clear that we'll support | there at all, but assuming
AND juxtapositional syntax, we can just write that:
my Dog Cat $catdog;
and get the same constraints on $catdog. And the fact of the matter is
that either of Dog or Cat may be a constrained subtype, not a real kind.
If we say
my Even Odd $evenodd;
then we'll never match our constraints, despite the fact that Even and Odd
are both subtypes of Int, and Int can function as a kind.
: I would think that a "named kind" is just a role ...
No, other way around, a role is just a named kind. More precisely,
a non-generic role can be forced to compose to a class that can
function as a kind. But there can be kinds that don't behave well
according to the rules of roles. You can't compose two kinds that
happen to represent native types, for instance.
: 3) Aren't classes mutable and roles immutable by default only? Or has
: this changed?
Of course. To change the default for a role, call it a class, and
to change the default for a class, call it a role. :-)
Larry
