[Types-sig] RFC 0.1

[Martijn Faassen]

Paul Prescod wrote:
> Greg Stein wrote:
[assigns objects of various types to the same name and wants this to
remain legal Python code]
> I am perfectly happy to have it be legal Python code. I just don't
> intend for it to be *statically type checkable* Python code. No, you
> cannot use all of the flexibility of Python and expect to get all of the
> static type checking of Java. For each function you choose one or the
> other.

I agree with this, which is I am advocating a strong split (for
simplicity) of fully-statically checked code and normal python code.
Later on you can work on blurring the interface between the two. First
*fully* type annotated functions (classes, modules, what you want),
which can only refer to other things that are fully annotated. By 'fully
annotated' I mean all names have a type. I keep disagreeing with Paul's
simplification of initially throwing out constructed types such as list
of integer, as that would break my own approach at simplicity. :)

[snip]
> > I believe that Python is too rich in data types and composition of types
> > to be able to add *syntax* for all type declarations. I think you better
> > stop and realize that before you get in too deep :-)
> 
> I have a few different answers here:
> 
>  1. I don't have to be able to describe every possible type. If you
> can't statically check that "foo is a callable from T,T to callable from
> T" tough bloody luck, at least for the time being. Java can't do that.
> Neither could mid-90's C++. And forget about it for ANSI C.
> 
> Python is not the world's most OO programming language. It is just a
> good one. It may not have the world's most static type checker. It will
> just have a good one. No type system makes type errors impossible so
> that is not my goal. My goal is that if a module uses type checks as
> religiously as  Java module would, that module would be roughly as
> type-safe.

If we throw out the syntax issue and use Python constructs for types
until we know more, we'll all be happier, right? :) The syntax will be
clear when the semantics is. Guido is good at syntax, let him figure out
a good syntax for it, let's just focus on the semantics.

Our static type checker/compiler can use the Python type constructions
directly. We can put limitations on them to forbid any type
constructions that the compiler cannot fully evaluate before the
compilation of the actual code, of course, just like we can put
limitations on statically typed functions (they shouldn't be able to
call any non-static functions in the first iteration of our design, I'm
still maintaining)

[snip]
>  3. Compositions of types are complex, but not infinitely complex. We
> have about two decades in parameterized type research to rely on. Within
> a year and a half, two of the world's most popular languages (C++ and
> Java) will have parameterized types.

Doesn't C++ already have parameterized types? (template classes and
such?).

> > In your RFC 0.1, you punted on the complex/composited data types issue too
> > keep the solution tractable. I posit that you will *never* solve the
> > problem of coming up with sufficient syntactical expression; therefore,
> > you will always have to resort to a procedural component in your type
> > system *if* you want full coverage.
> 
> I am happy to have a runtime component. I just don't see that we need
> any new syntax for this runtime component. And I don't think that we
> should give up on a formally defined static system.

I agree we should focus on a static system.

Regards,

Martijn