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.

See StronglyTypedWithoutLoopholes.

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

An example for a statically, but weakly typed language is C. (http://compilers.iecc.com/comparch/article/95-10-071)
C is strongly typed... (http://www.cs.njit.edu/~elsa/280/280%20Lecture%2013_files/slide0138.htm) ( BrokenLink )
This works fine in weakly typed languages such as C. (http://www.mvps.org/vb/hardcore/html/typelessvariables.htm)
LISP engines ... are themselves generally written in strongly typed languages like C... (http://tlug.linux.or.jp/ML/0010/msg00352.html)
In a weakly typed language such as C, ... (http://www.cs.colorado.edu/~diwan/5535-99/hw-6-soln.html)
TYPE: strongly typed: (C, Algol, Fortran) (http://sweat.cs.unm.edu/~bap/teach/S2000/CS257/notes/lecture/2000-01-19.txt)

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:

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.
- Why this distinction? It seems potentially a matter of syntax and not semantics. See examples in ImplicitTyping. -t
- [The point is rather poorly described. In short, a strongly typed language does not permit the type of a variable (and, hence, the type of values it references) to change within the lifetime of that variable.]
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.
- This implies that all interpreted languages are "weakly typed". This is odd, since they may require things like explicit (run-time) type declarations of all vars. -t
- [Again, the point is poorly described. A language is strongly typed if, in general and wherever possible, it performs checks for type constraint violations before execution rather than during execution.]
- This implies that no purely-interpreted language can ever be "strongly typed" since by definition there is no "before execution" activity. Is this correct? -t
- [In every language there will be something identifiably "before execution"; what activity happens there depends on language and implementation.]
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.
- This is "static" versus "dynamic" typing, not a strong/weak determinant. -t
- [The point could have been simplified to "[a] language is strongly typed if there are checks for type constraint violations. If no checking is done, it is weakly typed." That is accurate. The distinction between "static" and "dynamic" typing is essentially defined by whether or not slot types & function return values can change at run-time under program control. In dynamically typed languages, they can. In statically typed languages, they cannot.]
A language is strongly typed if conversions between different types are forbidden. If such conversions are allowed, it is weakly typed.
A language is strongly typed if conversions between different types must be indicated explicitly. If implicit conversions are performed, it is weakly typed.
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.
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.
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:

C++ supports StaticallyTyped and DynamicallyTyped and StronglyTyped and WeaklyTyped programming
Java supports StaticallyTyped and DynamicallyTyped and StronglyTyped programming
Python supports DynamicallyTyped and StronglyTyped programming

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.

StaticTyping : Type checking occurs at compile time, with data available only in the source files and annotations. (This incldues ManifestTyping and TypeInference). C++ without the virtual keyword or typecasts would fit this profile. ML derivatives also fit this profile.
DynamicTyping: Type checking occurs at runtime. A type error generally cannot occur at compile time (although some languages blur these lines). Ruby is a good example of a language that follows this paradigm.

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

StrongTyping : Values are strongly associated with a type, and this type cannot be changed. An int is an int, no matter what lexical variable points at it. Conversions from one type to another are accomplished by constructing a new data object out of the old one, not by converting the same data value to a new type. Many lanuages with DynamicTyping use this. Scheme is an example of a language with StrongTyping and DynamicTyping.
- Delphi/Pascal is an example. An int is an int no matter what time of day. A programmer must use StrToInt? and IntToStr? functions/procedures and etc. to convert one type to another.
WeakTyping : Vales are not strongly associated with a type. Usually, they are just values that may be interpreted in variety of ways dependon on the lexical variable that references them. This kind of typing is a bit funky when applied with DynamicTyping, so a Dynamically and Weakly Typed language is a rare thing. A good example of this is C. To see what we mean by this, consider the following C snippet:

  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.

CategoryLanguageTyping