[Python-3000] my take on "typeclasses"

[Talin]

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.

-- Talin