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

[Greg Stein]

On Tue, 21 Dec 1999, scott wrote:
> On Tue, Dec 21, 1999 at 08:06:28PM -0800, Greg Stein 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?

One of my points was that I do not believe you can issue warnings because
you can't know whether a problem might exist. Basically, it boils to not
knowing whether a global used by a function exists at the time the
function is called. So you either issues warnings for all global usage, or
you issue none. You can make a few guesses based on what happens in the
global code body, but I don't think the guesses will really improve the
quality of warnings.

Examples? No, I don't really have any handy. Any example would be a short
code snippet and people would say, "yah. that's bad. it should fail." But
the issue is with larger bodies of code... that's what we're trying to
fix! So... No, I don't have a non-trivial example.

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

The origination of this discussion was based on the recursive type issue.
If we have runtime objects, then I doubt we could support the recursive
type thing without some additional work. Or, as I'm suggesting, you do not
allow an undefined name (as specified by runtime/execution order) to be
used in a typedecl.

The design of how to handle recursive types depends on the decision to
include/exclude runtime objects that define function, class, or module
typedecl information. Even if we defer the runtime creation of those
objects, it will affect the design today.

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

I'm all for deferring stuff, but unfortunately, I believe this affects the
V1 design.

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

Bytecodes do not really need to be backwards compatible. The magic value
in the header of a .pyc prevents use of an incorrect version of bytecodes.
(see line 80 or so in Python/import.c)

I do believe the information goes into the bytecode, but I don't think
that is the basis for needing to plan now. Instead, we have to define the
semantics of when/where those typedecl objects exist. Do we have them at
runtime? Does a name have to exist (in terms of runtime execution) for it
to be used in a typedecl, or does it just have to exist *somewhere*? If
names must exist before usage, then how is the recursive type thing
handled? With unspecified typedecls? (like an unspecified struct)

Cheers,
-g

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