[Python-3000] PEP 3100 Comments

[Talin]

Phillip J. Eby wrote:
> At 06:19 AM, 9 May 2006 +0000, Talin <talin at acm.org> wrote:
> 
> In Haskell, interfaces are defined using "typeclasses".  A typeclass is 
> basically a collection of generic functions.  For example, you could 
> define a "sortable" typeclass that includes the generic functions for 
> "less than" and "equal to".  You can then define a function as taking a 
> "sortable" parameter, and it then accepts only values that can be passed 
> to "less than" and "equal to".
> 
> Further, Haskell has a concept of "typeclass instances" which basically 
> give you adaptation.  For example, suppose I have some generic functions 
> other than "less than" and "equal to", that do basically the same thing 
> for some set of types.  For example, maybe there's some library that has 
> "lt" and "eq" functions.  I can define typeclass instance for "sortable" 
> that maps "less than" to "lt" and "equals" to "eq" automatically.
> 
> With these two features, you get all the remaining benefits of 
> interfaces and adaptation, without any of the headaches caused by more 
> traditional type systems.  You never have to explicitly declare support 
> for an interface, unless you're effectively defining adaptation from a 
> different interface.  And anyone can easily define new subsets of 
> "dict-like" or "file-like" interfaces containing only the operations 
> they need, because these interfaces are just a collection of generic 
> functions that can be mixed and matched at will.
> 
> In Haskell, a lot of the work can be done by type inference, in that if 
> you use "less than" and "equal" generic functions in the body of a 
> method, the compiler can usually infer what types that method can thus 
> be applied to, without the need to create an explicit typeclass or  type 
> declarations.
> 
> (You couldn't get quite that implicit in Python, though; you'd have to 
> have at least explicit declaration that you wanted a "sortable" 
> parameter or a "mapping" argument.)

That's really interesting, and sounds like exactly what I want. I'd be 
interested in knowing a little more about the specifics.

Let me offer the following example as a basis for discussion, and see 
how it would work in such a system. (People who have different ideas as 
to how it should be done feel free to chime in -- I want to hear what 
other techniques are out there.)

Let's define a function called "flatten", which takes a complex data 
structure and flattens it, in other words, it transforms it into a 
single linear sequence.

Now, it would be unreasonable to say that "flatten" can handly any 
arbitrary type that is thrown at it. However, it should be able to 
handle any container type that is one of the standard "type classes" if 
I understand what you are saying.

In other words, as long as a type falls into a standard type class, it 
should be possible for flatten to work with it, even if flatten knows 
nothing about the specific type, and the type knows nothing about flatten.

How would something like this be done? Is there some way that we can do 
this in Python?

-- Talin