During the 80's and early 90's, high-level programming languages supported two different type-checking philosophies: static typing, and dynamic typing. Statically typed programming languages ensured that all programs conformed to a set of typing rules, which implied that programs could not "go wrong". Non-conforming programs were rejected. Dynamically typed programming languages, in contrast, did not reject programs, but rather checked for "type errors" during program execution. ML and Scheme were the prototypical respresentatives of the static and dynamic approachs to typing.Each typing philosophy had distinct advantages and disadvantages. Static typing does not require as much run-time type checking, and the detection of non-conformance supplies programmers with potentially valuable debugging information. The disadvantage of static typing, however, is that are some well-written, meaningful programs that never generate type errors at run time but do not conform to a given system of static typing rules. Semantic typecorrectness is undecidable. As a result, a programmer must rewrite such a program to conform to the type rules.In contrast, dynamic typing permits all programs to be executed, but fails to detect obvious type errors at compile time. Dynamic typing is more flexible at the cost of failing to detect type errors statically.Soft typing seeks to combine the advantages of static typing with the flexibility of dynamic typing. In other words, it provides the expressiveness of a dynamically typed language but it detects and flags potential type errors statically.In our paper, we focused on a core functional language similar to the functional core of both ML and Scheme, presuming that the non-functional features could be handled by extensions to our type system similar to those used in ML. Our key observation was that a type inference engine could be used to insert dynamic run-time checks where needed and inform a programmer that such checks were necessary. The inference engine, however, did not reject programs.At this stage, we noted that the standard ML Hindley-Milner type inference algorithm could be used as a soft type engine for a Scheme-like functional language. After trying the idea on some typical example programs, however, we noted that many typical Scheme programs would need unnecessary run-time checks. The troublesome programs we considered used union types and recursive types. Consequently, we next investigated ways to include true 20 union types (not discriminated union types as in ML) and recursive types in our soft typing system.The second phase of our soft typing research concerned our effort to add union types and recursive types to a Hindley-Milner type inference engine. Recursive types could be added by using circular unification instead of classical unification. Union types, however, have a subtype relation that seems to be inconsistent with the disjoint class assumption of traditional unification methods. Using a classical mathematical technique called slack variables, we could convert subty...
