Python 1.6 The balanced language

[Suchandra Thapa]

Manuel Gutierrez Algaba <thor at localhost.localdomain> wrote:
>On Tue, 5 Sep  Alex Martelli <aleaxit at yahoo.com> wrote:
>>
>>You do have the notion of typeclasses in Python: "a sequence",
>>for example, or "a file-like object"; you just lack the way to
>>*EXPRESS* this notion simply, directly, and explicitly _in the
>>language itself_.  So you express it in docs & comments, but
>>those are often not as precise as one would wish (and as an
>>expression in a formal language might make things): when
>>somebody says 'you pass a file-like object', what methods are
>>going to be called on it -- write? read? writelines? readlines?
>>close?  _Good_ docs would say that -- but why not have a
>>way to say it in the language itself?
>
>No, an object that implements those methods required to be 
>considered a sequence is not a type(object )= sequence
>
>Fortunately,  the notion of objects that accomplish certain 
>behaviours is far more general and flexible than types.

    I think Alex was trying to make the point that the notion
of a type class captures the idea of specifying that a certain
object needs to have certain properties.  For example, in 
Haskell type classes are used to specify what types can be tested
for equality and to define how to test these types for 
equality (through the use of an instance declaration).

>>Now THIS is 'wasting the possibilities some functions
>>may provide' -- because the language is not expressive
>>enough to supply a notation for the typesystem it is
>>in fact using...
>
>Ok, in python apart from ints and char , we don't use types,
>not at all, we don't need them and they're ugly. If we really
>need to do some checkings we can check the properties of the
>object, that is much flexible and exhaustive than type. 

    But typeclasses capture the notion of needing certain 
properties for given types.  With static type checking, you
gain something over a runtime check since you don't need to
keep type information and don't need to deal with runtime errors.
Even with your concept of just checking for properties, you still
need to insert code into the compiled version that deals with the case
where you don't have the proper method.

>>Having a *good* typesystem need be nothing as confining as
>>that; you don't seem to have much experience using such
>>typesystems -- I strongly suggest you try out a few before
>>expressing such trenchant judgments.
>>
>
>I have programmed in C for countless years, a bit in C++ and 
>a bit in Java. And in Pascal .  And yes, I won't like types, ever.
>
>The two brightest languages that come to my mind ( LISP, python)
>don't use types. 

    C/C++, Java and Pascal don't really have good type systems.  
The compiler can't figure out types without explicit declarations.
With a good type system, your compiler can use type inference to 
figure out what types to expect and just needs explicit type declarations
at a few places as hints. For example in Haskell code like, 

data Color = Red | Green | Blue
             deriving Eq
	    
permute x | x == Red   = Green
	  | x == Green = Blue
	  | x == Blue  = Red

asking for the type of permute returns permute :: Color -> Color. The compiler
is smart enough to figure out that x needs to belong to the color type and 
that permute returns a color.  This is in contrast to C/C++ where you would
need to define permute with explicit type declarations.  If you compare this
to the equivalent python or lisp code, they are remarkably similar.
    I'm not sure what you mean by Lisp not using types.  Lisp compilers
and run time systems maintain type information for all values that they
encounter.  This can easily be demonstrated by the existence of the declaim
and declare statements which assert that certain variables have a given type.
In fact, Lisp inspired the creation of tagged type architectures where the cpu
reserves a few bits in each register to hold type information in allow
hardware assisted runtime type checking.


>It's suspicious that Smalltalkers don't like types . Somewhat
>types represent a "hackerish" (low form of Computer Science)
>way of doing thing rights. 
>
>Sure, types are a good tool for certain things. But, sure, we
>have better tools for that sort of things.

    What tools do we have that are better than types for the things
that types are good at?  It seems that the tools that your idea of 
encoding the properties of object and just checking that is basically
a restatement of types and type classes but with different names.  
For example to capture the need for objects used in for to have Sequence
attributes, you can easily express it with types and typeclasses as 
    
    class Sequence a where 
    seq        :: Num b -> a -> [c]

so that with a definition of for similar to 

    for  y f = let z = seq y 
	       in map f z

any object y is allowed as long as you declare that y supports a seq method.