> 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
this changed?


Reply via email to