[Python-Dev] type categories

[Andrew Koenig]

>> Why?  That is, why can't you imagine making a claim that type
>> X meets interface Y, even though the author of neither X nor Y
>> made that claim?

Oren> It's not a failure of imagination, it's a failure of
Oren> terminology. In contexts where the term 'interface' is used
Oren> (Java, COM, etc) it usually means something you explicitly
Oren> expose from your objects. I find that the term 'category'
Oren> implies something you observe after the fact without modifying
Oren> the object - "these objects both have property so-and-so, let's
Oren> group them together and call it a category".

But what if it is possible to express property so-and-so as an
interface?  It's like observing that a particular set, that someone
else defined, is a group, so now all the group theorems apply to it.
Similarly, if someone has defined a class, and I happen to notice that
that class is really a reversible iterator, I would like a way saying
so that will let anyone who wants to use that class in a context that
requires a reversible iterator to do so.

>> However, now that you bring it up... One difference I see between
>> interfaces and categories is that I can imagine categories carrying
>> semantic information to the human reader of the code that is not
>> actually expressed in the category itself.  As a simple example,
>> I can imagine a PartialOrdering category that I might like as part
>> of the specification for an argument to a sort function.

Oren> You can define any category you like and attach a semantic
Oren> meaning to it as long as you can write a membership predicate
Oren> for the category. It may be based on a marker that the type must
Oren> have or, in case you can't change the type (e.g. a builtin type)
Oren> you can write a membership predicate that also tests for some
Oren> set of specific types.

Or perhaps a membership predicate that tests whether a type satisfies
a particular interface.

Oren> A category is defined mathematically by a membership
Oren> predicate. So what we need for type categories is a system for
Oren> writing predicates about types.

And, perhaps, a way for defining predicates that determine whether
types meet interfaces.

>> Indeed, that's what I was thinking about initially.  Guido pointed
>> out that the notion could be expanded to making concrete assertions
>> about the interface to a class.  I had originally considered that
>> those assertions could be just that--assertions, but then when
>> Guido started talking about interfaces, I realized that my original
>> thought of expressing satisfaction of a predicate by inheriting it
>> could be extended by simply adding methods to those predicates.  Of
>> course, this technique has the disadvantage that it's not easy to
>> add base classes to a class after it has been defined.

Oren> That's why the intelligence should be in the membership
Oren> predicate, not in the classes it selects. Nothing needs to be
Oren> changed about types.  Conceptually, categories apply to
Oren> *references*, not to *objects*.

I don't see why categories should not also apply to class objects.

Oren> They help you ensure that during execution certain references
Oren> may only point to objects from a limited category of types so
Oren> that the operations you perform on them are meaningful (though
Oren> not necessarily correct). A situation that may lead to a
Oren> reference pointing to an object outside the valid category
Oren> should be detected as early as possible. Detecting this during
Oren> compilation is great. On module import is good. At runtime it's
Oren> ok.

Agreed.

Oren> Can you can think of a better name than 'categories' to describe
Oren> a set of types selected by a membership predicate?

Not offhand.

-- 
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark