[Types-sig] Static typing: Towards closure?

Skip Montanaro skip@mojam.com (Skip Montanaro)
Fri, 21 Jan 2000 11:58:49 -0600 (CST)

    Jeremy> Guido showed the potentially painful example of passing a list
    Jeremy> containing thousands of elements from unchecked code to an
    Jeremy> object declared as "def (int list) -> int"; this seems to imply
    Jeremy> a runtime check to verify that all of the elements of the list
    Jeremy> are ints.  I worry that there would be subtler cases with
    Jeremy> similar performance hits.

I think this is an excellent example of where type propagation might rear
its ugly head.  How do you get rid of the performance hit?  If you don't
want to (or can't) rewrite your code, you'll add type declarations to it.

If a call from an unchecked module into a checked module occurs and causes a
protective performance hit as you suggest, my first inclination would be to
add types to the unchecked module, especially if the checked module was out
of my control (installed with type checking by the sys admin on a shared
server, for example).  A quick example, presuming the file object (in
whatever guise - will C modules be expected to be type-safe against calls
from unchecked Python modules?)  acquires type checking and I make the dumb
mistake of executing

    f = open("/tmp/foo", "w")
    f.writelines(["x\n"] * 100000)

then the file object's writelines method will protect itself by verifying
that each list element is a string.  I suspect my only recourses here would
be to rewrite the calling code (maybe not as easy as in this contrived
example) or add type checking to the previously unchecked module.  That
would then implicitly define a new set of untyped/type interfaces that may
suffer from similar performance problems and have to be addressed somehow.