[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"