1. Names, Bindings, Type Checking, and Scopes
Chapter 5
Names, Bindings, Type Checking, and Scopes

2. Type Equivalence

3. Why Type Equivalence Is Needed?
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 user-defined types, the rules are more complex.
Coercion of these types is rare, so the issue is not type compatibility, but type equivalence.

4. Categories of Type Equivalence
There are two approaches to defining type equivalence:
Name type equivalence
Structure type equivalence
There are some variations of these two approaches, and many languages use combinations of them.

5. Name Type Equivalence
Name type equivalence means that two variables have equivalent types if they are defined
in the same declaration or
in declarations that use the same type name.

6. Structure Type Equivalence
Structure type equivalence means that two variables have equivalent types if their types have identical structures.

7. Name Type Equivalence Is Highly Restrictive
Name type equivalence is easy to implement but is more restrictive.
e.g. Under a strict interpretation, a variable whose type is a subrange of the integers would not be equivalent to an integer type variable.

8. Example
Supposing Ada used strict name type equivalence, consider the following Ada code:
type Indextype is ;
count : Ineger;
index : Indextype;
The types of the variables count and index would not be equivalent; count could not be assigned to index or vice versa.

9. A Problem of Name Type Equivalence
When a structured type is passed among subprograms through parameters, such a type must be defined only once, globally.
A subprogram cannot state the type of such formal parameters in local terms.
This is the case with the original version of Pascal.

10. Name Type Equivalence and Type Name
To use name type equivalence, all types must have names.
Most languages allow users to define types that are anonymous – they do not have names.
For a language to use name type equivalence, such types must implicitly be given internal names by the compiler.

11. Implementation Difficulty of Structure Type Equivalence
Structure type equivalence is more flexible than name type equivalence, but it is more difficult to implement.
Under name type equivalence, only the two type names must be compared to determine equivalence.
Under structure type equivalence, the entire structures of the two types must be compared.

12. A Weakness of Structure Type Equivalence
Structure type equivalence disallows differentiating between types with the same structure.
For example, consider the following declarations:
type celsius = Float;
fahrenheit = Float;
Variables of these two types are considered equivalent under structure type equivalence, allowing them to be mixed in expressions.
The above equivalence is undesirable, because in general, types with different names are likely to be abstractions of different categories of problem values and should not be considered equivalent.

13. Type Equivalence of Ada
Ada uses a restrict form of name type equivalence, but provides two type constructs, subtypes and derived types to create types from existing types.

14. Derived Types
An Ada derived type is a NEW type that is based on some previously defined type with which it is not equivalent, although it may have identical structure.
Derived types inherit all the properties of their parent types.
Derived types can also include range constraints on the parent type, while still inheriting all of the parent's operations.

15. Example of Derived Types
type celsius is new FLOAT;
type fahrenheit is new FLOAT;
Variables of these two derived types are not equivalent, although their structures are identical.
Furthermore, variables of both type are not type equivalent with any other floating-point type.

16. The Type of Literals in Ada
Literals are exempt from the rule imposed upon derived types.
A literal such as 3.0 has the type universal real and is type equivalent to any floating-point type.

17. Ada Subtypes
An Ada subtype is a possibly range-constrained version of an existing type.
A subtype is type equivalent with its parent type.

18. Ada Subtype Example For example, consider the following declaration:
subtype Small_type is Integer range 0..99;
The type Small_type is equivalent to the type Integer.

19. Array Types in Ada Array types may be constrained types or
unconstrained types.

20. Constrained Array Types in Ada
Constrained array types have a predefined size.
E.g.
type Int_Buffer is array (1..10) of Integer;

21. Unconstrained Array Types in Ada
In Ada we can also declare unconstrained array types. That means, when the array is declared, the index type is specified but there is no need to state limits for the index, instead the symbol <> is used.
When an object of an unconstrained array type is declared, the index constraints must be stated.
type Vector is array (Integer range <>) of Character;
Vector_1 : Vector ( );

