304 Chapter 6 Data Types
of one type and using it as if it were of a different type. This kind of conver-
sion is sometimes called a nonconverting cast. Unchecked conversions can be
useful for user-defined storage allocation and deallocation operations, in which
addresses are manipulated as integers but must be used as pointers. Because no
checking is done in Unchecked_Conversion, it is the programmer’s respon-
sibility to ensure that the use of a value gotten from it is meaningful.
C and C++ are not strongly typed languages because both include union
types, which are not type checked.
ML is strongly typed, even though the types of some function parameters
may not be known at compile time. F# is strongly typed.
Java and C#, although they are based on C++, are strongly typed in the
same sense as Ada. Types can be explicitly cast, which could result in a type
error. However, there are no implicit ways type errors can go undetected.
The coercion rules of a language have an important effect on the value of
type checking. For example, expressions are strongly typed in Java. However,
an arithmetic operator with one floating-point operand and one integer oper-
and is legal. The value of the integer operand is coerced to floating-point, and
a floating-point operation takes place. This is what is usually intended by the
programmer. However, the coercion also results in a loss of one of the benefits
of strong typing—error detection. For example, suppose a program had the
int variables a and b and the float variable d. Now, if a programmer meant
to type a + b, but mistakenly typed a + d, the error would not be detected
by the compiler. The value of a would simply be coerced to float. So, the
value of strong typing is weakened by coercion. Languages with a great deal of
coercion, like C, and C++, are less reliable than those with little coercion, such
as Ada, and those with no coercion, such as ML and F#. Java and C# have half
as many assignment type coercions as C++, so their error detection is better
than that of C++, but still not nearly as effective as that of ML and F#. The
issue of coercion is examined in detail in Chapter 7.6.14 Type Equivalence..........................................................................
The idea of type compatibility was defined when the issue of type checking was
introduced. The compatibility rules dictate the types of operands that are
acceptable for each of the operators and thereby specify the possible type errors
of the language.^10 The rules are called compatibility because in some cases the
type of an operand can be implicitly converted by the compiler or run-time
system to make it acceptable to the operator.
The type compatibility rules are simple and rigid for the predefined scalar
types. However, in the cases of structured types, such as arrays and records and- Type compatibility is also an issue in the relationship between the actual parameters in a
subprogram call and the formal parameters of the subprogram definition. This issue is dis-
cussed in Chapter 9.