Programmer's ROM - The Computer Language Library

home *** CD-ROM | disk | FTP | other *** search

/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / lrm / chap08.doc < prev next >

Wrap

Text File | 1988-05-03 | 40.8 KB | 1,586 lines

The following document is a draft of the corresponding chapter of the version of the Ada Reference Manual produced in response to the Ansi Canvass. It is given a limited circulation to Ada implementers and to other groups contributing comments (according to the conventions defined in RRM.comments). This draft should not be referred to in any publication. ANSI-RM-08-v23 - Draft Chapter 8 Visibility Rules version 23 83-02-11 This version has addressed comments up to #5795 8. Visibility Rules The rules defining the scope of declarations and the rules defining which identifiers are visible at various points in the text of the program are described in this chapter. The formulation of these rules uses the notion of a declarative region. References: declaration 3.1, declarative region 8.1, identifier 2.3, scope 8.2, visibility 8.3 8.1 Declarative Region A declarative region is a portion of the program text. A single declarative region is formed by the text of each of the following: - A subprogram declaration, a package declaration, a task declaration, or a generic declaration, together with the corresponding body, if any. If the body is a body stub, the declarative region also includes the corresponding subunit. If the program unit has subunits, they are also included. - An entry declaration together with the corresponding accept statements. - A record type declaration, together with a corresponding private or incomplete type declaration if any, and together with a corresponding record representation clause if any. - A renaming declaration that includes a formal part, or a generic parameter declaration that includes either a formal part or a discriminant part. - A block statement or a loop statement. In each of the above cases, the declarative region is said to be associated with the corresponding declaration or statement. A declaration is said to occur immediately within a declarative region if this region is the innermost region that encloses the declaration, not counting the declarative region (if any) associated with the declaration itself. A declaration that occurs immediately within a declarative region is said to be local to the region. Declarations in outer (enclosing) regions are said to be global to an inner (enclosed) declarative region. A local entity is one declared by a local declaration; a global entity is one declared by a global declaration. 8 - 1 Some of the above forms of declarative region include several disjoint parts (for example, other declarative items can be between the declaration of a package and its body). Each declarative region is nevertheless considered as a (logically) continuous portion of the program text. Hence if any rule defines a portion of text as the text that extends from some specific point of a declarative region to the end of this region, then this portion is the corresponding subset of the declarative region (for example it does not include intermediate declarative items between the two parts of a package). 8 - 2 Notes: As defined in section 3.1, the term declaration includes basic declarations, implicit declarations, and those declarations that are part of basic declarations, for example, discriminant and parameter specifications. It follows from the definition of a declarative region that a discriminant specification occurs immediately within the region associated with the enclosing record type declaration. Similarly, a parameter specification occurs immediately within the region associated with the enclosing subprogram body or accept statement. The package STANDARD forms a declarative region which encloses all library units: the implicit declaration of each library unit is assumed to occur immediately within this package (see sections 8.6 and 10.1.1). Declarative regions can be nested within other declarative regions. For example, subprograms, packages, task units, generic units, and block statements can be nested within each other, and can contain record type declarations, loop statements, and accept statements. References: accept statement 9.5, basic declaration 3.1, block statement 5.6, body stub 10.2, declaration 3.1, discriminant part 3.7.1, discriminant specification 3.7.1, entry declaration 9.5, formal part 6.1, generic body 12.2, generic declaration 12.1, generic parameter declaration 12.1, implicit declaration 3.1, incomplete type declaration 3.8.1, library unit 10.1, loop statement 5.5, package 7, package body 7.1, package declaration 7.1, parameter specification 6.1, private type declaration 7.4, record representation clause 13.4, record type 3.7, renaming declaration 8.5, standard package 8.6, subprogram body 6.3, subprogram declaration 6.1, subunit 10.2, task body 9.1, task declaration 9.1, task unit 9 8.2 Scope of Declarations For each form of declaration, the language rules define a certain portion of the program text called the scope of the declaration. The scope of a declaration is also called the scope of any entity declared by the declaration. Furthermore, if the declaration associates some notation with a declared entity, this portion of the text is also called the scope of this notation (either an identifier, a character literal, an operator symbol, or the notation for a basic operation). Within the scope of an entity, and only there, there are places where it is legal to use the associated notation in order to refer to the declared entity. These places are defined by the rules of visibility and overloading. The scope of a declaration that occurs immediately within a declarative region extends from the beginning of the declaration to the end of the declarative region; this part of the scope of a declaration is called the immediate scope. Furthermore, for any of the declarations listed below, the scope of the declaration extends beyond the immediate scope: 8 - 3 (a) A declaration that occurs immediately within the visible part of a package declaration. (b) An entry declaration. (c) A component declaration. (d) A discriminant specification. (e) A parameter specification. (f) A generic parameter declaration. 8 - 4 In each of these cases, the given declaration occurs immediately within some enclosing declaration, and the scope of the given declaration extends to the end of the scope of the enclosing declaration. In the absence of a subprogram declaration, the subprogram specification given in the subprogram body or in the body stub acts as the declaration and rule (e) applies also in such a case. Note: The above scope rules apply to all forms of declaration defined by section 3.1; in particular, they apply also to implicit declarations. Rule (a) applies to a package declaration and thus not to the package specification of a generic declaration. For nested declarations, the rules (a) through (f) apply at each level. For example, if a task unit is declared in the visible part of a package, the scope of an entry of the task unit extends to the end of the scope of the task unit, that is, to the end of the scope of the enclosing package. The scope of a use clause is defined in section 8.4. References: basic operation 3.3.3, body stub 10.2, character literal 2.5, component declaration 3.7, declaration 3.1, declarative region 8.1, discriminant specification 3.7.1, entry declaration 9.5, extends 8.1, generic declaration 12.1, generic parameter declaration 12.1, identifier 2.3, implicit declaration 3.1, occur immediately within 8.1, operator symbol 6.1, overloading 6.6 8.7, package declaration 7.1, package specification 7.1, parameter specification 6.1, record type 3.7, renaming declaration 8.5, subprogram body 6.3, subprogram declaration 6.1, task declaration 9.1, task unit 9, type declaration 3.3.1, use clause 8.4, visibility 8.3, visible part 7.2 8.3 Visibility The meaning of the occurrence of an identifier at a given place in the text is defined by the visibility rules and also, in the case of overloaded declarations, by the overloading rules. The identifiers considered in this chapter include any identifier other than a reserved word, an attribute designator, a pragma identifier, the identifier of a pragma argument, or an identifier given as a pragma argument. The places considered in this chapter are those where a lexical element (such as an identifier) occurs. The overloaded declarations considered in this chapter are those for subprograms, enumeration literals, and single entries. For each identifier and at each place in the text, the visibility rules determine a set of declarations (with this identifier) that define possible meanings of an occurrence of the identifier. A declaration is said to be visible at a given place in the text when, according to the visibility rules, the declaration defines a possible meaning of this occurrence. Two cases arise. 8 - 5 - The visibility rules determine at most one possible meaning. In such a case the visibility rules are sufficient to determine the declaration defining the meaning of the occurrence of the identifier, or in the absence of such a declaration, to determine that the occurrence is not legal at the given point. - The visibility rules determine more than one possible meaning. In such a case the occurrence of the identifier is legal at this point if and only if exactly one visible declaration is acceptable for the overloading rules in the given context (see section 6.6 for the rules of overloading and section 8.7 for the context used for overload resolution). 8 - 6 A declaration is only visible within a certain part of its scope; this part starts at the end of the declaration except in a package specification, in which case it starts at the reserved word is given after the identifier of the package specification. (This rule applies, in particular, for implicit declarations.) Visibility is either by selection or direct. A declaration is visible by selection at places that are defined as follows. (a) For a declaration given in the visible part of a package declaration: at the place of the selector after the dot of an expanded name whose prefix denotes the package. (b) For an entry declaration of a given task type: at the place of the selector after the dot of a selected component whose prefix is appropriate for the task type. (c) For a component declaration of a given record type declaration: at the place of the selector after the dot of a selected component whose prefix is appropriate for the type; also at the place of a component simple name (before the compound delimiter =>) in a named component association of an aggregate of the type. (d) For a discriminant specification of a given type declaration: at the same places as for a component declaration; also at the place of a discriminant simple name (before the compound delimiter =>) in a named discriminant association of a discriminant constraint for the type. (e) For a parameter specification of a given subprogram specification or entry declaration: at the place of the formal parameter (before the compound delimiter =>) in a named parameter association of a corresponding subprogram or entry call. (f) For a generic parameter declaration of a given generic unit: at the place of the generic formal parameter (before the compound delimiter =>) in a named generic association of a corresponding generic instantiation. Finally, within the declarative region associated with a construct other than a record type declaration, any declaration that occurs immediately within the region is visible by selection at the place of the selector after the dot of an expanded name whose prefix denotes the construct. Where it is not visible by selection, a visible declaration is said to be directly visible. A declaration is directly visible within a certain part of its immediate scope; this part extends to the end of the immediate scope of the declaration, but excludes places where the declaration is hidden as explained below. In addition, a declaration occurring immediately within the visible part of a package can be made directly visible by means of a use clause according to the rules described in section 8.4. (See also section 8.6 for the visibility of library units.) A declaration is said to be hidden within (part of) an inner declarative region if the inner region contains a homograph of this declaration; the outer declaration is then hidden within the immediate scope of the inner 8 - 7 homograph. Each of two declarations is said to be a homograph of the other if both declarations have the same identifier and overloading is allowed for at most one of the two. If overloading is allowed for both declarations, then each of the two is a homograph of the other if they have the same identifier, operator symbol, or character literal, as well as the same parameter and result type profile (see 6.6). Within the specification of a subprogram, every declaration with the same designator as the subprogram is hidden; the same holds within a generic instantiation that declares a subprogram, and within an entry declaration or the formal part of an accept statement; where hidden in this manner, a declaration is visible neither by selection nor directly. 8 - 8 Two declarations that occur immediately within the same declarative region must not be homographs, unless either or both of the following requirements are met: (a) exactly one of them is the implicit declaration of a predefined operation; (b) exactly one of them is the implicit declaration of a derived subprogram. In such cases, a predefined operation is always hidden by the other homograph; a derived subprogram hides a predefined operation, but is hidden by any other homograph. Where hidden in this manner, an implicit declaration is hidden within the entire scope of the other declaration (regardless of which declaration occurs first); the implicit declaration is visible neither by selection nor directly. Whenever a declaration with a certain identifier is visible from a given point, the identifier and the declared entity (if any) are also said to be visible from that point. Direct visibility and visibility by selection are likewise defined for character literals and operator symbols. An operator is directly visible if and only if the corresponding operator declaration is directly visible. Finally, the notation associated with a basic operation is directly visible within the entire scope of this operation. Example: procedure P is A, B : BOOLEAN; procedure Q is C : BOOLEAN; B : BOOLEAN; -- an inner homograph of B begin ... B := A; -- means Q.B := P.A; C := P.B; -- means Q.C := P.B; end; begin ... A := B; -- means P.A := P.B; end; Note on the visibility of library units: The visibility of library units is determined by with clauses (see 10.1.1) and by the fact that library units are implicitly declared in the package STANDARD (see 8.6). Note on homographs: The same identifier may occur in different declarations and may thus be associated with different entities, even if the scopes of these declarations overlap. Overlap of the scopes of declarations with the same identifier can result from overloading of subprograms and of enumeration literals. Such overlaps can also occur for entities declared in package visible parts and for entries, record components, and parameters, where there is overlap of the scopes of the enclosing package declarations, task declarations, record type declarations, subprogram declarations, renaming declarations, or generic declarations. Finally overlapping scopes can result from nesting. 8 - 9 Note on immediate scope, hiding, and visibility: The rules defining immediate scope, hiding, and visibility imply that a reference to an identifier within its own declaration is illegal (except for packages and generic packages). The identifier hides outer homographs within its immediate scope, that is, from the start of the declaration; on the other hand, the identifier is visible only after the end of the declaration. For this reason, all but the last of the following declarations are illegal: 8 - 10 K : INTEGER := K * K; -- illegal T : T; -- illegal procedure P(X : P); -- illegal procedure Q(X : REAL := Q); -- illegal, even if there is a function named Q procedure R(R : REAL); -- an inner declaration is legal (although confusing) References: accept statement 9.5, aggregate 4.3, appropriate for a type 4.1, argument 2.8, basic operation 3.3.3, character literal 2.5, component association 4.3, component declaration 3.7, compound delimiter 2.2, declaration 3.1, declarative region 8.1, designate 3.8, discriminant constraint 3.7.2, discriminant specification 3.7.1, entry call 9.5, entry declaration 9.5, entry family 9.5, enumeration literal specification 3.5.1, expanded name 4.1.3, extends 8.1, formal parameter 6.1, generic association 12.3, generic formal parameter 12.1, generic instantiation 12.3, generic package 12.1, generic parameter declaration 12.1, generic unit 12, identifier 2.3, immediate scope 8.2, implicit declaration 3.1, lexical element 2.2, library unit 10.1, object 3.2, occur immediately within 8.1, operator 4.5, operator symbol 6.1, overloading 6.6 8.7, package 7, parameter 6.2, parameter association 6.4, parameter specification 6.1, pragma 2.8, program unit 6, record type 3.7, reserved word 2.9, scope 8.2, selected component 4.1.3, selector 4.1.3, simple name 4.1, subprogram 6, subprogram call 6.4, subprogram declaration 6.1, subprogram specification 6.1, task type 9.1, task unit 9, type 3.3, type declaration 3.3.1, use clause 8.4, visible part 7.2 8.4 Use Clauses A use clause achieves direct visibility of declarations that appear in the visible parts of named packages. use_clause ::= use package_name {, package_name}; For each use clause, there is a certain region of text called the scope of the use clause. This region starts immediately after the use clause. If a use clause is a declarative item of some declarative region, the scope of the clause extends to the end of the declarative region. If a use clause occurs within a context clause of a compilation unit, the scope of the use clause extends to the end of the declarative region associated with the compilation unit. In order to define which declarations are made directly visible at a given place by use clauses, consider the set of packages named by all use clauses whose scopes enclose this place, omitting from this set any packages that enclose this place. A declaration that can be made directly visible by a use clause (a potentially visible declaration) is any declaration that occurs immediately within the visible part of a package of the set. A potentially visible declaration is actually made directly visible except in the following two cases: - A potentially visible declaration is not made directly visible if the place considered is within the immediate scope of a homograph of the 8 - 11 declaration. - Potentially visible declarations that have the same identifier are not made directly visible unless each of them is either an enumeration literal specification or the declaration of a subprogram (by a subprogram declaration, a renaming declaration, a generic instantiation, or an implicit declaration). The elaboration of a use clause has no other effect. Note: The above rules guarantee that a declaration that is made directly visible by a use clause cannot hide an otherwise directly visible declaration. The above rules are formulated in terms of the set of packages named by use clauses. 8 - 12 Consequently, the following lines of text all have the same effect (assuming only one package P). use P; use P; use P, P; Example of conflicting names in two packages: procedure R is package TRAFFIC is type COLOR is (RED, AMBER, GREEN); ... end TRAFFIC; package WATER_COLORS is type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK); ... end WATER_COLORS; use TRAFFIC; -- COLOR, RED, AMBER, and GREEN are directly visible use WATER_COLORS; -- two homographs of GREEN are directly visible -- but COLOR is no longer directly visible subtype LIGHT is TRAFFIC.COLOR; -- Subtypes are used to resolve subtype SHADE is WATER_COLORS.COLOR; -- the conflicting type name COLOR SIGNAL : LIGHT; PAINT : SHADE; begin SIGNAL := GREEN; -- that of TRAFFIC PAINT := GREEN; -- that of WATER_COLORS end R; Example of name identification with a use clause: package D is T, U, V : BOOLEAN; end D; procedure P is package E is B, W, V : INTEGER; end E; procedure Q is T, X : REAL; use D, E; begin -- the name T means Q.T, not D.T -- the name U means D.U -- the name B means E.B -- the name W means E.W -- the name X means Q.X -- the name V is illegal : either D.V or E.V must be used ... 8 - 13 end Q; begin ... end P; 8 - 14 References: compilation unit 10.1, context clause 10.1, declaration 3.1, declarative item 3.9, declarative region 8.1, direct visibility 8.3, elaboration 3.1 3.9, elaboration has no other effect 3.1, enumeration literal specification 3.5.1, extends 8.1, hiding 8.3, homograph 8.3, identifier 2.3, immediate scope 8.2, name 4.1, occur immediately within 8.1, package 7, scope 8.2, subprogram declaration 6.1, visible part 7.2 8.5 Renaming Declarations A renaming declaration declares another name for an entity. renaming_declaration ::= identifier : type_mark renames object_name; | identifier : exception renames exception_name; | package identifier renames package_name; | subprogram_specification renames subprogram_or_entry_name; The elaboration of a renaming declaration evaluates the name that follows the reserved word renames and thereby determines the entity denoted by this name (the renamed entity). At any point where a renaming declaration is visible, the identifier, or operator symbol of this declaration denotes the renamed entity. The first form of renaming declaration is used for the renaming of objects. The renamed entity must be an object of the base type of the type mark. The properties of the renamed object are not affected by the renaming declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the constraints that apply to an object are not affected by renaming (any constraint implied by the type mark of the renaming declaration is ignored). The renaming declaration is legal only if exactly one object has this type and can be denoted by the object name. The following restrictions apply to the renaming of a subcomponent that depends on discriminants of a variable. The renaming is not allowed if the subtype of the variable, as defined in a corresponding object declaration, component declaration, or component subtype indication, is an unconstrained type; or if the variable is a generic formal object (of mode in out). Similarly if the variable is a formal parameter, the renaming is not allowed if the type mark given in the parameter specification denotes an unconstrained type whose discriminants have default expressions. The second form of renaming declaration is used for the renaming of exceptions; the third form, for the renaming of packages. The last form of renaming declaration is used for the renaming of subprograms and entries. The renamed subprogram or entry and the subprogram specification given in the renaming declaration must have the same parameter and result type profile (see 6.6). The renaming declaration is legal only if exactly one visible subprogram or entry satisfies the above requirements and can be denoted by the given subprogram or entry name. In addition, parameter modes must be identical for formal parameters 8 - 15 that are at the same parameter position. The subtypes of the parameters and result (if any) of a renamed subprogram or entry are not affected by renaming. These subtypes are those given in the original subprogram declaration, generic instantiation, or entry declaration (not those of the renaming declaration); even for calls that use the new name. On the other hand, a renaming declaration can introduce parameter names and default expressions that differ from those of the renamed subprogram; named associations of calls with the new subprogram name must use the new parameter name; calls with the old subprogram name must use the old parameter names. 8 - 16 A procedure can only be renamed as a procedure. Either of a function or operator can be renamed as either of a function or operator; for renaming as an operator, the subprogram specification given in the renaming declaration is subject to the rules given in section 6.7 for operator declarations. Enumeration literals can be renamed as functions; similarly, attributes defined as functions (such as SUCC and PRED) can be renamed as functions. An entry can only be renamed as a procedure; the new name is only allowed to appear in contexts that allow a procedure name. An entry of a family can be renamed, but an entry family cannot be renamed as a whole. Examples: declare L : PERSON renames LEFTMOST_PERSON; -- see 3.8.1 begin L.AGE := L.AGE + 1; end; FULL : exception renames TABLE_MANAGER.TABLE_FULL; -- see 7.5 package TM renames TABLE_MANAGER; function REAL_PLUS(LEFT, RIGHT : REAL ) return REAL renames "+"; function INT_PLUS (LEFT, RIGHT : INTEGER) return INTEGER renames "+"; function ROUGE return COLOR renames RED; -- see 3.5.1 function ROT return COLOR renames RED; function ROSSO return COLOR renames ROUGE; function NEXT(X : COLOR) return COLOR renames COLOR'SUCC; -- see 3.5.5 Example of a renaming declaration with new parameter names: function "*" (X,Y : VECTOR) return REAL renames DOT_PRODUCT; -- see 6.1 Example of a renaming declaration with a new default expression: function MINIMUM(L : LINK := HEAD) return CELL renames MIN_CELL; -- see 6.1 Notes: Renaming may be used to resolve name conflicts and to act as a shorthand. Renaming with a different identifier or operator symbol does not hide the old name; the new name and the old name need not be visible at the same points. The attributes POS and VAL cannot be renamed since the corresponding specifications cannot be written; the same holds for the predefined multiplying operators with a universal_fixed result. Calls with the new name of a renamed entry are procedure call statements and are not allowed at places where the syntax requires an entry call statement in conditional and timed entry calls; similarly, the COUNT attribute is not available for the new name. 8 - 17 A task object that is declared by an object declaration can be renamed as an object. However, a single task cannot be renamed since the corresponding task type is anonymous. For similar reasons, an object of an anonymous array type cannot be renamed. No syntactic form exists for renaming a generic unit. A subtype can be used to achieve the effect of renaming a type (including a task type) as in subtype MODE is TEXT_IO.FILE_MODE; 8 - 18 References: allow 1.6, attribute 4.1.4, base type 3.3, conditional entry call 9.7.2, constant 3.2.1, constrained subtype 3.3, constraint 3.3, declaration 3.1, default expression 6.1, depend on a discriminant 3.7.1, discriminant 3.7.1, elaboration 3.1 3.9, entry 9.5, entry call 9.5, entry call statement 9.5, entry declaration 9.5, entry family 9.5, enumeration literal 3.5.1, evaluation of a name 4.1, exception 11, formal parameter 6.1, function 6.5, identifier 2.3, legal 1.6, mode 6.1, name 4.1, object 3.2, object declaration 3.2, operator 6.7, operator declaration 6.7, operator symbol 6.1, package 7, parameter 6.2, parameter specification 6.1, procedure 6.1, procedure call statement 6.4, reserved word 2.9, subcomponent 3.3, subprogram 6, subprogram call 6.4, subprogram declaration 6.1, subprogram specification 6.1, subtype 3.3.2, task object 9.2, timed entry call 9.7.3, type 3.3, type mark 3.3.2, variable 3.2.1, visibility 8.3 8.6 The Package Standard The predefined types (for example the types BOOLEAN, CHARACTER and INTEGER) are the types that are declared in a predefined package called STANDARD; this package also includes the declarations of their predefined operations. The package STANDARD is described in Annex C. Apart from the predefined numeric types, the specification of the package STANDARD must be the same for all implementations of the language. The package STANDARD forms a declarative region which encloses every library unit and consequently the main program; the declaration of every library unit is assumed to occur immediately within this package. The implicit declarations of library units are assumed to be ordered in such a way that the scope of a given library unit includes any compilation unit that mentions the given library unit in a with clause. However, the only library units that are visible within a given compilation unit are as follows: they include the library units named by all with clauses that apply to the given unit, and moreover, if the given unit is a secondary unit of some library unit, they include this library unit. Notes: If all block statements of a program are named, then the name of each program unit can always be written as an expanded name starting with STANDARD (unless this package is itself hidden). If a type is declared in the visible part of a library package, then it is a consequence of the visibility rules that a basic operation (such as assignment) for this type is directly visible at places where the type itself is not visible (whether by selection or directly). However this operation can only be applied to operands that are visible and the declaration of these operands requires the visibility of either the type or one of its subtypes. References: applicable with clause 10.1.1, block name 5.6, block statement 5.6, declaration 3.1, declarative region 8.1, expanded name 4.1.3, hiding 8 - 19 8.3, identifier 2.3, implicit declaration 3.1, library unit 10.1, loop statement 5.5, main program 10.1, must 1.6, name 4.1, occur immediately within 8.1, operator 6.7, package 7, program unit 6, secondary unit 10.1, subtype 3.3, type 3.3, visibility 8.3, with clause 10.1.1 8.7 The Context of Overload Resolution Overloading is defined for subprograms, enumeration literals, operators, and single entries, and also for the operations that are inherent in several basic operations such as assignment, membership tests, allocators, the literal null, aggregates, and string literals. 8 - 20 For overloaded entities, overload resolution determines the actual meaning that an occurrence of an identifier has, whenever the visibility rules have determined that more than one meaning is acceptable at the place of this occurrence; overload resolution likewise determines the actual meaning of an occurrence of an operator or some basic operation. At such a place all visible declarations are considered. The occurrence is only legal if there is exactly one interpretation of each constituent of the innermost complete context; a complete context is one of the following: - A declaration. - A statement. - A representation clause. When considering possible interpretations of a complete context, the only rules considered are the syntax rules, the scope and visibility rules, and the rules of the form described below. (a) Any rule that requires a name or expression to have a certain type, or to have the same type as another name or expression. (b) Any rule that requires the type of a name or expression to be a type of a certain class; similarly, any rule that requires a certain type to be a discrete, integer, real, universal, character, boolean, or nonlimited type. (c) Any rule that requires a prefix to be appropriate for a certain type. (d) Any rule that specifies a certain type as the result type of a basic operation, and any rule that specifies that this type is of a certain class. (e) The rules that require the type of an aggregate or string literal to be determinable solely from the enclosing complete context (see 4.3 and 4.2). Similarly, the rules that require the type of the prefix of an attribute, the type of the expression of a case statement, or the type of the operand of a type conversion, to be determinable independently of the context (see 4.1.4, 5.4, 4.6, and 6.4.1). (f) The rules given in section 6.6, for the resolution of overloaded subprogram calls; in section 4.6, for the implicit conversions of universal expressions; in section 3.6.1, for the interpretation of discrete ranges with bounds having a universal type; and in section 4.1.3, for the interpretation of an expanded name whose prefix denotes a subprogram or an accept statement. Subprogram names used as pragma arguments follow a different rule: the pragma can apply to several overloaded subprograms, as explained in section 6.3.2 for the pragma INLINE, in section 11.7 for the pragma SUPPRESS, and in section 13.9 for the pragma INTERFACE. 8 - 21 Similarly, the simple names given in context clauses (see 10.1.1) and in address clauses (see 13.5) follow different rules. 8 - 22 Notes: If there is only one possible interpretation, the identifier denotes the corresponding entity. However, this does not mean that the occurrence is necessarily legal since other requirements exist which are not considered for overload resolution; for example, the fact that an expression is static, the parameter modes, whether an object is constant, conformance rules, forcing occurrences for a representation clause, order of elaboration, and so on. Similarly, subtypes are not considered for overload resolution (the violation of a constraint does not make a program illegal but raises an exception during program execution). Rules that require certain constructs to have the same parameter and result type profile fall under the category (a); the same holds for rules that require conformance of two constructs since conformance requires that corresponding names be given the same meaning by the visibility and overloading rules. A loop parameter specification is a declaration, and hence a complete context. References: aggregate 4.3, allocator 4.8, assignment 5.2, basic operation 3.3.3, case statement 5.4, class of type 3.3, declaration 3.1, entry 9.5, enumeration literal 3.5.1, exception 11, expression 4.4, formal part 6.1, identifier 2.3, legal 1.6, literal 4.2, loop parameter specification 5.5, membership test 4.5.2, name 4.1, null literal 3.8, operation 3.3.3, operator 4.5, overloading 6.6, pragma 2.8, representation clause 13.1, statement 5, static expression 4.9, static subtype 4.9, subprogram 6, subtype 3.3, type conversion 4.6, visibility 8.3 Rules of the form (a): address clause 13.5, assignment 5.2, choice 3.7.3 4.3.2 5.4, component association 4.3.1 4.3.2, conformance rules 9.5, default expression 3.7 3.7.1 6.1 12.1.1, delay statement 9.6, discrete range 3.6.1 5.5 9.5, discriminant constraint 3.7.2, enumeration representation clause 13.3, generic parameter association 12.3.1, index constraint 3.6.1, index expression 4.1.1 4.1.2 9.5, initial value 3.2.1, membership test 4.5.2, parameter association 6.4.1, parameter and result type profile 8.5 12.3.6, qualified expression 4.7, range constraint 3.5, renaming of an object 8.5, result expression 5.8 Rules of the form (b): abort statement 9.10, assignment 5.2, case expression 5.4, condition 5.3 5.5 5.7 9.7.1, discrete range 3.6.1 5.5 9.5, fixed point type declaration 3.5.9, floating point type declaration 3.5.7, integer type declaration 3.5.4, length clause 13.2, membership test 4.4, number declaration 3.2.2, record representation clause 13.4, selected component 4.1.3, short-circuit control form 4.4, val attribute 3.5.5 Rules of the form (c): indexed component 4.1.1, selected component 4.1.3, slice 4.1.2 Rules of the form (d): aggregate 4.3, allocator 4.8, membership test 4.4, null literal 4.2, numeric literal 2.4, short-circuit control form 4.4, string literal 4.2 8 - 23