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

[Paul Prescod]

Guido van Rossum wrote:
> 
> Paul's issue was that in ML the error message is typically
> ununderstandable.  I have never used ML (it's a language for people
> with excess IQ points) 

My impression was that the ONLY thing that makes ML tricky was the type
system. And the type system was built around the idea of type
inferencing.

> 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
		def bar(self): # anon type foo1->String
			if self.something:
				return "Abc"
			else:
				return None
else:
	def foo2(): # anon type 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 = [] 

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

#okay, another try:

k=[foo().bar(), foo().bar()] 
# anon type [String or None or Integer or Long ]

mvar: String or Integer or Long
myvar = k

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.

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.

 Paul Prescod