22. Example
For example, consider the following type declaration and two object declarations
type Vector is array (Integer range <>) of Integer;
Vector 1: Vector (1..10);
Vector 2: Vector (11..20);
The types of these two objects are equivalent, even though they have different names and different subscript ranges, because for objects of unconstrained array types, structure type equivalence rather than name type equivalence is used.
P.S.: Both types have ten elements and the elements of both are of type Integer.

23. Scope

24. The Scope of a Program Variable
The scope of a program variable is the range of statements in which the variable is visible.
A variable is visible in a statement if it can be referenced in that statement.

25. The Scope Rules of a Language
determine how a particular occurrence of a name is associated with a variable.
determine how references to variables declared outside the currently executing subprogram or block are associated with their declarations and thus their attributes.

26. Local Variables vs. Non-local Variables
A variable is local in a program unit or block if it is declared there.
The nonlocal variables of a program unit or block are those that are visible within the program unit or block but are not declared there.

27. Static Scoping
Static scoping is thus named because the scope of a variable can be statically determined, that is, prior to execution.

28. Categories of Static-scoped Languages
Those in which subprograms cannot be nested.
Those in which subprograms can be nested, which creates nested static scopes.
Ada, JavaScript, and PHP allow nested subprograms, which can create a hierarchy of scopes in a program.
but the C-based languages do not.

29. Assumption
The discussion of static scoping in this chapter focuses on those languages that allow nested subgprgrams.
So, for now we assume:
that all scopes are associated with program units.

30. Determine the Attributes of a Referred Variable
In a static-scoped language, for a reference to a variable, the attributes of the variable can be determined by finding the statement in which it is declared.

