Typeful programming

11.1. Syntax 11.2. Type rules 11.3. Library interfaces
6. Power kinds
6.1. Tuple subtypes 6.2. Option subtypes
Page 2
1. Introduction
There exists an identifiable programming style which is based on the widespread use of type information, and which relies on mechanical and transparent typechecking techniques to handle such information. This typeful programming style is in a sense independent of the language it is embedded in; it adapts equally well to functional, imperative, object-oriented, and algebraic programming, and it is not incompatible with relational and concurrent programming. Hence, it makes sense to discuss this programming style in a way that is relatively independent of particular flow-of-control paradigms, such as the ones just mentioned. Let us see more precisely what typeful programming is, and what it is not. The widespread use of type information is intended as a partial specification of a program. In this sense, one can say that typeful programming is just a special case of program specification, and one can read type as a synonym for specification, and typechecking as a synonym for verification in this discussion. This view fits well with the types as propositions paradigm of axiomatic semantics, and the propositions as types paradigm of intuitionistic logic. However, typeful programming is distinct from program specification in some fundamental ways. As we noted already, there must be a mechanical way of verifying that type constraints are respected by programs. The slogan here is that laws should be enforceable: unchecked constraining information, while often useful for documentation purposes, cannot be relied upon and is very hard to keep consistent in large software systems. In general, systems should not exhibit constraints that are not actively enforced at the earliest possible moment. In the case of typechecking the earliest moment is at compile-time, although some checks may have to be deferred until run-time. In contrast, some specifications can be neither typechecked nor deferred until run time, and require general theorem-proving (e.g., in verifying the property of being a constant function). Another emphasis is on transparent typing. It should be easy for a programmer to predict reliably which programs are going to typecheck. In other words, if a program fails to typecheck, the reason should be apparent. In automatic program verification, it may be hard in general to understand why a program failed to verify; at the current state of the art one may need to have a deep understanding of the inner workings of the verifier in order to correct the problem. The scope of typeful programming, as defined above, is limited. Typechecking will never merge with program verification, since the former requires mechanical checking and the latter is undecidable. We may however attempt to reduce this gap, on the one hand by integrating specifications as extensions of type systems, and on the other hand by increasing the sophistication of type systems. We intend to show that the latter road can already lead us quite far towards expressing program characteristics. The scope of typeful programming would also have another major limitation if we required programs to be completely statically typed. A statically typed language can be Turing-complete, but still not be able to express (the type of) an embedded eval function; this is important in many areas, and is just a symptom of similar problems occurring in compiler bootstrapping, in handling persistent data, etc. There are interesting ways in which statically checked languages can be extended to cover eval functions and other similar situations. The flavor of typeful programming is preserved if these extensions involve run-time type checks, and if these dynamic checks have a good relationship with corresponding static checks. Hence, typeful programming advocates static typing, as much as possible, and dynamic typing when necessary; the strict observance of either or both of these techniques leads to strong typing, intended as the absence of unchecked run-time type errors. The main purpose of this paper is to show how typeful programming is best supported by sophisticated type systems, and how these systems can help in clarifying programming issues and in adding power and regularity to languages. To a minor extent, the purpose of the paper is to motivate the use of typing in programming, as is done in the first few subsections, but in fact we take almost for granted the benefits of simple type systems. How should we go about explaining and justifying sophisticated type systems? One expository approach would involve listing and comparing all the different language design problems and solutions that have led to increasingly powerful notions of typing. This approach, however, may produce a very fragmented description of the field, and might not reveal much more information than can be gathered from language manuals and survey