Function types in complete type inference

We study type checking that is complete in the sense that it accepts every program whose subexpressions can all be executed without raising a type error at runtime. In a complete type checker for every function call (f a) of a function f with an argument expression a of type t(a) it is checked whether f is applicable to one of the possible values of a, i.e. whether <[t(a)]> boolean AND dom (f) not equal phi holds where <[t]> denotes the semantics of a type t. When approximating dom(f) by a type tin it turns out that the usual function type constructor is not appropriate for complete type checking: for a function type t(f) = t(in) --> t(out) of f the input type t(in) is usually not guaranteed to contain all values of dom(f) and the test for common elements can erroneously fail. We therefore introduce an alternative notion of function types, called I/O-representation, where the input types cover a superset of the domain of the denoted functions. We show that this notion of function types fits into the framework of complete type checking much better than the usual function type constructor. Moreover, we argue that complete type checking overcomes the disadvantages of soft-typing approaches by enabling the rejection of programs instead of just raising a warning.