The hypothetical strength of a type
In a previous post, I alluded to the idea that “weakly typed” and “strongly typed” have no clear definitions and they aren’t useful concepts. Generally, when it’s said “Language X is weakly typed”, one is led to think that “weakly typed” is a characteristic of language “X”. It may also lead one to think that a type or type system can be “weak” somehow.
In this post, I argue that so called “strong” and “weak” types are not a property of the type system — much less of a programming language — and that this strength notion is a mischaracterization of issues which arise whenever operators or functions are overloaded and the overloaded behaviors and the type combinations in the signatures become complex.
As a language designer, at first sight, overloading
+ seems like a great convenience which spares the programmer’s code from the noise of casts. But in practice, that versatility comes with a price.
In the code above, the first 2 lines are usually considered safe and predictable (i.e.,
execute_sql("SELECT * from table where col=" + (a + b) * 1.5)
a is the string
b is the number
2, it evaluates to:
execute_sql("SELECT * from table where col=153")
That is, instead of
a was the number
10) we get
153 as result. Presumably, because these operations don’t raise a type error when used with such diverse types but, instead, return a “normal” value, programmers seem to think the type system has been relaxed or weakened. But the behavior is simply a particularity of the operators themselves. These are operators that have been overloaded to a point that reasoning about them is not easy.
+ operator in a language like Haskell:
In this Haskell example, we created and overloaded the operator
By inspecting the code, we should conclude that assumptions about implicit casts are not needed as explanation for the perceived weakening of the typing rules. Rather, the diversity of types clearly defined in the signatures of the
+ operator could be modeled similarly as an overloaded function and conclude it‘s type can be precisely defined in a sound type system.
execute_sql("SELECT * from table where col=" + (a + b))
For an operator
+ overloaded to accept a mix of numbers and strings, the code above type-checks whether the variables
b are numbers or strings. Likely, the type checker could only identify a problem when, for example,
a is defined to be of a number type and the assignment of a string to it would fail.
Therefore, we can only conclude that “weakly typed” can’t be a characteristic of the language, nor of the type system. It it but a misnomer that merely indicates the presence of functions or operators with a complex/unintuitive signature/behavior where one is easily led to wrong assumptions about them [and there’s no static type checker to help]. Q.E.D.