[Types-sig] Re: RFC 0.1

[Martijn Faassen]

"Golden, Howard" wrote:
[snip snip]
> > #4. The first version of the system will be syntactically compatible
> > with Python 1.5.x in order to allow experimentation in the lead-up to
> > an integrated system in Python 2.
> 
> Does this mean no new syntax?  (That's what it appears from your examples.)
> 
> How about a declaration syntax, e.g.,
> 
>     var x : type1, y : type2
> 
> Is this prohibited by the RFC?

While my agenda is to kill the syntax discussions for the moment, I'd
propose a seperate declaration syntax before all others, because this is
the most syntactically compatible with Python. And easier on the
programmer.

Imagine you have a module. Now you want to make it fully statically
typed. With most syntax proposals I've seen you'd have to go through the
code and add type declarations here and there, mix it with the current
code.

With either a Python based system as I'm proposing (ugly but powerful
and fairly simple), or a seperate type declaration system, you have your
type declarations separated from the code itself. This means you easily
add and remove type information and switch between a statically typed
module and a dynamically typed module easily.

On a slightly seperate issue, I propose a classification of modules
according to type annotation (or functions or classes, whatever level
you prefer thinking about):

fully unannotated module:

Names have no type annotations. 

Full type dynamicism. Only run-time type checks by hand are possible.
Can use any other kind of module. I.e. this is the good old Python
module as we know it now.

fully annotated module:

All names (local and global, function definitions, classes, class
members, class data, etc) in the module have a type annotation.

Restricts lots. Can only use other fully annotated modules. object
attributes are fixed at compile-time according to type annotations. code
that tries to add a new member to an object at run-time will give a
run-time error. 'a = "foo"; a = 1' will give a compile time error. I.e.
this is like a static language and this can be compiled to fast native
code.

partially annotated module:

Some names, but not all names, have type information. Possibly all names
do in fact, but imported modules aren't fully annotated which also
breaks things.

Restricts some. Will raise a run-time error if it is detected that type
annotations are violate, automatically. *may* do limited compile-time
checking. *may* try to do type inference to turn this module into a
fully annotated one. *may* even do fancy analysis and come up with one
or more fully annotated modules (which can be compiled for speed
reasons), but keeps a dynamic module around in case the fully annotated
modules cannot be used.

Regards,

Martijn