[Python-3000] my take on "typeclasses"

[Marcin 'Qrczak' Kowalczyk]

Talin <talin at acm.org> writes:

> For any two predicates A & B, comparing them will produce one of four 
> possible outcomes:
>
>     1) A is a superset of B. In other words, any object that meets the 
> criteria for B also meets the criteria for A.
>     2) B is a superset of A.
>     3) Neither A nor B overlap. So an object that meets the criteria for 
> A can never meet the criteria for B and vice versa.
>     4) There may or may not be some overlap between A and B.

I'm afraid that most practical cases would yield 4.

For predictably behaving libraries, rules of prioritizing specializers
must be clearly defined. Otherwise there will be issues like "how do I
teach Python that a matrix is not a number (even though it has arithmetic
operators) and not a mapping (even though it has indexing), so Python
doesn't try to apply specializations designed for numbers and mappings?",
or "how do I teach Python that compressed streams are a subtype of
file-like objects, so it chooses specializations of the former instead
of reporting a conflict?".

>        -- lenient method: Use a heuristic to determine which predicate
>           accepts the smaller number of possible inputs.

Heuristics make sense in optimization. Heuristic dispatch would be evil.

>> When such concept is called to test the claim against an object,
>> how does it determine whether the object is a function which takes
>> an iterable and an int?
>
> By looking at the function's signature information.

What if there is none (which is quite a common case)? The function
is not applicable to this argument, the dispatch doesn't choose this
specialization etc.? Then type signatures are no longer optional,
functions constructed by generic wrappers rather than written by hand
(e.g. partial applications) must provide some other means to specify
the signature, and this is quite a radical shift towards a paradigm
that I don't think Python would like.

> (By the way, I did mention that this was a "sketch", which means
> that it doesn't have all the details worked out yet.)

I claim that it's impossible to base sane details on this basis.
You can't have type information which is at the same time:
- flexible, so it can test arbitrary predicates
- with a computable inclusion relation, so it can be used for dispatch
- optional, so people can continue to write functions without type
  annotations
- predictable and explicit, so people can easily determine which
  interfaces are supported by which types
- implicit, based on duck typing, so capabilities are compared by
  structure rather than by name
etc.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/