[Python-3000] my take on "typeclasses"

[Bill Birch]

On Wed, 10 May 2006 08:46 am, Talin wrote:
> Michael Chermside <mcherm <at> mcherm.com> writes:
> > Talin writes:
> > > Lets start a new top-level thread to discuss this specific
> > > proposal.
> >
> > tomer filiba writes:
> > > i'm sure my idea has flaws, but i'm very much pro-changing the type
> > > system.
> >
> >        [...]
> >
> > > types are just an ancient relic, an implementation detail if you wish,
> > > that was brought from static languages, but is not appropriate to
> > > dynamic languages. static languages NEED types in order to produce
> > > machine code, dynamic languages don't, so a different mechanism is
> > > needed here, imho.
> >
> > I think the idea of creating a new language with some of the wonderful
> > syntax of Python along with the wonderful type system of Haskell sounds
> > GREAT! I would be very interested, and would like to join in the
> > discussion.
> >
> > But I don't think it belongs in the Python-3000 discussion group. Can
> > this discussion be moved elsewhere? Python 3.0 is going to have types,
> > and they're going to look very similar to the types in Python 2.X --
> > a brand new language would be a separate project.
>
> Ordinarily I would agree with you on this point, and in fact I
> wouldn't even bring it up at all, except for two data points:
>
> 1) The proposal to include generic function dispatch
>    in Python 3000, based on explicit typing.
>
> 2) The proposal to remove all forms of type testing
>    other than those based on isinstance() (in other words,
>    removing callable, isSequence, isMapping, etc.)
>    (I'm not including attribute testing here because its
>    neither standardized nor systematic.)
>
> The net effect of these proposals is to greatly strengthen
> the capabilities of explicit typing, while seriously crippling
> the use of duck typing. By putting a much greater emphasis on
> explicit typing, we're effectively moving Python away from the
> implcit "duck-typing" that we've known up to this point.
>
> So essentially Python is *already* becoming a different
> language, whether we like it or not.
>
> I think that I agree with the gist of Tomer's point. I'm not
> going to claim that types are useless, but I think we should
> think about ways of dispatching other than types.
>
> What would seem very 'Pythonic' to me would be a system
> whereby objects can not only be dispatched on their
> types but also their *capabilities*. Thus, instead
> of asking the question "Is this a sequence?", we ask
> "Can this be iterated?"
>
> In such a model a "sequence type" would simply be a
> set of capabilities that often occur together.
>
> I think at the very least, we need a way a better
> definition of a "capability", and a formalized way
> to test for its presence. Whether or not that is
> directly wired into the dispatch mechanism (which would
> be cool) is another issue. Certainly attribute testing
> is part of it, but there needs to be agreement on which
> attributes to test.
This idea of capability is described in the literature using other words. 
(Reference below.)  When types are viewed as predicates defining sets of 
objects they can accommodate all wishes, including multiple inheritance. 

Note that GvR and type-sig had abandoned compile-time type -checking-, this 
being left to IDEs. That's why the current proposal is for -optional- type 
checks.

Tomer's complaints about 'types' all relate to the (now outdated) nominative 
type systems. Modern functional languages have structural subtyping. IMVHO 
Python's duck typing is structural subtyping. A question for Py3k is whether 
ir supports structural equivalence or nominative subtyping in the new type 
annotations. 

A simple test to see where your thinking is at. Consider:

interface I1:
    def foo(a: t1, b: t2) -> t3:
        "docstring"

class C(I1):    # implements I1
    def foo(a, b):
        return a+b

class D(object):    
    def foo(a: t1, b: t2) -> t3:
        return a+b

The manual for isinstance() says: "return true if classinfo is a type object 
and object is an object of that type". So consider this:

	 isinstance( D(), I1 ) 

Is this True or False? 

--- references:
http://www.artima.com/weblogs/viewpost.jsp?thread=87182
http://citeseer.ist.psu.edu/cardelli85understanding.html
http://billbirch.wordpress.com/