Strongly Typed

What are the TypesOfTyping?

I did just a little research a few months ago, trying to find out just what it meant for a language to be StronglyTyped.

My conclusion: there is no commonly agreed-upon meaning for 'strongly typed language'.

Similarly, Pascal was frequently cited as 'strongly typed' in contrast to C, even though the Pascal and C type systems are nearly identical and both Pascal and C both provide several mechanisms for evading compile-time type checks.

Other articles conflated 'strongly typed' with 'has compile-time type checking' (http://whatis.techtarget.com/definition/0,289893,sid9_gci213058,00.html for example.) It appears that 'strongly typed' may have at least the following meanings:

  1. A language is strongly typed if type annotations are associated with variable names, rather than with values. If types are attached to values, it is weakly typed.
  1. A language is strongly typed if it contains compile-time checks for type constraint violations. If checking is deferred to run time, it is weakly typed.
  1. A language is strongly typed if there are compile-time or run-time checks for type constraint violations. If no checking is done, it is weakly typed.
  1. A language is strongly typed if conversions between different types are forbidden. If such conversions are allowed, it is weakly typed.
  1. A language is strongly typed if conversions between different types must be indicated explicitly. If implicit conversions are performed, it is weakly typed.
  1. A language is strongly typed if there is no language-level way to disable or evade the type system. If there are casts or other type-evasive mechanisms, it is weakly typed.
  1. A language is strongly typed if it has a complex, fine-grained type system with compound types. If it has only a few types, or only scalar types, it is weakly typed.
  1. A language is strongly typed if the type of its data objects is fixed and does not vary over the lifetime of the object. If the type of a datum can change, the language is weakly typed.

I was repeatedly reminded of articles about the cold-war-era use of words like 'democratic', or recent uses of the word 'biased'. These words have ceased to have any objective meaning, and instead become epithets: our country is democratic, yours is not; your statements are biased, ours are not. These words are used automatically to describe anything at all, and their use by a single person may not be consistent with even that person's stated definition. For example, the author of #8 above (http://stofi.host.sk/fc_c.htm) contrasts the language 'Force' with C, using C as a 'weakly-typed' language, even though, according to the author's own definition, C is strongly typed.

I no longer use the phrases 'strongly typed' or 'strong typing'.

-- MarkJasonDominus

There is undoubly a lot of confusion about this term, however the the second definition given above seems right to me:

StronglyTyped languages are defined in the way which allows to check typing constraints at compile-time. No, that's StaticallyTyped.

According to this definition C, C++ or Java aren't StronglyTyped languages. In C and C++ there is pointer to void, Java has typing constrains 'leak' for arrays. ObjectiveCaml can be example of StronglyTyped language. In ObjectiveCaml compiler is able to check any type constraint at compile time.

-- PiotrWocal

No need to be confused- there always will be programmers that use such terms without understanding them, as there will always be people that use words they don't understand. Please see [[http://kahakai.sourceforge.net/wiki/index.php/StronglyTyped]]

-- imilev

The definition given there simply proves MarkJasonDominus' point:

Does not permit arbitrary, implicit conversion between types. For example adding a string constant to an int constant is usually forbidden. A StronglyTyped language checks type integrity of programs statically -- that is, at compile time. A program can never fail at runtime due to a type error. Ada, Haskell, ML and Java are all StronglyTyped languages.

Forbidding implicit conversion is a different and independent property from checking type integrity of programs at CompileTime. The latter is what most people would call StaticTyping, not strong typing. Java does allow implicit conversions in some cases. Java programs can fail at runtime due to a type error.

There's a problem here. It very often doesn't make sense to talk of a language of StronglyTyped, or StaticallyTyped, or whatever. One needs to draw a distinction between the language and the style it is being used in. Frequently a program will use both StaticallyTyped and DynamicallyTyped styles together. There is nothing inherently wrong with this.

A StaticallyTyped programming style means that one relies on the compiler to do type checking. A DynamicallyTyped programming style means that type checking is done at runtime.

A StronglyTyped programming style means that one works within the type system, that is, you don't arbitrarily convert from one type to another. A WeaklyTyped programming style means that you use something like a C cast or C++ reinterpret_cast<> to do exactly that.

Examples:

The freedom to adopt multiple styles has both benefits and drawbacks. For instance, WeaklyTyped programming allows to you go between raw memory and the type system (can be useful), but can make programs unmaintainable. So it's best to stay StronglyTyped where you can, but sometimes the freedom to get around the type system might be helpful (personally I don't ever seem to need this, but there you go).

WeaklyTyped programming is obviously the least popular of the 4 styles above. C more or less forces WeaklyTyped programming upon people, which is why people seem to think of it as a "WeaklyTyped language". But it makes more sense to say that "writing non-trivial programs in C will often only be possible by using a WeaklyTyped style".

Yeah, people get confused about this a lot. It's a rather fine grain of distinction, and it takes a bit of experience with a diverse group of languages to realize what people are talking about.

Firstly, 90% of the time, we don't talk about StrongTyping or WeakTyping (even if we say it). We usually mean StaticTyping and DynamicTyping.

StrongTyping and WeakTyping are more obscure and a little bit trickier. They can be tough to recognize within the context of the previous two.

int *my_int = malloc( sizeof( int ) ); // Make a memory address on the heap.
char *my_char = (char *)(my_int); // Note the typecast, a hallmark of this kind of programming
int **my_ptr_int = (int **)(my_int); // Another type.

We associate one heap address with several types of data. There really isn't an "authorative" representation here. The memory is just memory, and the syntax of C defines the type.

I know this repeats a bit of what's said above, but I wanted to consolidate what we had and add an example.

-- DaveFayram

Why say "C++ without the virtual keyword"? "virtual" doesn't get in the way of complete static typing.

Another difference between static and dynamic type checking is that static typing assigns types to a program's terms (i.e. the code), while dynamic typing assigns types to a program's runtime values.

Your description of "weak typing" seems to mean "a language that performs implicit conversions". This would imply that strong typing doesn't allow for different behavior in different contexts (such as C++-style method overloading). Also, I don't see how C is dynamically typed at all.

My preferred definition of strong/weak typing is when you make "strongly typed" synonymous with "has a powerful type system". "Using the programming language's type system, how accurately can you describe your data and algorithms?" It's a scale, not a yes/no thing. C++ is more strongly typed than C because it has parametric polymorphism (through templates), letting you create generic data types that are still accurately typed. Python is not as strongly typed as C++ because it can't accurately represent such types. C++ may have loopholes, but Python's type system is still weaker.

-- KannanGoundan

An even easier example is:

union { int i, char c, int *p };

BTW: "Translating" the above to Java would possibly result in a base class with three derived classes and accessing the "wrong" storage layout would be caught at run time. (But to play devils advocate: from the user's viewpoint, does it REALLY matter whether some application fails with a "BadCastException" thrown or for some other reason?)

When I made type errors like the union example in C++ the system crashed 4 releases and 6 months later in production. When I make type errors like this in Java the system crashes 2 seconds later in a unit test. FailFast is close to what this is about. Your mileage may vary, I am sure better bounds checkers, and operating systems other than Windows 3.1 would help.

See also TypingQuadrant, WeakAndStrongTyping, StronglyTypedCollection, StronglyTypedWithoutLoopholes.

CategoryLanguageTyping