> 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.
2) Isn't Dog|Cat kinda declaring a kind? Thus, can't you say "my
Dog|Cat $catdog;" and be talking about a kind? I would think that a
"named kind" is just a role ...
3) Aren't classes mutable and roles immutable by default only? Or has