This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Improving Static Typing
Feed Title: David Buck - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/buck-rss.xml
Feed Description: Smalltalk can do that
I often hear the argument that static typing catches a class of errors that would otherwise only be caught at runtime. Runtime errors can only be caught by testing but you can't guarantee that testing will find all the bugs. Because of this, code written in a statically typed language is more reliable than code written in a dynamically typed language. People will argue that code correctness is more important than readability or programmer productivity.
There are, however, other classes of errors which you can run across which are just as deadly (if not more so) than type errors. For example,
Arrays indexed out of bounds errors
Divide by zero errors
Integer overflows
Null pointer errors
With a better static type system, however, we can get the compiler to catch all of these problems. Let's see what it would take.
For arrays indexed out or bounds, the solution is simple. Pascal includes Integer subrange types. We could force all array accesses to use only Integer subranges as indices. For example,
The compiler should automatically coerce more specific types into more general types - you should be able to assign a variable of type [0..10] to a variable of type [0..20]. You should be able to have types of arbitrary size like [0..INF] or [-INF..INF] where INF means infinity. In these cases, the system can automatically use Big Integers. If you really want the equivalent of "short", you would use [-32768..32767]
To catch a divide by zero error, you require that the denominator be non-zero. To do this, we need to allow unions of types. For example, [-INF..-1 | 1..INF] is an appropriate type for the demoninator of a division.
Now, what happens if you have a variable with a more general type and you need to use it in a place that needs a more specific type? You have to use a type-split. Type-splits split a generic type into multiple specific types. Here's what it would look like:
This takes a variable "a" and casts it to "a1" if it's non-zero then runs the non-zero block. If it's zero, it casts it as 0 and assigns it to a2 then runs the zero block.
How about Integer overflow? This mechanism solves that too. Suppose you want to ensure that you want to add one short to another and assign the result into a short without overflow. You would just do this:
short a;
short b;
type-split (a + b) {
[-32768..32767] -> x { ...more code...};
[-INF..-32769 | 32768..INF] -> y {...overflow code...};
}
Of course, you must use type-splits on every add, subtract or multiply unless you always use [-INF..INF].
I'll leave null pointer errors as an exercise to the reader.
So, by improving our static type system, we can detect array indexing out of bounds, divide by zeros, integer overflows and null pointer errors all at compile time - no need to worry about any of these problems ever again.
What does this do to the readability of the code and the productivity of the programmer? Well, as we said before, that doesn't matter at all. Code correctness is paramount. If it helps eliminate these nasty runtime errors, it's worth it.
Incidently, if anybody does create a language that implements this type system, please don't make me use it. :-)
Previous Topic
