[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/