Adding static typing to Python
Huaiyu Zhu
huaiyu at gauss.almadan.ibm.com
Tue Feb 19 20:17:35 CET 2002
On Tue, 19 Feb 2002 15:44:09 GMT, Nick Mathewson <QnickQm at alum.mit.edu>
wrote:
>Making a real static type system is harder than you'd think.
>Consider this function:
>
>def fn(lst,item):
> for i in lst:
> if i == item:
> return repr(i)
>
>What is the type of fn? You could call it:
>
> (list[int], int) -> str
>
>But then you'd lose the polymorphism of the function. To a first
>approximation, you might say:
[snip excellent analysis of need of polymorphism]
>IMNSHO, some kind type inference is the only tractable answer.
This is an excellent point. A static typechecking system added to Python
will be overly restrictive unless it has the power of polymorphic type
systems found in some functional programming languages (ML, Haskell).
To further expand on this point, a full typechecking system in this example
must be able to handle the following type semantics:
fn :: I(A), B -> str where:
# These can be inferred automatically by type checker
I in Iter
(A, B) in Eq
A in Repr
# These can be imported as standard Python design interfaces
typeclass Iter(I): I(A) => (def I(A).next() :: A) and (raises StopIteration)
typeclass Eq(A, B): def A.__eq__(B) :: bool
typeclass Repr(A): def A.__repr__() :: str
It is not necessary to write all these on the spot --- predefined
typeclasses can be imported. And it is not necessary to make all of them
explicit --- much can be derived automatically using type inference as in ML
or Haskell. But the point is that a whole new set of mechanisms must be
developed to represent and handle such type semantics.
Such a system would certainly be marvelous to have. It is certainly doable.
It is likely to be difficult. Sounds like a good candidate for a
challenging project.
Huaiyu
More information about the Python-list
mailing list