[Types-sig] Basic questions

[skaller]

Paul Prescod wrote:
 
> This is why I think that "make everything explicit" is too strong of a
> rule in practice. I want type-checked code and untype-checked code to
> work together more or less seamlessly. 

	I agree.

> On the other hand, I don't want
> to get into complicated data flow analysis. Even if someone implemented
> it, how would we explain it to Python programmers? 

	But this I do not understand. When an inferencer assigns
types to a variable of function, there are three cases:

	(1) the types are what the programmer expected.
Programmers usually expect a particular result.

	(2) the type is more general than the programmer expected.
This is easy to explain: the inferencer isn't as smart as the
programmer.
If you want better types for these cases, add explicit type
declarations.

	(3) the type is not what the programmer expected.
In this case, there is a definite bug in the programmers understanding
of the code. (assuming the inference engine actually works correctly).
[The bug may be in a function, or in a function call: that is,
the programmer has to sort out whether the serving code is wrong,
or the client code: does the function have to be generalised to meet
the clients requirements, or does the client need to adjust the
code to use the function as it was intended to be used??]

	It is only case (3) which is difficult. But, the difficulty
is less than that which would result from a run time error, so the
inferencing cannot reduce the programmers understanding, only
make them realise there are bugs earlier than they might wish to
be reminded :-)

	Of course, there is a fouth case: the inferencer is 
producing the wrong answer. This would certainly confuse the 
programmer(s) -- probably both the client programmer and the
author(s) of the inferencer :-)

-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850