[Types-sig] Non-conservative inferencing considered harmful

[Paul Prescod]

Greg Stein wrote:
> 
> ...
>
> I maintain that it could be declared type-safe. In fact, it is reasonably
> straight-forward to generate the type information at each point, for each
> value, and then to verify that the .doSomething is valid.

Greg, you are getting into exactly what I want to avoid. Let's say the
first doSomething returns an int and the second doSomething returns a
string. Now you are trying to statically bind it to an integer-bearing
parameter. What's the appropriate error message:

> > a = [Foo(), Bar()]
> > 
> > ... 10,000 lines of code ...
> > 
> > for el in a:
> >    j = el.doSomething()
> > 
> > ... 10,000 lines of code ...
> > decl k: Int
> > k = j

"Warning: integer|string cannot be assigned to integer."

Note also that the point where the error message occurs may be miles
from the place where you did the funky thing that allowed the variable
to take two types. 

This is EXACTLY the sort of error message that made me run screaming
from the last language that tried to "help" me with data flow analysis
and type inferencing. To put this is in the strongest possible terms,
this sort of data flow analysis/inferencing "helps" me like MS Word's
guessing what I mean when I "misspell" happy face (e.g. Python code) and
Word fixes it for me. We are trying too hard and the result will be
non-intuitive. There is no need to complicate our system in order to
handle these corner cases. If the user wants a to be a List of (Foo|Bar)
then they can darn well SAY SO.

It is because of this experience that I am strongly of the belief that
we should do NO flow analysis in the normative part of our type system.
I am willing to support these basic kinds type inferencing:

 * if a variable is consistently assigned a particular type within its
scope, we inference the type.
 * if a variable is inconsistently assigned we infer it as "Any"
 * if a non-error-checking optimizer wants to inference anything else
and that inference doesn't change the language semantics then I am all
for it.

 Paul Prescod