[Types-sig] Type Inference I

skaller skaller@maxtal.com.au
Sun, 19 Dec 1999 10:37:22 +1100

Paul Prescod wrote:
> I don't see how this strategy can work.
> skaller wrote:
> >
> > You might just think, seeing
> >
> >         x + 1
> >
> > that if x is not an integer, the code must be an error,
> > but the example above shows that you'd be wrong
> > if you said that.
> But as you and others have pointed out, Python is protocol-centric, not
> type-centric. In real Python, x could be anything that with an __add__
> function. The optimization opportunity is thus dubious.

That depends on the scope of the analyser I think.
If you are only analysing a function, by itself, without any
type declarations, you are probably right that many cases
cannot be optimised. In that case type declarations may help.
However, it may well be that it _is_ possible to deduce things
in an isolated function in important places, like in the
body of an innner loop.

On the other hand, if you widen the scope of the analyser to
a whole module, or the whole program, then it may be possible
to do better. [See Guidos 'rambling' post]

Greg wants to write one kind of tool, I'm building a different one.
The point is to try to help both these tools, and any others,
do a better job for the programmer, by changing the python
language. I.e. the goal of the SIG is to recommend language
changes NOT to produce any kind of tool (although that 
is useful to help decide what needs changing, and it may
also be useful to end users as well: these are secondary
goals) At least, that's my understanding.

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