[Types-sig] PyDL RFC 0.02

[scott]

On Tue, Dec 28, 1999 at 06:19:26PM -0800, Greg Stein wrote:
> On Mon, 27 Dec 1999, scott wrote:
> > On Mon, Dec 27, 1999 at 12:14:41PM -0800, Greg Stein wrote:
> >...
> > > 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.
> 
> It doesn't have to run code.
> 
> Try out the prototype that I posted to this list a few days ago. It can
> tell you a lot about what, when, and where values are stored into the
> different namespaces. And it doesn't run code -- it just walks the parse
> tree.

OK, done that.

> 
> > 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.
> 
> You'd be surprised at what it can check :-)

While there may be a lot of value in walking the parse tree as your
checker does, it doesn't seem to do much in terms of what I expect out
of a type checker.  

What I want to be able to do:  declare types, and have things which
contradict the declarations reported nicely at compile time.  A little
searching through the code you posted didn't show any clear way to
declare types, it just seems to spit out lots of attribute warnings
when run it on itself, and it fails to detect anything wrong with the
few simple cases I've thrown at it.  for example:

a = 1
b = "3"
a + b

yields no warnings, but is an error I'd expect a type checker to
understand.


def foo(x, y): return x + y

foo(2)

also yields no warnings, and is something I'd expect a type checker to
understand.

> 
> The checker can easily track type usage and find things that should not be
> allowed. The check.py (and friends) that I posted only does a couple
> things, but the framework is there for more. I just need to start filling
> stuff in. I went for breadth-first so that people could see what a type
> checker would look like.
> 
> > 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.
> 
> Nope. I posted an "existence proof" that I believe contradicts this :-)

The checker you posted either falls way short of being able to declare
and check static types, or it's sufficiently unclear how to make it do
that that I'd only accept existence proof as a series of examples of
making it do that.  For example, how do you make it check the two
examples above properly?  How can I declare variable 'a' to be an
integer, and then have the checker report something remotely
meaningful when I assign a string to the variable 'a' in the same
namespace? in another namespace via ``global''?

scott

scott

> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
>