[Types-sig] Re: Revive the types sig?

[Paul Prescod]

Disclaimer: I am not the types-czar. I will design one system with the
help of people who are like-minded. You can design another with
different goals if you like. Guido can choose.

Marcin 'Qrczak' Kowalczyk wrote:
> 
> ...
> 
> I strongly disagree with making it broken-as-designed. A flawed type
> system adds too much complexity and yields pain in fighting with its
> limitations compared to benefits. We should either do it such that
> it really works in most cases, or don't do it at all.

As a thought experiment, let's imagine the radically simple situation I
outlined where you can only type check strings and integers. Please
explain how this will "yield pain in fighting with its limitations?"
"Simple" type systems are painful in statically typed languages because
there is no way to get around them. In Python, you can just ignore them
when they don't do what you need.

> When you pass a string instead of a number to a function, the error
> is often caught immediately as soon as the parameter is used. 

Often the parameter is not used for a long, long time. Compare the
traceback from open(None) to the one from urllib.urlopen(None).

> But when
> you pass a list and some of its elements don't have the expected type,
> the error is more subtle.

Yes, well. When you pass a list of integers that you expect to be prime
and some aren't prime, that's subtle too. We can't save the world. We
can only make a type system that is simple enough for people to like and
use.

> For me the ability to specify the type of an argument, but inability to
> say anything about elements of a list or tuple, makes the system not
> worth adding to a language. Similarly, being able to tell something
> only about builtin types or interfaces.

I'm not saying that we will be that draconian but if the design spins
out of control we might end up there.

> Many complaints about static typing result from the assumption that
> it must be as poor as in Java, or as complex as in C++.
> I suggest taking Haskell, ML or Eiffel as inspiration, not Java.

Well, I disliked ML's type system immensely and Eiffel's is so complex
that the Eiffel FAQ admits that most compilers do not implement it in
its entirety. Many people (myself included) consider ML to be rocket
science. I haven't used Haskell but compared to what I envision I know
it also has a brain-exploding type system. Monads???

"Haskell is a typeful programming language: (A phrase due to Luca
Cardelli.) Types are pervasive, and the newcomer is best off becoming
well-aware of the full power and complexity of Haskell's type system
from the outset."

 - http://www.cs.yale.edu/haskell/tutorial.html

Python is not a typeful programming language. It should never become
one.

> Java requires type casts to overcome limitations of the static type
> system, because of lack of genericity (besides builtin array hack)
> and lack of the ability to form conjunctions of interfaces.

Maybe this simplicity is why Java is more popular than C++

> Even Java is going to add genericity, and there already exist Java
> extensions which do it. Lack of genericity is IMHO the biggest single
> flaw in Java's type system.

As a computer scientist and sometimes Java programmer, I agree
wholeheartedly. But IMHO, Python cannot and will not do static type
checking better than Java and still remain Python. We have much more
modest goals. Nicer error messages. Better documentation. The ability to
auto-generate IDL. A little bit faster handling of ints, strings and
maybe (maybe!) method tables. I mean Python is a language that is so
radically simple that it doesn't even have a concept of protected or
truly private methods!


-- 
Python:
    Programming the way
    Guido
    indented it.
       - (originated with Skip Montanaro?)