[Types-sig] Type inferencing
Paul Prescod
paul@prescod.net
Mon, 13 Dec 1999 21:54:41 -0800
> > #3. The first version of the system will not define the operation of a
> > type inferencing system. For now, all type declarations would need to
> > be explicit.
>
> I expect that this will make the system relatively heavy-weight and
> hence unpythonic. You'd be sprinkling way more type decls over your
> source code than would be necessary with a somewhat more sophisticated
> type checker.
Point taken. I am only willing to do type inferencing up to a function
level. After my "ML Experience" I am not willing to do it globally. A
method with no type declaration should be presumed to return Object,
even if it is like this:
def foo():
return "abc"
Otherwise you get the problem where changing a line of code in the
middle of a function somewhere breaks code somewhere far away:
type-check
StringType
def a():
return b()
def b():
return c()
def c():
if something():
return "abc"
else
return 1
Under my plan, the very first function would never have been statically
checkable. So the code far away couldn't have broken it. But I am
willing to take type inference this far:
type-check
StringType
def a():
a="abc"
return a
This seems no harder than the type inferencing you need to do to check
the type of expressions. Probably the only reason that Java and C don't
do this is because they want to know what size of space to allocate on
the stack. Of course we won't worry about that.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"Unwisely, Santa offered a teddy bear to James, unaware that he had
been mauled by a grizzly earlier that year." - Timothy Burton, "James"