In designing a programming language, it is conventional wisdom that one must decide quite early whether its type system will be static or dynamic. If it is static, then all the types must be resolved at compile time, without any knowledge of the actual data the program will operate on. On the other hand, if it is dynamic, then all the types must be resolved at the moment it is necessary, with no way of anticipating potential errors or optimizations in advance. We show that the primary reason for this dichotomy is the common notion of mutability, and propose a system of "lucid types" which provides static-like analysis in the runtime environment, while smoothly permitting fully dynamic typing and fully compile-time typing as two ends of a continuum.
Programs for digital computers are comprised of and operate on only collections of bits, but for reasons of abstraction, we prefer to build taxonomies of these collections: classifying one bitstring as a floating-point number, to be interpreted as a mantissa, sign, and exponent; while classifying another as a cons cell, to be interpreted as two concatenated memory locations. The way these taxonomies are managed, at an abstract level, is what we call a type system.
Generally, type systems fall into two agreed-upon categories: static and dynamic [1]. In static type systems, an exact type specification for every variable and function is determined at compile time, either through mandatory specification, or type inference. If any type mismatches are forced anywhere in the program, the type system will be unable to do this, so it will signal an error and the program will not compile. In a dynamic type system, the type of each variable is tracked at runtime, along with its value, and may change depending on program input. If at some point a function is invoked on a variable whose type it cannot accept, a runtime type error is signaled.
| [1] | Some authors suggest a third possibility, called "duck typing." This is a type system in which every variable takes a standard "object" type, and can receive "messages" of various types (corresponding to method calls they support), and a type mismatch is redefined as the situation when an object can not respond to a message it is sent. It is our position that duck typing is not a feature of the type system itself, but rather a language feature, combined with a possible implementation strategy, for implicitly representing polymorphism. In all cases we are aware of, "duck typing" is implemented in dynamically typed languages (Ruby, JavaScript, Smalltalk), but in principle it could be implemented in a statically typed language as well, so it does not truly represent a third option. |