[Types-sig] RFC 0.1

[Greg Stein]

On Wed, 15 Dec 1999, Martijn Faassen wrote:
> 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.

"We" ?

I'm advocating a minimal change. Add a bit of grammar to function
definitions. Add a new type-assert operator. Add Tim's "decl" statement
for interfaces (caveat/todo: rationalize against JimF's proposal). Leave
out the complexity of variable declarations.

Note that I'd be okay with punting the "decl" / interfaces for now. That
leaves a bit of "def" grammar changing and a new operator.

To the Python programmer: *very* little change.

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

1) There is *no* way that I'm going to give every name a type. I may as
   well switch to Java, C, or C++ (per Guido's advice in another email :-)

2) You *still* need inferencing. "a = foo() + bar()" implies that some
   inferencing occurs.
   (for a compile-time check; the compiler can insert a runtime check to
    assert the type being assigned to "a" (but you know my opinion
    there...))

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

Agreed. Also, if I grab some module Foo from Joe, and he didn't add
typedecls, then why shouldn't I be able to use it?
(and I'd just add some type-asserts if that even mattered to me)

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

The compiler can issue a warning and insert a type assertion for a runtime
check. IMO, it should not forbid you from doing anything simply because it
can't figure out some type. Python syntax's "type agnosticism" is one of
its major strengths.

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

Bunk! It is *not* a cast. You cannot cast in Python. It is a type
assertion. An object is an object -- you cannot cast it to something else.
Forget function call syntax and casting syntax -- they don't work
grammatically, and that is the wrong semantic (if you're using that format
to create some semantic equivalent to a cast).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/