[Types-sig] PyDL RFC 0.02

scott scott@chronis.pobox.com
Mon, 27 Dec 1999 17:59:55 -0500

On Mon, Dec 27, 1999 at 12:14:41PM -0800, Greg Stein wrote:
> On Mon, 27 Dec 1999, scott wrote:
> > On Mon, Dec 27, 1999 at 11:30:47AM -0800, Greg Stein wrote:
> > > However: I'm still against adding a whole new namespace. I haven't seen a
> > > good argument for why it is needed. Can somebody come up with a concise
> > > rationale?
> > 
> > In my understanding of it, a separate namespace is needed for the
> > generation of compile-time checking, simply because compile time
> > checking can't know everything that happens in the run-time namespace.
> > In other words, the static-type interpreter in the RFC needs it's own
> > way of dealing with variable names.
> > 
> > This perspective, however, is 100% independent of the idea of a
> > separate namespace at run time.  I don't see a need for a separate run
> > time namespace at all, only for a modular, cleanly accessible way of
> > accessing type information at run time.
> Right -- a compile-time "namespace". But really: that is just an
> abbreviated form of the runtime namespaces rather than a separate
> compile-time namespace (so "... needed for the generation of compile-time 
> checking, ..." doesn't hold).

We already had a big discussion about this that was never resolved.
> Regardless of how the compile-time namespace is viewed, Paul was
> suggesting a new runtime namespace in the RFC.

> Note: the compile-time checking *does* need to know everything that
> happens in the run-time namespaces. It must check the assignments and
> usage of values in the namespaces.

I don't see how compile-time checking can know much of anything about
runtime-specific namespaces without running code.  If it runs code, it
is no longer compile-time checking. Furthermore, if the compile-time
checker assumes that the running of code can do anything it can today,
there's not much of anything that can be checked at compile time to
begin with.

This is why it seems to me that checks done at compile-time must be
done based on a compile-time specific model of the namespaces, and
that model must be more restrictive in naming and scoping usage than
python currently is. Example restrictions that seem to help meet this
end are: don't delete typed variables, don't use different types for
variables at different times, unless that variable is pre-set as a
union of both types, etc.