[Types-sig] recursive types, type safety, and flow analysis

[scott]

On Tue, Dec 21, 1999 at 08:06:28PM -0800, Greg Stein wrote:
> On Tue, 21 Dec 1999, Guido van Rossum wrote:
[...]
> >...
> 
> Basically, I think your request to find and report on
> use-before-definition is "intractable" *when* you're talking about
> multiple bodies of code (e.g. two functions, or the global space and a
> function).
> 
> [ by "intractable", I mean within the scope of what I believe we want to
>   build; the problem is certainly doable but I believe it would involve
>   complex, global, control-flow analysis. ]

I'd agree that this has been demonstrated, but only for examples of
code which seem like great candidates for compile time warnings.  Are
there examples which strike you otherwise?

[...]
> 
> I want compile time checks, but I also want function objects to contain
> typedecl information at runtime. I'm not talking about runtime type
> checks, just recording more information with the function objects.
> 
> For example, I'd like to be able to say something like:
> 
> for i in range(func.func_code.co_argcount):
>   print func.func_code.co_varnames[i], ':', func.func_argtypes[i]
> 

This sounds great, but to what extent do you think it should affect
the initial coding design?  It seems to me like this sort of
functionality is more likely a candidate for something quite
post-prototype-version-1 code, and to a large extent could be added to
a compile-time checking system that could store it's type assertions
in a form usable at runtime.  

If that information is in the byte code (is that even feasible a
remotely backword compatible fashion?), then planning for this needs
to happen earlier.  If it's acceptible that that information could be
stored elsewhere, perhaps even (optionally) in the interpreter itself,
It seems like this functionality could be relatively easy to add to an
existing compile-time-only static typing mechanism without cluttering
the initial develop of that compile-time-only static typing mechanism
with what seems like a rather large new set of complexities.

The way I see all this compile-time vs. run-time stuff is that 1) run
time is much more complex and undesirable for several already stated
reasons. 2) run time has the ability to further resolve some
inadequately-typed-at-compile-time code.  3) run time offers myriads
of cool python code interfaces for interacting with a stronger typing
system.

To me, it seems to make the most sense to develop a compile time base
first, paying enough attention to the benefits of run-time use so as
not to preclude it or present it with unduly large obstacles.  And as
the compile-time code begins to stabilize a bit, define an interface
though which the compile time type information may become available to
the interpreter at run time.

I'd much rather have a fairly closed compile time type system in several
months than a fairy closed compile+run type system in a few years,
especially if the former doesn't preclude the latter.

scott