[Types-sig] RFC 0.1

[Martijn Faassen]

Paul Prescod wrote:
> 
> Martijn Faassen wrote:
> >
> > I agree with this, which is I am advocating a strong split (for
> > simplicity) of fully-statically checked code and normal python code.
> 
> I don't see this as buying much simplicity. And I do see it as requiring
> more work later. I also see it as scaring the bejeesus out of many
> static type system fence sitters. Can you demonstrate that it makes our
> life easier to figure out integration issues later?

Sure, but we're bound to scare the bejeesus out of everyone anyway;
we're proposing a major change to Python.

The 'simplicity' part comes in because you don't need *any* type
inferencing. Conceptually it's quite simple; all names need a type.

> > 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 think that's a non-starter because it will take forever to become
> useful because the standard library is not type-safe. Anyhow I fell like
> I've *already solved* the problem of integration so why would I undo
> that?

Okay, I will need to figure out your solution then. :)

> > 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. :)
> 
> If I'm making this problem harder than it needs to be then I'm happy to
> accept your simple solution for parameterized types as soon as I
> understand it.

I'll try to clean up my swallow.py demo module. It doesn't demonstrate
much, just a way a type system could work using Python dicts and such to
construct complicated types.
 
> > 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.
> 
> Well, we need SOME syntax in order to communicate. Anyhow...

Right, but just Python code will do for communication. It's clear as we
all understand it already. It looks horrible, but we can work on that
later.
 
> > 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)
> 
> I see no reason for that limitation. The result of a call to a
> non-static function is a Pyobject. You cast it in your client code to
> get type safety. Just like the shift from K&R C to ANSI C. Functions
> always (okay, often) returned "ints" but you could cast them to foo *'s.

Sure, that's why I say it's easy to start blurring things later. This
would require runtime manipulation of bytecodes or something to insert a
type
cast or assertion, while a fully annotated module can be fully checked 
statically and thus this type of runtime manipulation can be delayed
until later.

> > Doesn't C++ already have parameterized types? (template classes and
> > such?).
> 
> Yes. I was just pointing out that in a year and a half Java will have
> them too which will put a lot of pressure on us.

We already have parameterized types that are fully dynamic in Python
now, don't we, really? :)

Regards,

Martijn