[Types-sig] Static typing: Towards closure?

[Martijn Faassen]

Guido van Rossum wrote:
> Martijn, I won't discuss the implied interfaces idea any further on
> the list.  I just find it too absurd.

Okay, then I won't point out that currently Python allows interfaces that
are even more implicit. :) [whoops, sorry, I'll shut up now]
 
> 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! :-)

Sounds good to me! :) Sorry to play devil's advocate so persistently; 
it's one of my life's tenets that even absurd ideas have merit in 
training the mind and gaining new insights -- which is why I end up
talking in absurdities quite frequently (usually to hopefully comic
effect). Anyway, a beer, good! 

[snip]
> > 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.

I hadn't considered this distinction between checked and unchecked fully 
enough; I'll have to think this one over. Can an unchecked module have
type annotations too, and can this cause run-time TypeError exceptions to
be raised? Perhaps this is in your document and I missed it.

Note that runtime checking might help avoid the list of 1000 ints problem
in some cases; this list can be declared to be of ints and this can
be checked at runtime, so that passing it into checked function can 
proceed without overhead. But, if this kind of thing is allowed, you
could very well have a type-infection problem; in order to avoid the 
overhead people are pushed to add checks everywhere.

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

I agree, the const example doesn't apply directly, but I was thinking more
about the more subtle cultural thing that makes C++ programmers want to
const-correct everything -- I don't think we want a similar drive to
'type-correctness' in Python. Anyway, we won't know until we try, so
I'll stop arguing about this.

For-now-at-least-ly yours,

Martijn