614 TYPING $17.1 We will say that a language is realistic if it is both useful and usable.Unlike the definition of static typing,which always yields an indisputable answer to the question"Is language X statically typed?",the definition of realism is partly subjective;reasonable people may disagree on whether a language,equipped with certain type rules,is still useful and usable In this chapter we will check that the ty ped notation defined in the preceding chapters is realistic. Pessimism In discussing approaches to O-O typing we should keep in mind another general property of static typing:it is always,by nature,a pessimistic policy.Trying to guarantee that no computation shall ever fail,you disallow some computations that might succeed. To see this,consider a trivial non-O-O language,Pascal-like,with distinct types INTEGER and REAL.With the declaration n:INTEGER,the assignment n:=r will be rejected as violating the type rules.So all the following will be considered type-invalid and rejected by the compiler: n=0.0 [A] n=1.0 [B] n=-3.67 [C] n=3.67-3.67 [D] Of these invalid operations,[A],if permitted to execute,would always work since any number system will provide an exact representation for the floating-point number 0.0, which can be transformed unambiguously to the integer 0.[B]would almost certainly work too.[C]is ambiguous(do we want the rounded version,the truncated version of the number?)But [D]would work.So would if n2<0 then n :3.67 end E] because the assignment will never be executed (n^2 denotes the square of n).If we replace n2 by just n,where n is read from user input just before the test,some executions would work (those for which n is non-negative),others would not.Assigning to n a very large real number,not representable as an integer,would not work. In a typed language,all these examples-those which would always work,those which would never work,and those which would work some of the time-are equally and mercilessly considered violations of the type rules,and any compiler will reject them. The question then is not whether to be pessimistic but how pessimistic we can afford to be.We are back to the realism requirement:if the type rules are so pessimistic as to bar us from expressing in a simple way the computations that we need,we will reject them.But if they achieve type safety with little loss of expressive power,we will accept them and enjoy the benefits.For example making n=rinvalid turns out to be good news if the environment provides functions such as round and truncate,enabling you to convert a real into an integer in exactly the way you want,without the ambiguity of an implicit conversion.614 TYPING §17.1 We will say that a language is realistic if it is both useful and usable. Unlike the definition of static typing, which always yields an indisputable answer to the question “Is language X statically typed?”, the definition of realism is partly subjective; reasonable people may disagree on whether a language, equipped with certain type rules, is still useful and usable. In this chapter we will check that the typed notation defined in the preceding chapters is realistic. Pessimism In discussing approaches to O-O typing we should keep in mind another general property of static typing: it is always, by nature, a pessimistic policy. Trying to guarantee that no computation shall ever fail, you disallow some computations that might succeed. To see this, consider a trivial non-O-O language, Pascal-like, with distinct types INTEGER and REAL. With the declaration n: INTEGER, the assignment n := r will be rejected as violating the type rules. So all the following will be considered type-invalid and rejected by the compiler: n := 0.0 [A] n := 1.0 [B] n := —3.67 [C] n := 3.67 — 3.67 [D] Of these invalid operations, [A], if permitted to execute, would always work since any number system will provide an exact representation for the floating-point number 0.0, which can be transformed unambiguously to the integer 0. [B] would almost certainly work too. [C] is ambiguous (do we want the rounded version, the truncated version of the number?) But [D] would work. So would if n ^ 2 < 0 then n := 3.67 end [E] because the assignment will never be executed (n ^ 2 denotes the square of n). If we replace n ^ 2 by just n, where n is read from user input just before the test, some executions would work (those for which n is non-negative), others would not. Assigning to n a very large real number, not representable as an integer, would not work. In a typed language, all these examples — those which would always work, those which would never work, and those which would work some of the time — are equally and mercilessly considered violations of the type rules, and any compiler will reject them. The question then is not whether to be pessimistic but how pessimistic we can afford to be. We are back to the realism requirement: if the type rules are so pessimistic as to bar us from expressing in a simple way the computations that we need, we will reject them. But if they achieve type safety with little loss of expressive power, we will accept them and enjoy the benefits. For example making n := r invalid turns out to be good news if the environment provides functions such as round and truncate, enabling you to convert a real into an integer in exactly the way you want, without the ambiguity of an implicit conversion