@Part(03, Root="ada.mss") @Comment{$Date: 2007/07/10 05:00:45 $} @LabeledSection{Declarations and Types} @Comment{$Source: e:\\cvsroot/ARM/Source/03a.mss,v $} @Comment{$Revision: 1.86 $} @begin{Intro} This section describes the types in the language and the rules for declaring constants, variables, and named numbers. @end{Intro} @LabeledClause{Declarations} @begin{Intro} @PDefn{entity} The language defines several kinds of named @i(entities) that are declared by declarations. @PDefn{name} The entity's @i(name) is defined by the declaration, usually by a @nt, but sometimes by a @nt{defining_@!character_@!literal} or @nt{defining_@!operator_@!symbol}. There are several forms of declaration. A @nt is a form of declaration defined as follows. @end{Intro} @begin{Syntax} @ChgRef{Version=[2],Kind=[Revised],ARef=[AI95-00348-01]} @Syn{tabs=[P27], lhs=,rhs=" @Syn2{type_declaration}@\| @Syn2{subtype_declaration} | @Syn2{object_declaration}@\| @Syn2{number_declaration} | @Syn2{subprogram_declaration}@\| @Syn2{abstract_subprogram_declaration} | @Chg{Version=[2],New=[@Syn2{null_procedure_declaration}@\| ],Old=[]}@Syn2{package_declaration}@Chg{Version=[2],New=[ |],Old=[@\|]} @Syn2{renaming_declaration}@Chg{Version=[2],New=[@\|],Old=[ |]} @Syn2{exception_declaration}@Chg{Version=[2],New=[ |],Old=[@\|]} @Syn2{generic_declaration}@Chg{Version=[2],New=[@\|],Old=[ |]} @Syn2{generic_instantiation}"} @Syn{lhs=,rhs="@Syn2{identifier}"} @end{Syntax} @begin{StaticSem} @ToGlossaryAlso{Term=, Text=} @begin{Discussion} An implicit declaration generally declares a predefined or inherited operation associated with the definition of a type. This term is used primarily when allowing explicit declarations to override implicit declarations, as part of a type declaration. @end{Discussion} @ChgRef{Version=[2],Kind=[Revised],ARef=[AI95-00318-02]} @Defn{declaration} Each of the following is defined to be a declaration: any @nt{basic_@!declaration}; an @nt{enumeration_@!literal_@!specification}; a @nt{discriminant_@!specification}; a @nt{component_@!declaration}; a @nt{loop_@!parameter_@!specification}; a @nt{parameter_@!specification}; a @nt{subprogram_@!body}; an @nt{entry_@!declaration}; an @nt{entry_@!index_@!specification}; a @nt{choice_@!parameter_@!specification}; a @nt{generic_@!formal_@!parameter_@!declaration}.@Chg{Version=[2],New=[ In addition, an @nt{extended_return_statement} is a declaration of its @nt{defining_identifier}.],Old=[]} @begin(Discussion) This list (when @nt is expanded out) contains all syntactic categories that end in "_declaration" or "_specification", except for program unit _specifications. Moreover, it contains @nt{subprogram_body}. A @nt{subprogram_body} is a declaration, whether or not it completes a previous declaration. This is a bit strange, @nt{subprogram_body} is not part of the syntax of @nt{basic_declaration} or @nt{library_unit_declaration}. A renaming-as-body is considered a declaration. An @nt{accept_statement} is not considered a declaration. Completions are sometimes declarations, and sometimes not. @end(Discussion) @Defn(view)@Defn(definition) All declarations contain a @i(definition) for a @i(view) of an entity. A view consists of an identification of the entity (the entity @i(of) the view), plus view-specific characteristics that affect the use of the entity through that view (such as mode of access to an object, formal parameter names and defaults for a subprogram, or visibility to components of a type). In most cases, a declaration also contains the definition for the entity itself (a @nt(renaming_declaration) is an example of a declaration that does not define a new entity, but instead defines a view of an existing entity (see @RefSecNum(Renaming Declarations))). @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=<@Chg{Version=[2],New=[A view of an entity reveals some or all of the properties of the entity. A single entity may have multiple views.], Old=[(See @b[Definition].)]}>} @begin{Discussion} Most declarations define a view (of some entity) whose view-specific characteristics are unchanging for the life of the view. However, subtypes are somewhat unusual in that they inherit characteristics from whatever view of their type is currently visible. Hence, a subtype is not a @i(view) of a type; it is more of an indirect reference. By contrast, a private type provides a single, unchanging (partial) view of its full type. @end{Discussion} @ChgToGlossary{Version=[2],Kind=[Deleted],Term=, Text=<@ChgDeleted{Version=[2],Text=[@Defn(view) All declarations contain a @i(definition) for a @i(view) of an entity. A view consists of an identification of the entity (the entity @i(of) the view), plus view-specific characteristics that affect the use of the entity through that view (such as mode of access to an object, formal parameter names and defaults for a subprogram, or visibility to components of a type). In most cases, a declaration also contains the definition for the entity itself (a @nt(renaming_declaration) is an example of a declaration that does not define a new entity, but instead defines a view of an existing entity (see @RefSecNum(Renaming Declarations))).]}>} @PDefn2{Term=[scope], Sec=(informal definition)} For each declaration, the language rules define a certain region of text called the @i(scope) of the declaration (see @RefSecNum(Scope of Declarations)). Most declarations associate an @nt with a declared entity. Within its scope, and only there, there are places where it is possible to use the @nt to refer to the declaration, the view it defines, and the associated entity; these places are defined by the visibility rules (see @RefSecNum(Visibility)). @Defn2{Term=[name], Sec={of (a view of) an entity}} At such places the @nt is said to be a @i(name) of the entity (the @nt or @nt); @PDefn2{Term=[denote], Sec={informal definition}} the name is said to @i(denote) the declaration, the view, and the associated entity (see @RefSecNum{The Context of Overload Resolution}). @Defn{declare} The declaration is said to @i(declare) the name, the view, and in most cases, the entity itself. As an alternative to an @nt, an enumeration literal can be declared with a @nt as its name (see @RefSecNum(Enumeration Types)), and a function can be declared with an @nt as its name (see @RefSecNum(Subprogram Declarations)). @Defn{defining name} The syntax rules use the terms @nt, @nt, and @nt for the defining occurrence of a name; these are collectively called @i(defining names). @Defn{usage name} The terms @nt and @nt are used for usage occurrences of @nts, @nts, and @nts. These are collectively called @i(usage names). @begin(Honest) The terms @nt, @nt, and @nt are used directly in contexts where the normal visibility rules do not apply (such as the @nt that appears after the @key(end) of a @nt). Analogous conventions apply to the use of @nt, which is the collective term for @nt and @nt. @end(Honest) @end{StaticSem} @begin{RunTime} @RootDefn{execution} The process by which a construct achieves its run-time effect is called @i(execution). @RootDefn{elaboration} @RootDefn{evaluation} This process is also called @i(elaboration) for declarations and @i(evaluation) for expressions. One of the terms execution, elaboration, or evaluation is defined by this International Standard for each construct that has a run-time effect. @ToGlossary{Term=, Text=} @begin{Honest} The term elaboration is also used for the execution of certain constructs that are not declarations, and the term evaluation is used for the execution of certain constructs that are not expressions. For example, @nt{subtype_indication}s are elaborated, and @nt{range}s are evaluated. For bodies, execution and elaboration are both explicitly defined. When we refer specifically to the execution of a body, we mean the explicit definition of execution for that kind of body, not its elaboration. @end{Honest} @begin(Discussion) Technically, "the execution of a declaration" and "the elaboration of a declaration" are synonymous. We use the term "elaboration" of a construct when we know the construct is elaborable. When we are talking about more arbitrary constructs, we use the term "execution". For example, we use the term "erroneous execution", to refer to any erroneous execution, including erroneous elaboration or evaluation. When we explicitly define evaluation or elaboration for a construct, we are implicitly defining execution of that construct. We also use the term "execution" for things like @nt{statement}s, which are executable, but neither elaborable nor evaluable. We considered using the term "execution" only for non-elaborable, non-evaluable constructs, and defining the term "action" to mean what we have defined "execution" to mean. We rejected this idea because we thought three terms that mean the same thing was enough @em four would be overkill. Thus, the term "action" is used only informally in the standard (except where it is defined as part of a larger term, such as "protected action"). @end(Discussion) @ChgToGlossary{Version=[2],Kind=[Added],Term=, Text=<@ChgAdded{Version=[2],Text=[The process by which a declaration achieves its run-time effect is called elaboration. Elaboration is one of the forms of execution.]}>} @ChgToGlossary{Version=[2],Kind=[Added],Term=, Text=<@ChgAdded{Version=[2],Text=[The process by which an expression achieves its run-time effect is called evaluation. Evaluation is one of the forms of execution.]}>} @begin{Honest} @Defn{elaborable} A construct is @i(elaborable) if elaboration is defined for it. @Defn{evaluable} A construct is @i(evaluable) if evaluation is defined for it. @Defn{executable} A construct is @i(executable) if execution is defined for it. @end{Honest} @begin(Discussion) Don't confuse @lquotes@;elaborable@rquotes@; with @lquotes@;preelaborable@rquotes@; (defined in @RefSecNum(Elaboration Control)). @ChgRef{Version=[2],Kind=[Revised],ARef=[AI95-00114-01]} Evaluation of an evaluable construct produces a result that is either a value, a denotation, or a range. The following are evaluable: expression; @nt{name} @nt{prefix}; @nt{range}; @Chg{Version=[2],New=[@nt{entry_index_specification}],Old=[@ntf{entry_list_iterator}]}; and possibly @nt{discrete_range}. The last one is curious @em RM83 uses the term @lquotes@;evaluation of a @nt{discrete_range},@rquotes@; but never defines it. One might presume that the evaluation of a @nt{discrete_range} consists of the evaluation of the @nt{range} or the @nt{subtype_indication}, depending on what it is. But @nt{subtype_indication}s are not evaluated; they are elaborated. Intuitively, an @i(executable) construct is one that has a defined run-time effect (which may be null). Since execution includes elaboration and evaluation as special cases, all elaborable and all evaluable constructs are also executable. Hence, most constructs in Ada are executable. An important exception is that the constructs inside a generic unit are not executable directly, but rather are used as a template for (generally) executable constructs in instances of the generic. @end(Discussion) @end{RunTime} @begin{Notes} @Defn{declare} At compile time, the declaration of an entity @i(declares) the entity. @Defn{create} At run time, the elaboration of the declaration @i(creates) the entity. @begin{Ramification} Syntactic categories for declarations are named either @i(entity_)@ntf (if they include a trailing semicolon) or @i(entity_)@ntf (if not). @Defn{entity} The various kinds of named entities that can be declared are as follows: an object (including components and parameters), a named number, a type (the name always refers to its first subtype), a subtype, a subprogram (including enumeration literals and operators), a single entry, an entry family, a package, a protected or task unit (which corresponds to either a type or a single object), an exception, a generic unit, a label, and the name of a statement. Identifiers are also associated with names of pragmas, arguments to pragmas, and with attributes, but these are not user-definable. @end{Ramification} @end{Notes} @begin{DiffWord83} The syntax rule for @nt{defining_identifier} is new. It is used for the defining occurrence of an @nt{identifier}. Usage occurrences use the @nt{direct_name} or @nt{selector_name} syntactic categories. @Leading@;Each occurrence of an @nt{identifier} (or @ntf{simple_name}), @nt{character_literal}, or @nt{operator_symbol} in the Ada 83 syntax rules is handled as follows in Ada 95: @begin{itemize} It becomes a @nt{defining_identifier}, @nt{defining_character_literal}, or @nt{defining_operator_symbol} (or some syntactic category composed of these), to indicate a defining occurrence; It becomes a @nt{direct_name}, in usage occurrences where the usage is required (in Section 8) to be directly visible; It becomes a @nt{selector_name}, in usage occurrences where the usage is required (in Section 8) to be visible but not necessarily directly visible; It remains an @nt{identifier}, @nt{character_literal}, or @nt{operator_symbol}, in cases where the visibility rules do not apply (such as the @nt{designator} that appears after the @key{end} of a @nt{subprogram_body}). @end{itemize} For declarations that come in @lquotes@;two parts@rquotes@; (program unit declaration plus body, private or incomplete type plus full type, deferred constant plus full constant), we consider both to be defining occurrences. Thus, for example, the syntax for @nt{package_body} uses @nt{defining_identifier} after the reserved word @key{body}, as opposed to @nt{direct_name}. The defining occurrence of a statement name is in its implicit declaration, not where it appears in the program text. Considering the statement name itself to be the defining occurrence would complicate the visibility rules. The phrase @lquotes@;visible by selection@rquotes@; is not used in Ada 95. It is subsumed by simply @lquotes@;visible@rquotes@; and the Name Resolution Rules for @nts. (Note that in Ada 95, a declaration is visible at all places where one could have used a @nt{selector_name}, not just at places where a @nt{selector_name} was actually used. Thus, the places where a declaration is directly visible are a subset of the places where it is visible. See Section 8 for details.) We use the term @lquotes@;declaration@rquotes@; to cover @ntf<_specification>s that declare (views of) objects, such as @nts. In Ada 83, these are referred to as a @lquotes@;form of declaration,@rquotes@; but it is not entirely clear that they are considered simply @lquotes@;declarations.@rquotes@; RM83 contains an incomplete definition of "elaborated" in this clause: it defines "elaborated" for declarations, @nt{declarative_part}s, @nt{declarative_item}s and @nt{compilation_unit}s, but "elaboration" is defined elsewhere for various other constructs. To make matters worse, Ada 95 has a different set of elaborable constructs. Instead of correcting the list, it is more maintainable to refer to the term "elaborable," which is defined in a distributed manner. RM83 uses the term @lquotes@;has no other effect@rquotes@; to describe an elaboration that doesn't do anything except change the state from not-yet-elaborated to elaborated. This was a confusing wording, because the answer to @lquotes@;other than what?@rquotes@; was to be found many pages away. In Ada 95, we change this wording to @lquotes@;has no effect@rquotes@; (for things that truly do nothing at run time), and @lquotes@;has no effect other than to establish that so-and-so can happen without failing the Elaboration_Check@rquotes@; (for things where it matters). We make it clearer that the term "execution" covers elaboration and evaluation as special cases. This was implied in RM83. For example, "erroneous execution" can include any execution, and RM83-9.4(3) has, "The task designated by any other task object depends on the master whose execution creates the task object;" the elaboration of the master's @nt{declarative_part} is doing the task creation. @end{DiffWord83} @begin{DiffWord95} @ChgRef{Version=[2],Kind=[AddedNormal],ARef=[AI95-00318-02]} @ChgAdded{Version=[2],Text=[Added @nt{extended_return_statement} to the list of declarations.]} @ChgRef{Version=[2],Kind=[AddedNormal],ARef=[AI95-00348-01]} @ChgAdded{Version=[2],Text=[Added null procedures (see @RefSecNum{Null Procedures}) to the syntax.]} @end{DiffWord95} @LabeledClause{Types and Subtypes} @begin{StaticSem} @Defn{type} @PDefn{primitive operation} A @i(type) is characterized by a set of values, and a set of @i(primitive operations) which implement the fundamental aspects of its semantics. @PDefn{object} An @i(object) of a given type is a run-time entity that contains (has) a value of the type. @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text= of types],Old=[The types of a given class share a set of primitive operations. @Defn(closed under derivation) Classes are closed under derivation; that is, if a type is in a class, then all of its derivatives are in that class]}.>} @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=} @ChgRef{Version=[2],Kind=[Revised],ARef=[AI95-00442-01]} @Chg{Version=[2],New=[@Defn2{Term=[category], Sec=(of types)}], Old=[]}@Defn2{Term=[class], Sec=(of types)} Types are grouped into @Chg{Version=[2],New=[@i(categories)], Old=[@i(classes)]} of types@Chg{Version=[2],New=[],Old=[, reflecting the similarity of their values and primitive operations]}. @Defn2{Term=[language-defined class], Sec=(of types)} There exist several @i(language-defined @Chg{Version=[2],New=[categories], Old=[classes]}) of types (see NOTES below)@Chg{Version=[2],New=[, reflecting the similarity of their values and primitive operations],Old=[]}.@Chg{Version=[2], New=[@Defn2{Term=[language-defined category], Sec=(of types)} @Redundant[Most categories of types form @i(classes) of types.]],Old=[]} @Defn{elementary type} @i(Elementary) types are those whose values are logically indivisible; @Defn{composite type} @Defn{component} @i(composite) types are those whose values are composed of @i(component) values. @IndexSeeAlso{Term={aggregate},See=(composite type)} @begin{TheProof} @ChgRef{Version=[2],Kind=[Revised],ARef=[AI95-00442-01]} @ChgAdded{Version=[2],Text=[The formal definition of @i and @i is found in @RefSecNum{Derived Types and Classes}.]} @end{TheProof} @ChgNote @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=<@Defn(closed under derivation) A class is a set of types that is closed under derivation, which means that if a given type is in the class, then all types derived from that type are also in the class. The set of types of a class share common properties, such as their primitive operations.>} @ChgToGlossary{Version=[2],Kind=[Added],Term=, Text=<@ChgAdded{Version=[2],Text=[A category of types is a set of types with one or more common properties, such as primitive operations. A category of types that is closed under derivation is also known as a @i.]}>} @ToGlossary{Term=, Text=} @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ToGlossary{Term=, Text=} @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=} @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=} @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=}@ChgNote{This was changed to parallel "incomplete type"} @ChgToGlossary{Version=[2],Kind=[Revised],Term=, Text=