[Types-sig] Sample declarations

Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
13 Mar 2001 20:52:56 GMT

13 Mar 2001 14:40:03 -0500, Daniel Wang <danwang@CS.Princeton.EDU> pisze:

> given a method or function body
>  def foo (....):
>    random code...
> automatically compute a "type assertion" function that basically
> simulates the behavior of the random code with respect to type errors

This will never work well in Python. Python is too dynamic and the
behavior of libraries wrt. types is too irregular to be inferred
statically from usage (perhaps except most simple cases, which is

Sorry, a simple statement of
    spam.spam(spam, spam)
generates a complex assertion that
    the object to which spam is bound, whatever it is at this point,
    has the attribute 'spam', or at least is able to produce it,
    which is a callable object, whatever type it is, which can accept
    two arguments, not necessarily only two, whose types are required
    to be some unknown supertypes of the type of the object to which
    spam is bound, assuming that their requirements can be described
    in terms of supertypes at all.

You can't even combine assertions about the 'spam' attribute derived
from two calls, because nothing prevents rebinding the attribute at
any point.

Type inference works very well in SML, OCaml, Haskell, Clean and
Miranda. These languages have a simple model of behavior of basic
objects and simple type rules. Libraries are designed according to
these rules. Polymorphism is present only in resticted ways, quite
different from the Python way.

The result is that these languages allow to program with almost no
explicit type annotations, yet fully protected from type errors and
not too limited, if you agree to think according to their way. But
it's far from Python, and not compatible with existing Python's style
at all.

At most there can be (I hope) a soft type system, with optional
assertion-like type annotations. It would even allow applying
optimizations by a smart interpreter: fortunately rebinding of local
variables is restricted to the body of the given function, so the
interpreter can sometimes be sure that a local variable is indeed
always an integer.

 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
  ^^                      SYGNATURA ZAST=CAPCZA