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

[Guido van Rossum]

[a.a can have type int, string, or a few other possibilities]
> > j: Int
> > j = a.a
> > 
> > What's the error message? 
> 
> 	There isn't one at compile time.
> a could be an int, the inference engine cannot 
> know if it is or not, so it keeps quiet.
> At run time, a TypeError is raised if something
> other than int is assigned.

I don't like this rule, and I don't think this kind of rule exists in
other languages.  I would say a.a is a union, and most languages
dealing with unions require the programmer to explicitly code a type
test.

Never mind that *we* might know that the original program in fact
will only reach this point with an int in a.a; the fact that the type
checker can't see that (and it would have to solve the halting problem
to see it!) means that I'd be happy to get an error message here.

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

--Guido van Rossum (home page: http://www.python.org/~guido/)