Re:ParTcl – a micro Tcl implementation
by evincarofautumn on Saturday February 18, 2017 @08:14PM
(#13677648)
Sure, dynamic types are types. And nothing stops you from running a full-featured typechecker at runtime, one that can enforce useful invariants beyond “expected int but got string”.
It’s just markedly more useful to me to have that information available statically. I like being able to modify code with the assurance that the compiler will tell me about all inconsistencies. I like that the compiler can prove that its automated transformations are correct. Of course, maybe that says more about the way I work than type systems themselves.
For an example of a respected academic discussing dynamic typing properly, recognizing it to be typing, see Henry Baker's paper The Nimble Type Inferencer for Common Lisp.
https://news.ycombinator.com/item?id=13616965
In dynamically typed code, it is often possible to logically infer the type without executing it, so that the same information which is known at run-time can be ascribed to nodes of the syntax.
These are not two different type systems; it's the same information, just known at different times to some degree of completeness.
Quote from the paper:
We have chosen to perform static type inference on programs in the dynamically-typed Common Lisp programming language [CLtL84]. Common Lisp-84 has a reasonably complex type system. This system involves 42 simple type specifiers, 4 standard type operators, and 21 type specialization forms. Common Lisp has the usual primitive integer and floating point types, characters, the traditional atoms and conses of Lisp, vectors, arrays, and strings. In addition, Common Lisp has a host of non-traditional datatypes, such as hash tables, readtables, and other special purpose types. The datatype system can also be extended through user-defined structures, which are analogous to structures in C and to records in Pascal and Ada.
No nonsense here about Common Lisp having just one type, the value cell.