On Mon, Aug 26, 2002 at 03:51:13PM -0400, Andrew Koenig wrote:
Oren> Can you give a more concrete example of what could a cartesian Oren> product of type predicates actually stand for in Python?
Consider my TotallyOrdered suggestion from before. I would like to have a way of saying that for any two types T1 and T2 (where T1 might equal T2) chosen from the set {int, long, float}, < imposes a total ordering on values of those types.
Come to think of it, that's not really a Cartesian product. Rather, it's a claim about the members of the set union(int,union(long, float)).
Isn't it easier to just spell it union(int, long, float)? Your example helped me make the distinction between two very types of type categories: 1. Type categories based on form: presence of methods, call signatures, etc. 2. Type categories based on semantics. Semantic categories only live within a single form category. A method call cannot possibly be semantically correct if it isn't well-formed: it will cause a runtime error. But a method call that is well-formed may or may not be semantically correct. A language *can* verify well-formedness. It cannot verify semantical correctness but it can provide tools to help developers communicate their semantic expectations. Form-based categories may be used to convey semantic categories: just add a dummy method or member to serve as a marker. It can force an interface with an otherwise identical form to be intentionally incompatible to help you detect semantic categorization errors. The opposite is not true: semantic categories cannot be used to enforce well-formedness. You can mark a class as implementing the "TotallyOrdered" interface when it doesn't even have a comparison method. A similar case can happen when using inheritance for categorization: a subclass may modify the call signatures, making the class form-incompatible but it still retains its ancestry which may be interpreted in some cases as a marker of a semantic category. Oren