[Types-sig] RFC 0.1

[Paul Prescod]

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?

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

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

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

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

> 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.
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things to be wary of: A new kid in his prime
A man who knows the answers, and code that runs first time
http://www.geezjan.org/humor/computers/threes.html