[Fwd: Re: [Types-sig] Apologies and proposal]

[Paul Prescod]

Forwarded for Scott.

-------- Original Message --------
Subject: Re: [Types-sig] Apologies and proposal
Date: Mon, 28 Feb 2000 12:01:07 -0500
From: scott <scott@chronis.pobox.com>
To: Paul Prescod <paul@prescod.net>
References: <38B9733F.F251C817@prescod.net>
<20000227195110.A3106@chronis.pobox.com> <38BA4362.A85082B6@prescod.net>

On Mon, Feb 28, 2000 at 01:44:02AM -0800, Paul Prescod wrote:
> scott wrote:
> > 
> > While I'm all for putting in what we can as soon as possible, I have
> > some reservations about pushing ahead on 20% of the goals.
> > Specifically, I don't think the remaining 80% have been thought
> > through well enough to know how we can accomplish 20% without really
> > damaging the potential of static types.  The issues are subtle and
> > complex, and, I have found even seemingly innocent assumptions about a
> > static type system can cause all kinds of problems in an overall
> > system.
> 
> There are risks also to trying to design a huge, complex system all in
> one go. 

Perhaps.  But all other static type checking systems that I know of
are the result of atleast an intial core system with add ons, not a
20% system with an incomplete infrastructure -- or even blueprint.


> I do not consider the approach I suggest to be particularly risk
> from a backwards compatibility standpoint. We are all very familiar with
> this approach from other programming languges. 

not with regards to type checking -- there always seems to be a
complete infrastructure first, small changes and add-on functionality
later.  Please let me know of any even marginally successful counter
examples to this claim.

>The chances of a final
> Python static type system NOT being a superset of the system I describe
> seem quite remote.  

There are some things that you said before that seem to imply to me
direct things about a static type system for python that may not be
true.

Earlier Paul wrote:
> Implementation would require a change to the grammar, some extra
> information attached to method objects (perhaps just a list of parameter
> type pointers), an extra check at runtime (a loop over the args and the
> type pointers, maybe even implemented as a bytecode hack).

This, for example, makes me think that some might want to overlap
static types and dynamic types by making static info dynamic.  Which
may really not be a good idea.  See the language reference for Cecil
about some of the findings about mixing the two in general.  For
example,
http://www.cs.washington.edu/research/projects/cecil/cecil/www/www/www/Release/doc-cecil-lang/cecil-spec-78.html#HEADING78-0

> 
> At its heart, the goal of this proposal is to provide a standard syntax
> for static type declarations which can be used by tools *like* static
> type checkers, documentation engines, reflection engines, and runtime
> type checkers. It doesn't matter much whether we use a new syntax, or
> docstrings but I think that the interpreter needs to make that
> information available at runtime and it should probably have optional
> runtime checking as *an inducement* to actually doing the declarations.

While some subset of a syntax is easily workable in any static type
checking system for python, eg "decl foo: int", other very fundamental
parts have a very dramatic effect.  For example, can a person declare
something to be of type "none" (aka NoneType)?  If something like the
ability to declare a variable as type "none" is included in a 20%
plan, there are some _big_ implications for the usability of any
polymorphic static type system which may not be what we want. 

There are several things along these lines which, IMO would be quite
dangerous to set in stone in a 20% plan.  20% functionality is fine,
I'm just skeptical about the ability to provide it without a real
understanding of how an 85 or 90% plan would _work_.  Maybe it's
possible, but issues like the above will continue to creep up at every
stage.  Seems to me that it's better that they be made apparent now.

scott