[Types-sig] type inference/deduction (was: recursive types, type safety, and flow analysis)

Greg Stein gstein@lyra.org
Mon, 27 Dec 1999 04:43:38 -0800 (PST)


On Mon, 27 Dec 1999, Paul Prescod wrote:
> Guido van Rossum wrote:
>...
> > but I don't think that is the right level of
> > critique.  In any case I think we can do better by simply referring to
> > the line number(s) where a.a gets assigned a non-int value.  Good
> > error messages are a human factors issue, not a type system issue.
> 
> It's a little bit more subtle than that. The problem is that we are
> generating anonymous types left right and center:
> 
> if a:
> 	def foo(): # anon type foo1

This would be def()->Any.

And for discussion, we'll call this type "foo1"

Oh. Wait. I just saw. You actually meant:

        class foo:

And yah: we'll refer to this version as "foo1"

> 		def bar(self): # anon type foo1->String

Huh? This would be: def(foo1)->Any

> 			if self.something:
> 				return "Abc"
> 			else:
> 				return None
> else:
> 	def foo2(): # anon type foo2

We'll assume: class foo

And we'll refer to this version as "foo2"

> 		def bar(self): # anon type foo2->String
> 			if self.something:
> 				return 123
> 			else:
> 				return 45L
> 
> k = [foo, foo] # anon type [foo1_class or foo2_class]
> 
> j = [] 

This would be: [Any]

> for i in k:
> 	j.append(i()) #oops. how do we handle this?

No problem. j can take any element.

> #okay, another try:
> 
> k=[foo().bar(), foo().bar()] 
> # anon type [String or None or Integer or Long ]
> 
> mvar: String or Integer or Long

myvar: ...

> myvar = k

myvar = k[0]   (??)

Assuming assignment enforcement, you would get an error here. Nowhere
else. It would give some error message about k having a type which is
incompatible with myvar.

> Now you have to back-track a LOT of code. Merely reporting: "bar can
> return None on line 13" is not very helpful because I have to trace a
> path from bar to where I am which is harder when this code is embedded
> in other code.

I do not believe that we would issue an error message like that. The
message would be about a type conflict at the assignment.

> Anyhow, I won't say (anymore) that this sort of deduction is
> unequivocally a bad idea. If we generate these PyDL files then you will
> have a useful debugging tool which may clear up a lot of these problems.
> It comforts me to know that if the inferencing goes horibbly wrong you
> can look at the PyDL file to figure out what the inferencer was thinking
> and override it.

I would expect to be able to generate/cache the PyDL files. I do not see
how things can go "horribly wrong." The types are the types. As I
mentioned previously: we have to know the type of the RHS in an
assignment. I say we use that info, you say we check it against the type
of the LHS.

Based on the prototype that I posted, I think that I'm going to modify my
position a bit:

* if you declare a variable/attribute, then you get assignment enforcement
  (note this also applies to func param names)

* if you do not declare, then there is no enforcement (the type is deduced
  from the RHS)


Cheers,
-g

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