[Types-sig] Type Inference I

[Tim Peters]

[Martijn Faassen]
> ...
> The counter argument I got to this before is that inferencing takes
> place anyway in the case of expressions:
>
> def foo(a, b):
>     # Martijn's evil verbose format in yet another form
>     decl:
>         a = Int
>         b = Int
>         return Int
>     return a + b

Tony also had a "declaration block" construct; they look nice.

> 'a + b' would need inferencing to figure out what the type is of
> the complete expression. I think that this argument overlooks
> that this kind of evaluation is a lot more easy than a back-
> tracking kind of inferencing.
> ...
> Though checking could be seen as a kind of inferencing, right? Or
> are people confusing the issues? Initially I didn't consider the
> expression evaluation stuff as inferencing either, but there's a
> good argument to consider it so, not?

Not to me -- it's logic-chopping.  This is like the "compiler vs
interpreter" arguments that pop up on c.l.py from time to time:  yes,
there's a fine line between compilation and interpretation, but Python today
is nowhere near that line.  It's an interpreter.

Likewise there's a fine line between inferencing and checking, but in the
common usage of the words, deducing the type of "a + b" *given* the types of
a and b, and *given* the signatures of a.__add__ and b.__radd__, is not
called inferencing.  Insisting that it is cheapens the currency of the
marketplace of verbal discourse <wink>.  To the extent that you take away
one or more of the the four givens, "inferencing" gets more and more
appropriate.

Rule of thumb:  If it's something Algol and Fortran did Since The Beginning,
it's unhelpful to call it inferencing.

hmm!-we-could-just-begin-every-python-identifier-with-its-type-name-
    and-call-it-quits-early-ly y'rs  - tim