[Types-sig] Static typing: Towards closure?

[Guido van Rossum]

Martijn, I won't discuss the implied interfaces idea any further on
the list.  I just find it too absurd.  Since you're coming to the
conference next week, I'll buy you a beer and we can talk about it
under more enlightened circumstances.  Maybe I'll even remeber a few
words of Dutch! :-)

Other stuff:

> > Actually, we would expect it to be faster, because errors are caught
> > earlier (during code generation rather than during testing or when in
> > production) and this should save time.
> 
> Hm, no. If this were so we'd all be using Java or C++.

Touche.

> Catching errors early is good in large systems for maintainability reasons,
> and in the situation where the approach to solving a problem is thoroughly
> understood. Often while coding you are prototyping however; parts of the
> code don't make sense and this is known, but we want a quick way to 
> test parts of the code that already works.
> 
> This is tolerated by Python currently partly because it doesn't do type
> checking. You don't have to think about having to have all the interfaces
> right and all the types right in the beginning. This can speed up 
> development in Python, where in C++ I get bogged down in nailing down lots
> of class interfaces before I can proceed to the meat of the problem (where
> I may find out my initial approach is all wrong and I did a lot of work
> for nothing).
> 
> If type-annotated Python is infecteous (Skip I think called this the 'const'
> propagation problem, like the way you need to const-correct everything in C++
> if you use const at all), we have a problem. I'm still worried we'll end
> up with a language where there's a type-propagation problem; if we use
> type annotations somewhere, we may have to add them everywhere. My worries
> may not be justified at all; I suppose we'll have to have some practical
> experience with it before we can really know.

I don't expect that there will be a propagation problem, even if all
the standard library modules (and extensions) are typechecked.  My
reasoning is that the type system only adds static warnings (i.e.,
restrictions) to checked modules; unchecked modules (such as you are
likely to be using during prototyping) will only get runtime errors,
and they should only get runtime errors where they would have gotten
runtime errors before anyway.

There are two exceptions: maybe you'll get warnings when you compile
an unchecked module that imports a checked module and then uses it in
an obviously broken way (e.g. calling a function that's not defined or
calling a function that is defined with the wrong number of
arguments); but that's code that's already broken.  And maybe code
that abuses the standard library will break (e.g. if you put things in
sys.modules that aren't modules or whose keys aren't strings).  But
calling a standard function that takes an int with an object whose
type is only known as 'any' at compile time is not a compile-time
error; you only get an error when at runtime it's not an int, and
that's no different than before (except that sometimes the diagnostic
will be more understandable; currently you sometimes get these errors
after the illegal value has been passed down several levels deep into
the internals of a library module).

But I don't think this will affect your ability to write unchecked
modules at all.  The 'const' example doesn't apply here.

--Guido van Rossum (home page: http://www.python.org/~guido/)