31. Suppose a reference is made to a variable x in subprogram Sub1.
Find the Declaration Statement of a Variable in Static Scoped Languages with Nested Subprograms
Suppose a reference is made to a variable x in subprogram Sub1.
The correct declaration is found by first searching the declarations of subprogram Sub1.
If no declaration is found for the variable there, the search continues in the declarations of the subprogram that declared subprogram Sub1, which is called its static parent.
If a declaration of x is not found there, the search continues to the next larger enclosing unit (the unit that declared Sub1's parent), and so forth, until
a declaration for x is found or
the largest unit's declarations have been searched without success. In that case, an undeclared variable error has been detected.

32. Static Ancestors of a Subprogram
The static parent of subprogram Sub1, and its static parent, and so forth up to and including the largest enclosing subprogram, are called the static ancestors of Sub1.

33. A Static Scoping Example
Under static scoping, the reference to the variable X in Sub2 is to the X declared in the procedure Big.
This is true because the search for X begins in the procedure in which the reference occurs, Sub2, but no declaration for X is found there. The search thus continues in the static parent of Sub2, Big, where the declaration of X is found.
procedure Big is
X : Integer;
procedure Sub1 is
begin -- of Sub1
...
end; of Sub1
procedure Sub2 is
begin -- of Sub2
...X...
end; -- of Sub2
begin of Big
end; of Big

34. Hide Variable Declarations
In some languages that use static scoping, regardless of whether nested subprograms are allowed, some variable declarations can be hidden from some other code segments.

35. Example
The reference to count in the while loop is to that loop’s local count. In this case, the count of sub is hidden from the code inside the while loop.
In general, a declaration for a variable effectively hides any declaration of a variable with the same name in a larger enclosing scope.
void sub() {
int count; …
while (…) {
int count;
count++; }

36. Selective References
In Ada, hidden variables from ancestor scopes can be accessed with selective references, which include the ancestor scope's name.
For example, in the preceding procedure, Big, the X declared in Big can be accessed in Sub1 by the reference Big.X.
P.S.: The textbook is wrong.

37. Global Variables
Although C and C++ do not allow subprograms to be nested inside other subprogram definitions, they do have global variables.
These variables are declared outside any subprogram definition.
Local variables can hide these globals, as in Ada.
In C++, such hidden globals can be accessed using the scope operator (::).
For example, if x is a global that is hidden in a subprogram by a local named x, the global could be referenced as ::x.

38. Blocks
Many languages allow NEW static scopes to be defined in the midst of executable code.
This powerful concept, introduced in ALGOL 60, allows a section of code to have its own local variables whose scope is minimized.
Such variables are typically stack dynamic, so they have their storage allocated when the section is entered and deallocated when the section is exited.
Such a section of code is called a block.

39. Specify Blocks in Ada
In Ada, blocks are specified with declare clauses, as in
...
declare TEMP : Integer;
begin
Temp := First;
First := Second;
Second := Temp;
end;

40. In C-based Languages Blocks Could Be Created by Compound Statements
The C-based languages (such as C, C++, and Java) allow any compound statement (a statement sequence surrounded by matched braces) to have declarations and thus define a new scope. Such compound statements are blocks.
For example, if list were an integer array, one could write
if (list[i] < listf[j]) {
int temp;
temp = list[i];
list[i] = listf[j];
llst[j] = temp; }

41. Scopes Created by Blocks
The scopes created by blocks are treated exactly like those created by subprograms.
References to variables in a block that are not declared there are connected to declarations by searching enclosing scopes in order of increasing size.

42. Scope Rules for C++ and C
C++ allows variable definitions to appear anywhere in functions.
When a definition appears at a position other than at the beginning of a function, but not within a block, that variable's scope is from its definition statement to the end of the function.
Note that in C, all data declarations in a function but not in blocks within the function MUST appear at the beginning of the function.

43. Scope Rules for Variables Defined in for Statements in C++, Java, and C#
The for statements of C++, Java, and C# allow variable definitions in their initialization expressions.
In early versions of C++, the scope of such a variable was from its definition to the end of the smallest enclosing block.
In the standard version, however, the scope is restricted to the for construct, as is the case with Java.

44. Example
void fun() {
...
for (int count = 0; count < 10; count++) }
In early version of C++, the scope of count would be from the for statement to the end of the method.
In later versions, as well as in Java and C#, the scope of count would be from the for statement to the end of its body.

45. Evaluation of Static Scoping

46. Assumptions for the Analysis of the Drawbacks of Static Scoping
Static scoping provides a method of nonlocal access that works well in many situations. However, it is not without its problems.
Based on the program whose skeletal structure is shown in Figure 5.1, in the following slides, we will discuss its weakness.
For the program in Figure 5.1, assume that all scopes are created by the definitions of the main program and the procedures.

47. The Structure of an Example Program
This program contains an overall scope for main, with two procedures that define scopes inside main, A and B.
Inside A are scopes for the procedures C and D.
Inside B is the scope of procedure E.
We assume that the necessary data and procedure access determined the structure of this program.
The required procedure access is as follows: main can call A and B, A can call C and D, and B can call A and E.

48. The Tree Representation of the Scopes of the Previous Example Program
View the structure of the program as a tree in which each node represents a procedure and thus a scope.
A tree representation of the program of Figure 5.1 is shown in Figure 5.2.

49. The Potential Call Graph of the Previous Example Program
However, a graph of the potential procedure calls of this system, shown in Figure 5.3, shows that a great deal of calling opportunity beyond that required is possible.
This call graph has nothing to do with the nested scoping.

50. The Graph of the Desirable Calls

51. Access to Procedures Should Be Restricted
Figures 5.3 and 5.4 illustrates the number of possible calls that are not necessary in this specific application.
A programmer could mistakenly call a subprogram that should not have been callable, which would not be detected as an error by the compiler.
The above situation delays detection of the error until run time, which may make its correction more costly.
Therefore, access to procedures should be restricted to those that are necessary.

52. Unnecessary Visibility of Variables
Too much data access is a closely related problem.
For example, all variables declared in the main program are visible to all of the procedures, whether or not that is desired, and there is no way to avoid it.

53. Assumptions
Suppose that after the program has been developed and tested, a modification of its specification is required.
In particular, suppose that procedure E must now gain access to some variables of the scope of D.

54. Solution One (Moving E inside the Scope of D) and Its Drawback
One way to provide that access is to move E inside the scope of D.
But then E can no longer access the scope of B, which it presumably needs.

55. Solution Two (Moving Variables Needed into main Procedure) and Its Weakness
Another solution is to move the variables defined in D that are needed by E into main.
This would allow access by all the procedures, which would be more than is needed and thus creates the possibility of incorrect accesses.
For example, a misspelled identifier in a procedure can be taken as a reference to an identifier in some enclosing scope, instead of being detected as an error.

56. Another Disadvantage of Solution Two –Variables Needed Becomes Invisible
Suppose the variable that is moved to main is named x, and x is needed by D and E. But suppose that there is a variable named x declared in A. That would hide the correct x from its original owner, D.

57. More Disadvantage of Solution Two
One final problem with moving the declaration of x to main is that it is harmful to readability to have the declaration of variables so far from their uses.

58. Problems of Subprogram Visibility with Static Scoping
[Premise] In the tree of Figure 5.2, suppose that, due to some specification change, procedure E needed to call procedure D.
The above change could only be accomplished by moving D to nest directly in main, assuming that it was also needed by either A or C.
It would then also lose access to the variables defined in A.
This solution, when used repeatedly, results in programs that begin with long lists of low-level utility procedures.

59. Drawbacks of Static Scoping
Designers are encouraged to use far more globals than are necessary.
All procedures can end up being nested at the same level, in the main program, using globals instead of deeper levels of nesting.
This approach makes the layout of procedures of a program looking like the layout of a C program.
Solution:
Encapsulation construct (discussed in Chapter 11)

60. Dynamic Scoping
Dynamic scoping is based on the calling sequence of subprograms, not on their spatial relationship to each other.
Thus the scope can be determined ONLY at run time.

61. Example Program Dynamic scoping rules apply to nonlocal references.
The meaning of the identifier X referenced in Sub2 is dynamic—it cannot be determined at compile time. It may reference the variable from either declaration of X, depending on the calling sequence.
procedure Big is
X : Integer;
procedure Sub1 is
begin -- of Sub1
...
end; of Sub1
procedure Sub2 is
begin -- of Sub2
...X...
end; -- of Sub2
begin of Big
end; of Big

62. Finding the Meaning of a X of the Previous Program
One way the correct meaning of X can be determined at run time is to begin the search with the local declarations.
This is also the way static scoping began, but that is where the similarity between the two techniques ends.
When the search of local declarations fails, the declarations of the dynamic parent, or calling procedure, are searched.
If a declaration for X is not found there, the search continues in that procedure's dynamic parent, and so forth, until a declaration for X is found.
If none is found in any dynamic ancestor, it is a run-time error.

63. Examples of Finding the Declaration of a Variable
Consider the two different call sequences for Sub2 in the example above.
First, Big calls Sub1, which calls Sub2. In this case, the search proceeds from the local procedure, Sub2, to its caller, Sub1, where a declaration for X is found. So the reference to X in Sub2 in this case is to the X declared in Sub1.
Next, Sub2 is called directly from Big. In this case, the dynamic parent of Sub2 is Big, and the reference is to the X declared in Big.
P.S.: If static scoping were used, in either calling sequence discussed, the reference to X in Sub2 would be to Big’s X.

64. Properties of Dynamic Scoping
The correct attributes of nonlocal variables visible to a program statement cannot be determined statically.
Furthermore, such variables are not always the same.
A statement in a subprogram that contains a reference to a nonlocal variable can refer to different nonlocal variables during different executions of the subprogam.
Several kinds of programming problems follow directly form dynamic scoping.

65. Programming Problems Caused by Dynamic Scoping – (1)
During the time span beginning when a subprogram begins its execution and ending when that execution ends, the local variables of the subprogram are all visible to any other executing subprogram, regardless of its textual proximity.
There is no way to protect local variables from this accessibility.
Subprograms are ALWAYS executed in the environment of all previously called subprograms that have not yet completed their execution.
Therefore, dynamic scoping results in less reliable programs than static scoping.

66. Programming Problems Caused by Dynamic Scoping – (2)
A second problem with dynamic scoping is the inability to statically type check references to nonlocals.
This results from the inability to statically determine the declaration for a variable referenced as a nonlocal.

67. Programming Problems Caused by Dynamic Scoping – (3)
Dynamic scoping also makes programs much more difficult to read, because the calling sequence of subprograms must be known to determine the meaning of references to nonlocal variables.
The above task can be virtually impossible for a human reader.

68. Programming Problems Caused by Dynamic Scoping – (4)
Finally, accesses to nonlocal variables in dynamic scoped languages take far longer than accesses to nonlocals when static scoping is used.
The reason for this is explained in Chapter 10.

69. Advantage of Dynamic Scoping
In some cases, the parameters passed from one subprogram to another are simply variables that are defined in the caller.
NONE of these need to be passed in a dynamically scoped language, because they are implicitly visible in the called subprogram.

70. Dynamic Scoping Is not as Widely Used as Static Scoping
Programs in static scoped languages
are easier to read
are more reliable
execute faster than equivalent programs in dynamic scoped languages.
It was precisely for these reasons that dynamic scoping was replaced by static scoping in most current dialects of LISP.

71. Scope vs. Lifetime Scope and lifetime are different concepts.
Static scope is a textual, or spatial, concept.
Lifetime is a temporal concept.

72. The Scope and Lifetime of a C and C++ Variable – (1)
In C and C++, a variable that is declared in a function using the specifier static is
statically bound to the scope of that function
and
is also statically bound to storage.
So its scope is static and local to the function.
But its lifetime extends over the entire execution of the program of which it is a part.

73. The Scope and Lifetime of a C and C++ Variable – (2)
Consider the following C++ functions:
void printheader() {
...
} /* end of printheader */
void compute() {
int sum;
printheader();
} /* end of compute */
The scope of the variable sum is completely contained within the compute function. It does not extend to the body of the function printheader, although printheader executes in the midst of the execution of compute.
However, the lifetime of sum extends over the time during which printheader executes. Whatever storage location sum is bound to before the call to printheader, that binding will continue during and after the execution of printheader.

74. Referencing Environments

75. Referencing Environment
The referencing environment of a statement is the collection of all variables that are visible in the statement.

76. The Referencing Environment of a Statement in a Static-scoped Language
The referencing environment of a statement in a static-scoped language is
the variables declared in its local scope
plus
the collection of all variables of its ancestor scopes that are visible.
In such a language, the referencing environment of a statement is needed while that statement is being compiled, so code and data structures can be created to allow references to variables from other scopes during run time.

77. The Referencing Environment of a Statement in Ada
In Ada, scopes can be created by procedure definitions.
The referencing environment of a statement includes
the local variables
plus
all of the variables declared in the procedures in which the statement is nested
P.S.: excluding variables in nonlocal scopes that are hidden by declarations in nearer procedures.
Each procedure definition creates a new scope and thus a new environment.

78. The Referencing Environment of an Ada Example Program
procedure Example is
A, B : Integer;
...
procedure Sub1 is
X, Y : Integer;
begin -- of Subl
end; -- of Subl
procedure Sub2 is
X : Integer;
procedure Sub3 is
begin -- of Sub3
end; -- of Sub3
begin -- of Sub2
end; -- of Sub2
begin –- of Example
end. –- of Example
The referencing environments of the indicated program points are as follows;
Point Referencing Environment
X and Y of Sub1, A and B of
Example
X of Sub3, (X of Sub2 is hidden),
A and B of Example
X of Sub2, A and B of Example

79. Analysis of the Previous Example
Although the scope of Sub1 is at a higher level (it is less deeply nested) than Sub3, the scope of Sub1 is not a static ancestor of Sub3, so Sub3 does not have access to the variables declared in Sub1.
P.S.:
The variables declared in Sub1 are stack dynamic, so they are not bound to storage if Sub1 is not in execution.
Because Sub3 can be in execution when Sub1 is not, it cannot be allowed to access variables in Sub1, which would not necessarily be bound to storage during the execution of Sub3.

80. Active Subprograms
A subprogram is active if its execution has begun but has not yet terminated.

81. The Referencing Environment of a Statement in a Dynamically Scoped Language
The referencing environment of a statement in a dynamically scoped language is
the locally declared variables
plus
the variables of all other subprograms that are currently active.
Once again, some variables in active subprograms can be hidden from the referencing environment.
Recent subprogram activations can have declarations for variables that hide variables with the same names in previous subprogram activations.

82. Referencing Environment Examples
Consider the following example
program. Assume that the only
function calls are the following: main
calls sub2, which calls sub1.
void subl() {
int a, b;
} /* end of subl */
void sub2 {
int b, c;
subl;
} /* end of sub2 */
void main() {
int c, d;
sub2();
} /* end of main */
The referencing environments of the indicated program points are as
follows:
Point Referencing Environment
a and b of sub1, c of
sub2, d of main, , (c of
main and b of sub2 are
hidden)
b and c of sub2, d of
main, (c of main is hidden)
c and d of main

83. Named Constants
A named constant is a variable that is bound to a value only once.

84. Advantages of Named Constants
Named constants are useful as aids to readability and program reliability.
Readability can be improved.
For example, by using the name pi instead of the constant

85. Another Advantages of Named Constants
In a program that process a fixed number of data values, say 100.
Such a program usually use the constant 100 in a number of locations
for declaring array subscript ranges
for loop control limits.
When this program must be modified to deal with a different number of data values, all occurrences of 100 must be found and changed.
On a large program, this can be tedious and error-prone. An easier and more reliable method is to use a named constant.

86. Example – Named Constants Are Not Used
void example() {
int[] intList = new int[100];
String[] strList = new String[100];
...
for (index = 0; index < 100; index++) { }
average = sum / 100;

87. Example – Named Constants Are Used
void example() {
final int len = 100;
int[] intList = new int[len];
String[] strList = new String[len];
...
for (index = 0; index < len; index++) { }
average = sum / len;

88. Further Analysis of the Previous Program
Now when the length must be changed, only one line must be changed (the parameter len), regardless of the number of times it is used in the program.
This is another example of the benefits of abstraction.
The name len is an abstraction for
the number of elements in some arrays
and
the number of iterations in some loops.
This illustrates how named constants can aid modifiability.

89. Manifest Constants
Fortran 95 allows only constant expressions to be used as the values of its named constants.
These constant expressions can contain
previously declared named constants
constant values
operators
The reason for the restriction to constants and constant expressions in Fortran 95 is that it uses static binding of values to named constants.
Named constants in languages that use static binding of values are sometimes called manifest constants.

90. Dynamic Binding of Values to Named Constant
Ada and C++ allow dynamic binding of values to named constants.
This allows expressions containing variables to be assigned to constants in the declarations.
For example, the C++ statement:
const int result = 2 * width +1;
Declares result to be an integer type named constant whose value is set to the value of the expression * width +1, where the value of the variable width must be visible when result is allocated and bound to it value

91. Initialization
In many instances, it is convenient for variables to have values before the code of the program or subprogram in which they are declared begins executing.
The binding of a variable to a value at the time it is bound to storage is called initialization.

92. Initialization of Variables Statically Bound to Storage
If the variable is statically bound to storage, variable initialization occur before run time.
In these cases, the initial value must be specified as a literal or an expression whose only nonliteral operands are named constants that have already been defined.

93. Initialization of Variables Dynamically Bound to Storage
If the storage binding is dynamic, initialization is also dynamic and the initial values can be any expression.

94. Example
In most languages, initialization is specified on the declaration that creates the variable.
For example, in C++, we could have
int sum = 0;
int* ptrSum = ∑
char name[] = “George Washintton Carver”;