[Types-sig] Sample declarations
Wed, 14 Mar 2001 01:04:54 +0100
> I think the real problem is the possibility that identifiers can get
> rebound at almost any point in time. Other than that, python's type rules
> aren't that much more complex. Also, I'm not attempting to suggest we do
> type inference, just "type check hoisting".
> Again, I think you misunderstood the idea... in the limit it leaves your
> Python program alone. If it can move the type error earlier it does. I don't
> promise much in the way of ruling out type errors. I'm just suggesting a way
> to make sure the type errors are reported earlier, if they occur.
If I understood well your suggesting that some code analysis given the
could infere we could for example check param a for "having" __getitem__
directly at the beginning of f. Yes it could. I don't think that we can in
general infere checking for being a float or an int. You're saying that a
problem is so to say the excess of dynamism of python, this is true
(also wrt opt).
But I continue not to understand why languages like ML are cited as
an example, they have polymorphism in the form of parametric types.
Python has just crude polymorphism (like Smalltalk or Self):
any parameters that support + (int,float, ... exposing __add__ or __radd__) can
do the job here and are ok, if we add type checks or annotations they fix
programmer intentions (about usage) or supply information about the context,
from the correctness viewpoint what is really important are the
(calling&called) contexts, we can infere nothing about them because python is
too dynamic, has reflective features and dynamic loading, we cannot make any
closed world assumption and in any case the whole call graph problem is
difficult and would require type inference (as everybody knows in the case
of python and similar the two make together a fix-point problem).
This context problem limit a lot the amount of error checking that
one can hoist...
regards, Samuele Pedroni.