[Types-sig] consensus(?) summary (was: Type annotations)

[Greg Stein]

On Thu, 16 Dec 1999, Paul Prescod wrote:
>...
> I don't have time to write up all of the semantics of the system yet but
> the major parts are:
> 
>  * local variables types are usually inferred

Woo! :-)

>  * module variables and instance variables may have type declarations

Yes. I believe this is because these variables fall under the same rubric
of "interface declarations." One interface for the module, another for a
class.

>  * non-local writes are checked at runtime (by default)

Hrm. Is there an easy rule to determine this? I might suggest deferring
this unless/until we have a clear set of rules. Shades of C++'s "friend"
modifier are forming in my head when we talk about this...

>  * for optimization, the checks may be stripped based on type inferenced
> information

Which checks? I think runtime checks are *ignored* if you run with -O.
Python doesn't (yet) have different forms of compilation (or did I miss
something?). Certainly, in 1.6 we can have different compilations by
virtue of substituting a new compiler, but I think it would be nice to
retain a single form of compilation.

In reference to type-inferred information: I don't think runtime checks
would ever be added if the type has been inferred.

Issue: what are the rules for inserting runtime checks? When are they
added and when are they not?

   Strawman:
      1) they are added for function arguments which have type declarators
         (i.e. added as a function prologue).
      2) they are added when the type-assert operator is used.

>  * function return types are NEVER inferred
>  * ...they must be declared or assumed to be PyObject
>  * "types" can be Python primitive types, or declared classes or
> interfaces

Agreed.

>  * built-in types are declared through "shadow files"

This is somewhat problematic. How do we map from a builtin type to this
shadow file? Do they reside in a well-known location?

Second issue: keeping them in sync, version mismatches, distribution and
install problems, etc.

My recommendation would be to enable a mechanism by which modules can
internally declare their interface. I recognize this is complex and would
therefore defer any discussion regarding interfaces for builtin types.

Note: and when I say "builtin type", I'm referring to things like "socket"
rather than the "core types" such as List or Dict.

>  * but a function return statement could be verified based on
> inferencing to conform to its declaration

Yes. This would be a compile-time static check.

>  * expression assertions support within-function assertions
>  * function parameters can have declarations

Agreed.

>  * function calls and assignments are checked at runtime if they cannot
> be verified at compile time

Function calls: yes.

I'm not sure we would ever check assignments. See my response above,
regarding knowing when the proper time is. Instead, I think that an
interface is a statement (to users) about the types, but we don't
necessarily have to enforce it. Hrm. This kind of falls under the concept
of "verifying an implementation conforms to an interface." I would prefer
to avoid that.

>  * but you can ask for an explicit verification at compile time
>  * which enables faster code to be generated
>  * ...and verifies your understanding of what you are doing

I'm not clear on your points here.

>  * types can be parameterized
>  * which means that the compile/runtime checks need to be more
> sophisticated

Yes, although I might modify it somewhat and say "only core types can be
parameterized."

>  * we do not yet handle the "exception interface" of a function

Thank you :-)

Cheers,
-g

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