[Types-sig] Static typing: Towards closure?

Greg Stein gstein@lyra.org
Thu, 20 Jan 2000 18:34:19 -0800 (PST)


On Fri, 21 Jan 2000, Martijn Faassen wrote:
> 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]

While a class definition *does* imply an interface(*), I think it was your
concept of deducing an interface from multiple classes that was the
problem. If you have:

  class Foo implements Alpha:
    ...

  class Bar implements Alpha:
    ...

Then Alpha will be constructed from the definitions of Foo and Bar. There
is no type-checking that Foo and Bar actually conform to the developer's
intention of what Alpha is supposed to mean.

Sure, "Alpha" now has *some* meaning, but it might not be the intended
meaning. Therefore, it provides no assistance with checking.


(*) Note that my type-checker prototype actually builds an interface
    object based on a class definition. It then uses this interface during
    the rest of the checking to check whether clients are using the class
    instances properly.

    In other words, it is an existence proof of creating and using an
    implied interface from a class definition.


>...
> 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.

I would hope that unchecked modules can include declarations. I don't want
to have to convert an *entire* module to be "checked" when I only want
type checking in a couple key areas.

> 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.

The runtime checks will always be present on function entry. The function
could be called from an unchecked module.

Caveat: the runtime check would be eliminated if the function was compiled
while the -O switch was present. This can be stated explicitly, or can be
deduced if we say function-entry checks use the semantics of the '!'
operator (which has explicit semantics with regard to -O).

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

fyi, this problem is usually called "const poisoning".

Note that I plan to submit patches to the Python core at some point to
const-poison it :-)  I tried a partial version once, but Guido rejected it
saying he wanted all or nothing... hehe.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/