[Types-sig] RFC 0.1

[Tim Peters]

[Paul Prescod]
> ...
> In theory, but in practice "whole-program X" seems to never get
> implemented (in Python or elsewhere!), as in "whole program type checks"
> and "whole program optimization" and "whole program flow analysis."
> "Whole program analysis" tends to be an excuse to put off work (roughly
> like "type inference").

Whole-program type inference is the *norm* in the functional language
world -- although they design the languages to make this provably possible
in all cases(possible != easy -- it's not).  Experienced f.p. programmers
nevertheless explicitly name all their types and explictly declare all their
vrbls of non-trivial types; else the unification algorithms that deduce
most-general types yield incomprehensible error msgs; e.g., if you have a
function that you *think* of as taking a list of ints, you don't know what
the compiler is talking about if you forget to declare it as such and the
type inferencer bitches about being unable to unify two type expressions
that take five lines each to spell <0.5 wink>.

The more general the language, the more benefit there is for *people* to be
able to declare types, in their role as code readers.  So in addition to
Guido's OPT and ERR, add COM -- for "make this mess COMprehensible" <wink>.

> ...
> If we invent new, syntactically distinct spellings then we can
> syntactically recognize them and complain if they aren't spelled
> "exactly right" (i.e. in a statically analyzable way).

[Guido]
>> As long as an easy mechanical transformation to valid Python
>> 1.5.x is available, I'd be happy.

[PP]
> ...
> With all due respect my problem is that you took the obvious (or at
> least traditional) instance variable declaration syntax and used it
> as a class variable declaring syntax. Okay, let's try this:
>
>  class foo:
>      types.IntType, a=5
>
>      def __init__( self ):
>          types.ListType, self.b
>
> That looks equally ugly to me. Got any other ideas?

Don't try to overload existing syntax, either asserts or (as above) tuple
syntax.  That confuses both the overloader and the overloadee.  Guido just
*begged* <wink> us to suck up a new keyword!  For lack of a better word, say
type declarations are in "decl" stmts.  It doesn't matter to me, but what
does matter is that once you get your own statement, you can also define the
syntax of that statement; e.g.,

    class foo:
        decl a: int  # slop in a const too, if you like
        a = 5

        def __init__(self):
            decl member b: List of Any
            # or put that at class level -- where it belongs <wink>

Resist the dubious temptation to conflate declaration with initialization,
and "an easy mechanical transformation to valid Python 1.5.x" consists of
commenting out the decl stmts!  Heck, call the keyword "#\s+decl\s+" and
it's a nop.

> ...
> if we are ever going to get to full polymorphic parametric static
> type checking we will have to acknowledge that the type system will
> have hard parts just as the language has hard parts.

Indeed it will.

but-in-a-pythonically-soft-way-ly y'rs  - tim