Type systems (by alaric)
And, yet, people being people, they still have massive flamewars about which is best. When will they learn that there's no point? In any environment where there are two or more camps who all produce valid arguments as to why doing things the way the other camps do would be bad and, therefore, argue that their way is best... the one true answer is that there's no one true answer.
But that doesn't mean there can never be one ultimate programming language that's best for everyone... or even a few ultimate programming languages, each of which is best for a broad field (which is good news for people like me, who'd like to build one).
The answer is simple: embrace both approaches.
Look at Common Lisp (aka CL). Lisp is a dynamically typed language, but in CL one can put in optional type restrictions on variables, arguments, and data structure members. When they are present, the implementation may omit dynamic run-time typing information for those slots in memory, insert type checks when things of unknown type are assigned into those slots, and do compile-time type checks where values from those slots are used, omitting run-time checks where possible. So, depending on how widely the programmer places type declarations, the actual result can be fully dynamically typed, fully static, or a combination of the two with run-time type checks wherever a value passes from the dynamic world into the static world, and perhaps wrapping with dynamic type information when values travel the other way, if the implementation elects to store values in statically typed slots without wrapping.
The implementation may also do some type inferencing as well, to deduce more type declarations than the programmer has included, providing the benefits thereof without the costs.
This, I think, is a good approach. I can envisage taking it further, and having a compiler option that can be applied to a region of safety-critical code to state that run time type errors within that region of code are forbidden, in which case the compiler will signal an error if, while compiling that code, it finds a situation in which it would generate a run-time check, indicating that static type coverage is not complete.
But another important consideration for a programming language design is simplicity: and in this case, an implementation may choose to just act like a dynamic language, and convert all the type declarations into run-time type checks on every value entering that slot (or, for an even faster and looser implementation, not bother). So the complexity of inference and checking is entirely in the form of an optional extension that detects more bugs up front and improves the efficiency of generated code. Which is good! Ease of implementation of a language increases the amount of innovation around it.
Pages: 1 2
Thu 8th May 2008 2:10 pm 
Subscribe