[Types-sig] "Concrete types"

[Paul Prescod]

I think that there is an important point hiding in the middle of a long
message. :)

Marcin 'Qrczak' Kowalczyk wrote:
> 

> Because an interface rarely says anything about the representation.
> Other types supporting the same interface should be generally accepted
> where lists are accepted. ListType says too much about an object.
> Python has exceptions to this. Many builtin types require other builtin
> types, e.g. __dict__ of a builtin class object must have the builtin
> dictionary type. It's slowly shifting to allow more generality, but...
> 
> ...concrete types must be finally used somewhere. You can express
> an abstract interface of an integer, but you can't express every
> abstract interface in terms of other abstract interfaces. Finally
> some real work must be done besides message passing.
> If you try to express pure Smalltalk model in Haskell:
> 
>     newtype Object = O (String -> [Object] -> IO Object)
> 
> then you can't do anything useful unless you encode data in method
> names, because the only thing you can do with an object is to send
> it a message, so you can't know which damn integer number an object
> represents to implement arithmetic or to index a sequence. Some
> objects or some messages must be special.
> 
> There is a balance between concrete and abstractness. It's impossible
> to be completely abstract, and should not be completely concrete
> because it's very painful to use (as in C and Pascal).

This is an excellent point. We should not go overboard and require that
everywhere an integer can be used an integer-like object should also be
usable. This is not reasonable for objects that are only ever worked
*on* and have no intrinsic behavior or their own.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.activestate.com/pythoncookbook