Deciding ML typability is complete for deterministic exponential time

Abstract

A well known but incorrect piece of functional programming folklore is that ML expressions can be efficiently typed in polynomial time. In probing the truth of that folklore, various researchers, including Wand, Buneman, Kanellakis, and Mitchell, constructed simple counterexamples consisting of typable ML programs having length n, with principal types having R(2e") distinct type variables and length Q(2"'").When the types associated with these ML constructions were represented as directed acyclic graphs, their sizes grew as Q(2"').The folklore was even more strongly contradicted by the recent result of Kanellakis and Mitchell that simply deciding whether or not an ML expression is typable is PSPACE-hard.We improve the latter result, showing that deciding ML typability is DEXPTIME-hard. As Kanellakis and Mitchell have shown containment in DEXPTIME, the problem is DEXPTIME-complete.The proof of DEXPTIME-hardness is carried out via a generic reduction: it consists of a very straightforward simulation of any deterministic one-tape Turing machine M with input t running in O(cl'l) time by a polynomialsized ML formula CPM,=, such that M accepts x iff @M,= is typable. The simulation of the transition function 6 of the Turing Machine is realized uniquely through terms in the lambda calculus zoilhovl the use of the polymorphic let construct. We use let for two purposes only: to generate an exponential amount of blank tape for the Turing Machine simulation to begin, and to compose an exponential number of applications of the ML formula simulating state transition. ML [Mi78][HMM86] is a well known functional programming language incorporating a variety of novel features, and prominent in its contributions to programming language design is its polymorphic typing system. A strongly typed language like Pascal is completely type checked at compile time, obviating the need for runtime type checking; the penalty is that code which has been written in a largely "type independent" style (stacks, trees, or even the identity function) must be repeated with only changes in type declarations. On the other hand, a naive Lisp compiler will do no compile time type checking, allowing Lisp code to be freely reused on different data types, but the Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 0 1990 ACM 089791-3434/90/0001/0382 $1.50 382It is purely the expressive power of ML polymorphism to succinctly express function composition which results in a proof of DEXPTIME-hardness.We conjecture that lower bounds on deciding typability for extensions to the typed lambda calculus can be regarded precisely in terms of this expressive capacity for succinct function composition.To further underst...

Polyvariant Analysis of the Untyped Lambda Calculus

“…Note that the transformed program may become exponentially larger; this relates to ML type inference being DEXPTIME complete [14].…”

The complexity of type inference for higher-order typed lambda calculi

“…Because no value is 'used' more than once, no side-effecting of type variables occurs, and the fanout gates mentioned earlier, used in the proofs in Mairson (1990) and Kanellakis et al (1991), are not necessary.…”

Type inference with inequalities

“…Typability and type inference in ordinary A-systems has recently been shown to have similar com-/plexities [5], but in practice the running times are quite acceptable.…”