On 10/26/05, Larry Wall <[EMAIL PROTECTED]> 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.
We're screwing around with existing OO jargon, so it's probably not
too bad to screw around with this one too, especially since it only
appears under the covers in ML.
A kind is the "signature" of a type. So, for instance,
Int has kind *
Array has kind * -> *
Array Int has kind *
Other than that, I think the term works find.
> 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,
Don't you mean $x.kind eqv $y.kind?
Ugh.
> but $x.kind isn't a class-like
> object, only an identity of some sort. $x.meta returns the Class
> instance, or whatever.
>
> At the moment, I think the weakest word choice is "subtype".
> People from certain cultures will confuse subtypes with subclasses.
> The notion of constraints or limitations is already conveyed by
> "where", and some subtypes may just be aliases. Plus, as we've defined
> them above, subtypes are the most generic type you can name in Perl.
> So maybe we should go with "type"...which is yet another thing I've
> waffled on repeatedly...
"constrained type"? Though that only works for the literature, not
Perl's active vocabulary.
Luke
