;;;-*- Fonts: cthl12, cthl12b, cthl12b, cptfontb, hl10, ct18b, cthl12i, cthl12b, cthl12b, brchars -*-
      document lrm

      chapter lrm-chapter-1



                                                  11. Introduction

0     Ada is a programming language designed in accordance with requirements defined by the United States
     Department of Defense:  the so-called Steelman requirements.  Overall, these requirements call for a
     language with considerable expressive power covering a wide application domain.  As a result, the
     language includes facilities offered by classical languages such as Pascal as well as facilities often
     found only in specialized languages.  Thus the language is a modern algorithmic language with the usual
     control structures, and with the ability to define types and subprograms.  It also serves the need for
     modularity, whereby data, types, and subprograms can be packaged.  It treats modularity in the physical
     sense as well, with a facility to support separate compilation.

     In addition to these aspects, the language covers real-time programming, with facilities to model
     parallel tasks and to handle exceptions.  It also covers systems programming; this requires precise
     control over the representation of data and access to system-dependent properties.  Finally, both
     application-level and machine-level input-output are defined.

      section lrm-section1-1

     21.1. Scope of the Standard

0     This standard specifies the form and meaning of program units written in Ada.  Its purpose is to promote
     the portability of Ada programs to a variety of data processing systems.

      subsection lrm-section1-1-1



     71.1.1. Extent of the Standard

0     This standard specifies:

       (a) The form of a program unit written in Ada.

       (b) The effect of translating and executing such a program unit.

       (c) The manner in which program units may be combined to form Ada programs.

       (d) The predefined program units that a conforming implementation must supply.

       (e) The permissible variations within the standard, and the manner in which they must be
           specified.

       (f) Those violations of the standard that a conforming implementation is required to detect, and
           the effect of attempting to translate or execute a program unit containing such violations.

       (g) Those violations of the standard that a conforming implementation is not required to detect.

     This standard does not specify:

       (h) The means whereby a program unit written in Ada is transformed into object code executable by
           a processor.

       (i) The means whereby translation or execution of program units is invoked and the executing units
           are controlled.

       (j) The size or speed of the object code, or the relative execution speed of different language
           constructs.

       (k) The form or contents of any listings produced by implementations; in particular, the form or
           contents of error or warning messages.

       (l) The effect of executing a program unit that contains any violation that a conforming
           implementation is not required to detect.

       (m) The size of a program or program unit that will exceed the capacity of a particular conforming
           implementation.

     Where this standard specifies that a program unit written in Ada has an exact effect, this effect is the
     operational meaning of the program unit and must be produced by all conforming implementations.  Where
     this standard specifies permissible variations in the effects of constituents of a program unit written
     in Ada, the operational meaning of the program unit as a whole is understood to be the range of possible
     effects that result from all these variations, and a conforming implementation is allowed to produce any
     of these possible effects.  Examples of permissible variations are:

        - The represented values of fixed or floating numeric quantities, and the results of operations
          upon them.

        - The order of execution of statements in different parallel tasks, in the absence of explicit
          synchronization.

      subsection lrm-section1-1-2



     71.1.2. Conformity of an Implementation With the Standard

0     A conforming implementation is one that:

       (a) Correctly translates and executes legal program units written in Ada, provided that they are
           not so large as to exceed the capacity of the implementation.

       (b) Rejects all program units that are so large as to exceed the capacity of the implementation.

       (c) Rejects all program units that contain errors whose detection is required by the standard.

       (d) Supplies all predefined program units required by the standard.

       (e) Contains no variations except where the standard permits.

       (f) Specifies all such permitted variations in the manner prescribed by the standard.

      section lrm-section1-2

     21.2. Structure of the Standard

0     This reference manual contains fourteen chapters, three annexes, three appendices, and an index.

     Each chapter is divided into sections that have a common structure.  Each section introduces its subject,
     gives any necessary syntax rules, and describes the semantics of the corresponding language constructs.
     Examples and notes, and then references, may appear at the end of a section.

     Examples are meant to illustrate the possible forms of the constructs described.  Notes are meant to
     emphasize consequences of the rules described in the section or elsewhere.  References are meant to
     attract the attention of readers to a term or phrase having a technical meaning defined in another
     section.

     The standard definition of the Ada programming language consists of the fourteen chapters and the three
     annexes, subject to the following restriction:  the material in each of the items listed below is
     informative, and not part of the standard definition of the Ada programming language:

        - Section 1.3 Design goals and sources

        - Section 1.4 Language summary

        - The examples, notes, and references given at the end of each section

        - Each section whose title starts with the word "Example" or "Examples"

      section lrm-section1-3

     21.3. Design Goals and Sources

0     Ada was designed with three overriding concerns:  program reliability and maintenance, programming as a
     human activity, and efficiency.

     The need for languages that promote reliability and simplify maintenance is well established.  Hence
     emphasis was placed on program readability over ease of writing.  For example, the rules of the language
     require that program variables be explicitly declared and that their type be specified.  Since the type
     of a variable is invariant, compilers can ensure that operations on variables are compatible with the
     properties intended for objects of the type.  Furthermore, error-prone notations have been avoided, and
     the syntax of the language avoids the use of encoded forms in favor of more English-like constructs.
     Finally, the language offers support for separate compilation of program units in a way that facilitates
     program development and maintenance, and which provides the same degree of checking between units as
     within a unit.

     Concern for the human programmer was also stressed during the design.  Above all, an attempt was made to
     keep the language as small as possible, given the ambitious nature of the application domain.  We have
     attempted to cover this domain with a small number of underlying concepts integrated in a consistent and
     systematic way.  Nevertheless we have tried to avoid the pitfalls of excessive involution, and in the
     constant search for simpler designs we have tried to provide language constructs that correspond
     intuitively to what the users will normally expect.

     Like many other human activities, the development of programs is becoming ever more decentralized and
     distributed.  Consequently, the ability to assemble a program from independently produced software
     components has been a central idea in this design.  The concepts of packages, of private types, and of
     generic units are directly related to this idea, which has ramifications in many other aspects of the
     language.

     No language can avoid the problem of efficiency.  Languages that require over-elaborate compilers, or
     that lead to the inefficient use of storage or execution time, force these inefficiencies on all machines
     and on all programs.  Every construct of the language was examined in the light of present implementation
     techniques.  Any proposed construct whose implementation was unclear or that required excessive machine
     resources was rejected.

     None of the above design goals was considered as achievable after the fact.  The design goals drove the
     entire design process from the beginning.

     A perpetual difficulty in language design is that one must both identify the capabilities required by the
     application domain and design language features that provide these capabilities.  The difficulty existed
     in this design, although to a lesser degree than usual because of the Steelman requirements.  These
     requirements often simplified the design process by allowing it to concentrate on the design of a given
     system providing a well defined set of capabilities, rather than on the definition of the capabilities
     themselves.

     Another significant simplification of the design work resulted from earlier experience acquired by
     several successful Pascal derivatives developed with similar goals.  These are the languages Euclid, Lis,
     Mesa, Modula, and Sue.  Many of the key ideas and syntactic forms developed in these languages have
     counterparts in Ada.  Several existing languages such as Algol 68 and Simula, and also recent research
     languages such as Alphard and Clu, influenced this language in several respects, although to a lesser
     degree than did the Pascal family.

     Finally, the evaluation reports received on an earlier formulation (the Green language), and on
     alternative proposals (the Red, Blue, and Yellow languages), the language reviews that took place at
     different stages of this project, and the thousands of comments received from fifteen different countries
     during the preliminary stages of the Ada design and during the ANSI canvass, all had a significant impact
     on the standard definition of the language.

      section lrm-section1-4

     21.4. Language Summary

0     An Ada program is composed of one or more program units.  These program units can be compiled separately.
     Program units may be subprograms (which define executable algorithms), package units (which define
     collections of entities), task units (which define parallel computations), or generic units (which define
     parameterized forms of packages and subprograms).  Each unit normally consists of two parts:  a
     specification, containing the information that must be visible to other units, and a body, containing the
     implementation details, which need not be visible to other units.

     This distinction of the specification and body, and the ability to compile units separately, allows a
     program to be designed, written, and tested as a set of largely independent software components.

     An Ada program will normally make use of a library of program units of general utility.  The language
     provides means whereby individual organizations can construct their own libraries.  The text of a
     separately compiled program unit must name the library units it requires.

     6Program0 6Units

0     A subprogram is the basic unit for expressing an algorithm.  There are two kinds of subprograms:
     procedures and functions.  A procedure is the means of invoking a series of actions.  For example, it may
     read data, update variables, or produce some output.  It may have parameters, to provide a controlled
     means of passing information between the procedure and the point of call.

     A function is the means of invoking the computation of a value.  It is similar to a procedure, but in
     addition will return a result.

     A package is the basic unit for defining a collection of logically related entities.  For example, a
     package can be used to define a common pool of data and types, a collection of related subprograms, or a
     set of type declarations and associated operations.  Portions of a package can be hidden from the user,
     thus allowing access only to the logical properties expressed by the package specification.

     A task unit is the basic unit for defining a task whose sequence of actions may be executed in parallel
     with those of other tasks.  Such tasks may be implemented on multicomputers, multiprocessors, or with
     interleaved execution on a single processor.  A task unit may define either a single executing task or a
     task type permitting the creation of any number of similar tasks.

     6Declarations0 6and0 6Statements

0     The body of a program unit generally contains two parts:  a declarative part, which defines the logical
     entities to be used in the program unit, and a sequence of statements, which defines the execution of the
     program unit.

     The declarative part associates names with declared entities.  For example, a name may denote a type, a
     constant, a variable, or an exception.  A declarative part also introduces the names and parameters of
     other nested subprograms, packages, task units, and generic units to be used in the program unit.

     The sequence of statements describes a sequence of actions that are to be performed.  The statements are
     executed in succession (unless an exit, return, or goto statement, or the raising of an exception, causes
     execution to continue from another place).

     An assignment statement changes the value of a variable.  A procedure call invokes execution of a
     procedure after associating any actual parameters provided at the call with the corresponding formal
     parameters.

     Case statements and if statements allow the selection of an enclosed sequence of statements based on the
     value of an expression or on the value of a condition.

     The loop statement provides the basic iterative mechanism in the language.  A loop statement specifies
     that a sequence of statements is to be executed repeatedly as directed by an iteration scheme, or until
     an exit statement is encountered.

     A block statement comprises a sequence of statements preceded by the declaration of local entities used
     by the statements.

     Certain statements are only applicable to tasks.  A delay statement delays the execution of a task for a
     specified duration.  An entry call statement is written as a procedure call statement; it specifies that
     the task issuing the call is ready for a rendezvous with another task that has this entry.  The called
     task is ready to accept the entry call when its execution reaches a corresponding accept statement, which
     specifies the actions then to be performed.  After completion of the rendezvous, both the calling task
     and the task having the entry may continue their execution in parallel.  One form of the select statement
     allows a selective wait for one of several alternative rendezvous.  Other forms of the select statement
     allow conditional or timed entry calls.

     Execution of a program unit may encounter error situations in which normal program execution cannot
     continue.  For example, an arithmetic computation may exceed the maximum allowed value of a number, or an
     attempt may be made to access an array component by using an incorrect index value.  To deal with such
     error situations, the statements of a program unit can be textually followed by exception handlers that
     specify the actions to be taken when the error situation arises.  Exceptions can be raised explicitly by
     a raise statement.

     6Data0 6Types

0     Every object in the language has a type, which characterizes a set of values and a set of applicable
     operations.  The main classes of types are scalar types (comprising enumeration and numeric types),
     composite types, access types, and private types.

     An enumeration type defines an ordered set of distinct enumeration literals, for example a list of states
     or an alphabet of characters.  The enumeration types BOOLEAN and CHARACTER are predefined.

     Numeric types provide a means of performing exact or approximate numerical computations.  Exact
     computations use integer types, which denote sets of consecutive integers.  Approximate computations use
     either fixed point types, with absolute bounds on the error, or floating point types, with relative
     bounds on the error.  The numeric types INTEGER, FLOAT, and DURATION are predefined.

     Composite types allow definitions of structured objects with related components.  The composite types in
     the language provide for arrays and records.  An array is an object with indexed components of the same
     type.  A record is an object with named components of possibly different types.  The array type STRING is
     predefined.

     A record may have special components called discriminants.  Alternative record structures that depend on
     the values of discriminants can be defined within a record type.

     Access types allow the construction of linked data structures created by the evaluation of allocators.
     They allow several variables of an access type to designate the same object, and components of one object
     to designate the same or other objects.  Both the elements in such a linked data structure and their
     relation to other elements can be altered during program execution.

     Private types can be defined in a package that conceals structural details that are externally
     irrelevant.  Only the logically necessary properties (including any discriminants) are made visible to
     the users of such types.

     The concept of a type is refined by the concept of a subtype, whereby a user can constrain the set of
     allowed values of a type.  Subtypes can be used to define subranges of scalar types, arrays with a
     limited set of index values, and records and private types with particular discriminant values.

     6Other0 6Facilities

0     Representation clauses can be used to specify the mapping between types and features of an underlying
     machine.  For example, the user can specify that objects of a given type must be represented with a given
     number of bits, or that the components of a record are to be represented using a given storage layout.
     Other features allow the controlled use of low level, nonportable, or implementation-dependent aspects,
     including the direct insertion of machine code.

     Input-output is defined in the language by means of predefined library packages.  Facilities are provided
     for input-output of values of user-defined as well as of predefined types.  Standard means of
     representing values in display form are also provided.

     Finally, the language provides a powerful means of parameterization of program units, called generic
     program units.  The generic parameters can be types and subprograms (as well as objects) and so allow
     general algorithms to be applied to all types of a given class.

      section lrm-section1-5

     21.5. Method of Description and Syntax Notation

0     The form of Ada program units is described by means of a context-free syntax together with
     context-dependent requirements expressed by narrative rules.

     The meaning of Ada program units is described by means of narrative rules defining both the effects of
     each construct and the composition rules for constructs.  This narrative employs technical terms whose
     precise definition is given in the text (references to the section containing the definition of a
     technical term appear at the end of each section that uses the term).

     All other terms are in the English language and bear their natural meaning, as defined in Webster's Third
     New International Dictionary of the English Language.

     The context-free syntax of the language is described using a simple variant of Backus-Naur-Form.  In
     particular,

       (a) Lower case words, some containing embedded underlines, are used to denote syntactic
           categories, for example:

                     adding_operator

           Whenever the name of a syntactic category is used apart from the syntax rules themselves,
           spaces take the place of the underlines (thus:  adding operator).

       (b) Boldface words are used to denote reserved words, for example:

                     1array

0       (c) Square brackets enclose optional items.  Thus the two following rules are equivalent.

                     return_statement ::= 1return0 [expression];
                     return_statement ::= 1return0; | 1return0 expression;

       (d) Braces enclose a repeated item.  The item may appear zero or more times; the repetitions occur
           from left to right as with an equivalent left-recursive rule.  Thus the two following rules
           are equivalent.

                     term ::= factor {multiplying_operator factor}
                     term ::= factor | term multiplying_operator factor

       (e) A vertical bar separates alternative items unless it occurs immediately after an opening
           brace, in which case it stands for itself:

                     letter_or_digit ::= letter | digit
                     component_association ::= [choice {| choice} =>] expression

       (f) If the name of any syntactic category starts with an italicized part, it is equivalent to the
           category name without the italicized part.  The italicized part is intended to convey some
           semantic information.  For example 6type_0name and 6task_0name are both equivalent to name
           alone.

     6Note:

0     The syntax rules describing structured constructs are presented in a form that corresponds to the
     recommended paragraphing.  For example, an if statement is defined as

         if_statement ::=
              1if0 condition 1then
0                    sequence_of_statements
            { 1elsif0 condition 1then
0                    sequence_of_statements}
            [ 1else
0                    sequence_of_statements]
              1end0 1if;

0     Different lines are used for parts of a syntax rule if the corresponding parts of the construct described
     by the rule are intended to be on different lines.  Indentation in the rule is a recommendation for
     indentation of the corresponding part of the construct.  It is recommended that all indentations be by
     multiples of a basic step of indentation (the number of spaces for the basic step is not defined).  The
     preferred places for other line breaks are after semicolons.  On the other hand, if a complete construct
     can fit on one line, this is also allowed in the recommended paragraphing.

      section lrm-section1-6

     21.6. Classification of Errors

0     The language definition classifies errors into several different categories:

       (a) Errors that must be detected at compilation time by every Ada compiler.

           These errors correspond to any violation of a rule given in this reference manual, other than
           the violations that correspond to (b) or (c) below.  In particular, violation of any rule that
           uses the terms 6must,0 6allowed,0 6legal,0 or 6illegal0 belongs to this category.  Any
           program that contains such an error is not a legal Ada program; on the other hand, the fact
           that a program is legal does not mean, per se, that the program is free from other forms of
           error.

       (b) Errors that must be detected at run time by the execution of an Ada program.

           The corresponding error situations are associated with the names of the predefined exceptions.
           Every Ada compiler is required to generate code that raises the corresponding exception if
           such an error situation arises during program execution.  If an exception is certain to be
           raised in every execution of a program, then compilers are allowed (although not required) to
           report this fact at compilation time.

       (c) Erroneous execution.

           The language rules specify certain rules to be obeyed by Ada programs, although there is no
           requirement on Ada compilers to provide either a compilation-time or a run-time detection of
           the violation of such rules.  The errors of this category are indicated by the use of the word
           6erroneous0 to qualify the execution of the corresponding constructs.  The effect of
           erroneous execution is unpredictable.

       (d) Incorrect order dependences.

           Whenever the reference manual specifies that different parts of a given construct are to be
           executed 6in0 6some0 6order0 6that0 6is0 6not0 6defined0 6by0 6the0 6language,0 this means that the
	   implementation is allowed to execute these parts in any given order, following the rules that
           result from that given order, but not in parallel. Furthermore, the construct is incorrect if
           execution of these parts in a different order would have a different effect.  Compilers are
           not required to provide either compilation-time or run-time detection of incorrect order
           dependences.  The foregoing is expressed in terms of the process that is called execution;
           it applies equally to the processes that are called evaluation and elaboration.

     If a compiler is able to recognize at compilation time that a construct is erroneous or contains an
     incorrect order dependence, then the compiler is allowed to generate, in place of the code otherwise
     generated for the construct, code that raises the predefined exception PROGRAM_ERROR.  Similarly,
     compilers are allowed to generate code that checks at run time for erroneous constructs, for incorrect
     order dependences, or for both.  The predefined exception PROGRAM_ERROR is raised if such a check fails.

      chapter lrm-chapter-2



                                                12. Lexical Elements

0     The text of a program consists of the texts of one or more compilations.  The text of a compilation is a
     sequence of lexical elements, each composed of characters; the rules of composition are given in this
     chapter.  Pragmas, which provide certain information for the compiler, are also described in this
     chapter.

     6References:0 4 character 2.1, compilation 10.1, lexical element 2.2, pragma 2.8 0

      section lrm-section2-1

     22.1. Character Set

0     The only characters allowed in the text of a program are the graphic characters and format effectors.
     Each graphic character corresponds to a unique code of the 6ISO0 seven-bit coded character set (6ISO
0     standard 646), and is represented (visually) by a graphical symbol.  Some graphic characters are
     represented by different graphical symbols in alternative national representations of the 6ISO
0     character set.  The description of the language definition in this standard reference manual uses the
     6ASCII0 graphical symbols, the 6ANSI0 graphical representation of the 6ISO0 character set.

         graphic_character ::= basic_graphic_character
            | lower_case_letter | other_special_character

         basic_graphic_character ::=
               upper_case_letter  | digit
            |  special_character  | space_character

         basic_character ::=
                basic_graphic_character | format_effector

     The basic character set is sufficient for writing any program.  The characters included in each of the
     categories of basic graphic characters are defined as follows:

       (a) upper case letters
           A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

       (b) digits
           0 1 2 3 4 5 6 7 8 9

       (c) special characters
           " # & ' ( ) * + , - . / : ; < = > _ |

       (d) the space character

     Format effectors are the 6ISO0 (and 6ASCII)0 characters called horizontal tabulation, vertical
     tabulation, carriage return, line feed, and form feed.

     The characters included in each of the remaining categories of graphic characters are defined as follows:

       (a) lower case letters
           a b c d e f g h i j k l m n o p q r s t u v w x y z

       (b) other special characters
           ! $ % ? @ [ \ ] ^ ` { } ~

     Allowable replacements for the special characters vertical bar (|), sharp (#), and quotation (") are
     defined in section 2.10.

     6Notes:

0     The 6ISO0 character that corresponds to the sharp graphical symbol in the 6ASCII0 representation
     appears as a pound sterling symbol in the French, German, and United Kingdom standard national
     representations.  In any case, the font design of graphical symbols (for example, whether they are in
     italic or bold typeface) is not part of the 6ISO0 standard.

     The meanings of the acronyms used in this section are as follows:  6ANSI0 stands for American National
     Standards Institute, 6ASCII0 stands for American Standard Code for Information Interchange, and 6ISO
0     stands for International Organization for Standardization.

     The following names are used when referring to special characters and other special characters:

         6symbol0      6name0                          6symbol0      6name

0             "           quotation                       >          greater than
             #          sharp                           _          underline
             &          ampersand                      |          vertical bar
             '           apostrophe                     !          exclamation mark
             (           left parenthesis               $          dollar
             )           right parenthesis              %          percent
             *          star, multiply                   ?          question mark
             +          plus                             @          commercial at
             ,           comma                          [          left square bracket
             -          hyphen, minus                  \          back-slash
             .           dot, point, period              ]          right square bracket
             /          slash, divide                    ^          circumflex
             :           colon                           3` 2        0grave accent
             ;           semicolon                      {          left brace
             <           less than                      }          right brace
             =           equal                           ~          tilde

      section lrm-section2-2

     22.2. Lexical Elements, Separators, and Delimiters

0     The text of a program consists of the texts of one or more compilations.  The text of each compilation is
     a sequence of separate lexical elements.  Each lexical element is either a delimiter, an identifier
     (which may be a reserved word), a numeric literal, a character literal, a string literal, or a comment.
     The effect of a program depends only on the particular sequences of lexical elements that form its
     compilations, excluding the comments, if any.

     In some cases an explicit 6separator0 is required to separate adjacent lexical elements (namely, when
     without separation, interpretation as a single lexical element is possible).  A separator is any of a
     space character, a format effector, or the end of a line.  A space character is a separator except within
     a comment, a string literal, or a space character literal.  Format effectors other than horizontal
     tabulation are always separators.  Horizontal tabulation is a separator except within a comment.

     The end of a line is always a separator.  The language does not define what causes the end of a line.
     However if, for a given implementation, the end of a line is signified by one or more characters, then
     these characters must be format effectors other than horizontal tabulation.  In any case, a sequence of
     one or more format effectors other than horizontal tabulation must cause at least one end of line.

     One or more separators are allowed between any two adjacent lexical elements, before the first of each
     compilation, or after the last.  At least one separator is required between an identifier or a numeric
     literal and an adjacent identifier or numeric literal.

     A 6delimiter0 is either one of the following special characters (in the basic character set)

         & ' ( ) * + , - . / : ; < = > |

     or one of the following 6compound0 6delimiters0 each composed of two adjacent special characters

         =>   ..   **   :=   /=   >=   <=   <<   >>   <>

     Each of the special characters listed for single character delimiters is a single delimiter except if
     this character is used as a character of a compound delimiter, or as a character of a comment, string
     literal, character literal, or numeric literal.

     The remaining forms of lexical element are described in other sections of this chapter.

     6Notes:

0     Each lexical element must fit on one line, since the end of a line is a separator.  The quotation, sharp,
     and underline characters, likewise two adjacent hyphens, are not delimiters, but may form part of other
     lexical elements.

     The following names are used when referring to compound delimiters:

         6delimiter0     6name

0               =>          arrow
               ..          double dot
               **          double star, exponentiate
               :=          assignment (pronounced: "becomes")
               /=          inequality (pronounced: "not equal")
               >=          greater than or equal
               <=          less than or equal
               <<          left label bracket
               >>          right label bracket
               <>          box

     6References:0 4 character literal 2.5, comment 2.7, compilation 10.1, format effector 2.1, identifier
     2.3, numeric literal 2.4, reserved word 2.9, space character 2.1, special character 2.1, string literal
     2.6 0

      section lrm-section2-3

     22.3. Identifiers

0     Identifiers are used as names and also as reserved words.

         identifier ::=
            letter {[underline] letter_or_digit}

         letter_or_digit ::= letter | digit

         letter ::= upper_case_letter | lower_case_letter

     All characters of an identifier are significant, including any underline character inserted between a
     letter or digit and an adjacent letter or digit.  Identifiers differing only in the use of corresponding
     upper and lower case letters are considered as the same.

     6Examples:

0         COUNT           X           get_symbol           Ethelyn           Marion

         SNOBOL_4        X1          PageCount            STORE_NEXT_ITEM

     6Note:

0     No space is allowed within an identifier since a space is a separator.

     6References:0 4 digit 2.1, lower case letter 2.1, name 4.1, reserved word 2.9, separator 2.2, space
     character 2.1, upper case letter 2.1 0

      section lrm-section2-4  

     22.4. Numeric Literals

0     There are two classes of numeric literals:  real literals and integer literals.  A real literal is a
     numeric literal that includes a point; an integer literal is a numeric literal without a point.  Real
     literals are the literals of the type 6universal0_6real.0 Integer literals are the literals of the
     type 6universal0_6integer.

0         numeric_literal    ::= decimal_literal | based_literal

     6References:0 4 literal 4.2, universal0_4integer type 3.5.4, universal0_4real type 3.5.60  

      subsection lrm-section2-4-1



     72.4.1. Decimal Literals

0     A decimal literal is a numeric literal expressed in the conventional decimal notation (that is, the base
     is implicitly ten).

         decimal_literal  ::= integer [.integer] [exponent]

         integer      ::= digit {[underline] digit}

         exponent     ::= E [+] integer | E - integer

     An underline character inserted between adjacent digits of a decimal literal does not affect the value of
     this numeric literal.  The letter E of the exponent, if any, can be written either in lower case or in
     upper case, with the same meaning.

     An exponent indicates the power of ten by which the value of the decimal literal without the exponent is
     to be multiplied to obtain the value of the decimal literal with the exponent.  An exponent for an
     integer literal must not have a minus sign.

     6Examples:

0         12             0             1E6             123_456             --  integer literals

         12.0           0.0           0.456           3.14159_26          --  real literals

         1.34E-12       1.0E+6                                            --  real literals with exponent


     6Notes:

0     Leading zeros are allowed.  No space is allowed in a numeric literal, not even between constituents of
     the exponent, since a space is a separator.  A zero exponent is allowed for an integer literal.

     6References:0 4 digit 2.1, lower case letter 2.1, numeric literal 2.4, separator 2.2, space character
     2.1, upper case letter 2.1 0

      section lrm-section2-4-2



     72.4.2. Based Literals

0     A based literal is a numeric literal expressed in a form that specifies the base explicitly.  The base
     must be at least two and at most sixteen.

         based_literal ::=
            base # based_integer [.based_integer] # [exponent]

         base ::= integer

         based_integer ::=
            extended_digit {[underline] extended_digit}

         extended_digit ::= digit | letter

     An underline character inserted between adjacent digits of a based literal does not affect the value of
     this numeric literal.  The base and the exponent, if any, are in decimal notation.  The only letters
     allowed as extended digits are the letters A through F for the digits ten through fifteen.  A letter in a
     based literal (either an extended digit or the letter E of an exponent) can be written either in lower
     case or in upper case, with the same meaning.

     The conventional meaning of based notation is assumed; in particular the value of each extended digit of
     a based literal must be less than the base.  An exponent indicates the power of the base by which the
     value of the based literal without the exponent is to be multiplied to obtain the value of the based
     literal with the exponent.

     6Examples:

0         2#1111_1111#      16#FF#      016#0FF#          -- integer literals of value 255
         16#E#E1           2#1110_0000#                  -- integer literals of value 224
         16#F.FF#E+2       2#1.1111_1111_111#E11         -- real literals of value 4095.0

     6References:0 4 digit 2.1, exponent 2.4.1, letter 2.3, lower case letter 2.1, numeric literal 2.4,
     upper case letter 2.1 0

      section lrm-section2-5

     22.5. Character Literals

0     A character literal is formed by enclosing one of the 95 graphic characters (including the space) between
     two apostrophe characters.  A character literal has a value that belongs to a character type.

         character_literal ::= 'graphic_character'

     6Examples:

0         'A'   '*'   '''   ' '

     6References:0 4 character type 3.5.2, graphic character 2.1, literal 4.2, space character 2.1 0 

      section lrm-section2-6

     22.6. String Literals

0     A string literal is formed by a sequence of graphic characters (possibly none) enclosed between two
     quotation characters used as 6string0 6brackets.

0         string_literal ::= "{graphic_character}"

     A string literal has a value that is a sequence of character values corresponding to the graphic
     characters of the string literal apart from the quotation character itself.  If a quotation character
     value is to be represented in the sequence of character values, then a pair of adjacent quotation
     characters must be written at the corresponding place within the string literal.  (This means that a
     string literal that includes two adjacent quotation characters is never interpreted as two adjacent
     string literals.)

     The 6length0 of a string literal is the number of character values in the sequence represented.  (Each
     doubled quotation character is counted as a single character.)

     6Examples:

0         "Message of the day:"  

         ""                     --  an empty string literal
         " "   "A"   """"       --  three string literals of length 1

         "Characters such as $, %, and } are allowed in string literals"


     6Note:

0     A string literal must fit on one line since it is a lexical element (see 2.2).  Longer sequences of
     graphic character values can be obtained by catenation of string literals.  Similarly catenation of
     constants declared in the package ASCII can be used to obtain sequences of character values that include
     nongraphic character values (the so-called control characters).  Examples of such uses of catenation are
     given below:

         "FIRST PART OF A SEQUENCE OF CHARACTERS " &
         "THAT CONTINUES ON THE NEXT LINE"

         "sequence that includes the" & ASCII.ACK & "control character"

     6References:0 4 ascii predefined package C, catenation operation 4.5.3, character value 3.5.2,
     constant 3.2.1, declaration 3.1, end of a line 2.2, graphic character 2.1, lexical element 2.20 4 0

      section lrm-section2-7

     22.7. Comments

0     A comment starts with two adjacent hyphens and extends up to the end of the line.  A comment can appear
     on any line of a program.  The presence or absence of comments has no influence on whether a program is
     legal or illegal.  Furthermore, comments do not influence the effect of a program; their sole purpose is
     the enlightenment of the human reader.

     6Examples:

0         --  the last sentence above echoes the Algol 68 report

         1end;0  --  processing of LINE is complete

         --  a long comment may be split onto
         --  two or more consecutive lines

         ----------------  the first two hyphens start the comment

     6Note:

0     Horizontal tabulation can be used in comments, after the double hyphen, and is equivalent to one or more
     spaces (see 2.2).

     6References:0 4 end of a line 2.2, illegal 1.6, legal 1.6, space character 2.1 0

      section lrm-section2-8

     22.8. Pragmas

0     A pragma is used to convey information to the compiler.  A pragma starts with the reserved word
     1pragma0 followed by an identifier that is the name of the pragma.

         pragma ::=
            1pragma0 identifier [(argument_association {, argument_association})];

         argument_association ::=
              [6argument0_identifier =>] name
            | [6argument0_identifier =>] expression


     Pragmas are only allowed at the following places in a program:

        - After a semicolon delimiter, but not within a formal part or discriminant part.

        - At any place where the syntax rules allow a construct defined by a syntactic category whose
          name ends with "declaration", "statement", "clause", or "alternative", or one of the syntactic
          categories variant and exception handler; but not in place of such a construct.  Also at any
          place where a compilation unit would be allowed.

     Additional restrictions exist for the placement of specific pragmas.

     Some pragmas have arguments.  Argument associations can be either positional or named as for parameter
     associations of subprogram calls (see 6.4).  Named associations are, however, only possible if the
     argument identifiers are defined.  A name given in an argument must be either a name visible at the place
     of the pragma or an identifier specific to the pragma.

     The pragmas defined by the language are described in Annex B:  they must be supported by every
     implementation.  In addition, an implementation may provide implementation-defined pragmas, which must
     then be described in Appendix F. An implementation is not allowed to define pragmas whose presence or
     absence influences the legality of the text outside such pragmas.  Consequently, the legality of a
     program does not depend on the presence or absence of implementation-defined pragmas.

     A pragma that is not language-defined has no effect if its identifier is not recognized by the (current)
     implementation.  Furthermore, a pragma (whether language-defined or implementation-defined) has no effect
     if its placement or its arguments do not correspond to what is allowed for the pragma.  The region of
     text over which a pragma has an effect depends on the pragma.

     6Examples:

0         1pragma0 LIST(OFF);
         1pragma0 OPTIMIZE(TIME);
         1pragma0 INLINE(SETMASK);
         1pragma0 SUPPRESS(RANGE_CHECK, ON => INDEX);

     6Note:

0     It is recommended (but not required) that implementations issue warnings for pragmas that are not
     recognized and therefore ignored.

     6References:0 4 compilation unit 10.1, delimiter 2.2, discriminant part 3.7.1, exception handler 11.2,
     expression 4.4, formal part 6.1, identifier 2.3, implementation-defined pragma F, language-defined pragma
     B, legal 1.6, name 4.1, reserved word 2.9, statement 5, static expression 4.9, variant 3.7.3, visibility
     8.30, 4basic declaration 3.1, component declaration 3.7, entry declaration 9.5, generic parameter
0    4declaration 12.10, 4alignment clause 13.4, component clause0 413.4, context clause 10.1.1, representation
0    4clause 13.1, use clause 8.4, with clause 10.1.10,4 accept alternative 9.7.1, case statement alternative
0    45.4, delay alternative 9.7.1, select alternative 9.7.1, selective wait alternative0,4 9.7.1, terminate
0    4alternative 9.7.10

      section lrm-section2-9

     22.9. Reserved Words

0     The identifiers listed below are called 6reserved0 6words0 and are reserved for special significance
     in the language.  For readability of this manual, the reserved words appear in lower case boldface.

         1abort           declare          0 1generic           of           select
0         1abs             delay            0 1goto0 1             or           separate
0         1accept         0 1delta                               others     0  1subtype
0         1access         0 1digits           0 1 if                out
0         1all             0  1do              0 1in                             0 1task
0         1and                              0 1is                package    0  1terminate
0         1array                                               pragma     0  1then
0         1at              else                                private     0   1type
0         1                elsif              limited          0  1procedure
0         1                end              loop
0         1begin          0 1entry                               raise        0  1use
0         1body           exception                         0  1range
0         1                exit               mod             record      0  1when
0         1                                                   0 1rem         0 1while
0         1                                  new            0 1 renames    0  1with
0         1case           for               0 1not             0  1return
0         1constant      0 1function          0 1null             0  1reverse     0  1xor

0     A reserved word must not be used as a declared identifier.

     6Notes:

0     Reserved words differing only in the use of corresponding upper and lower case letters are considered as
     the same (see 2.3).  In some attributes the identifier that appears after the apostrophe is identical to
     some reserved word.

     6References:0 4 attribute 4.1.4, declaration 3.1, identifier 2.3, lower case letter 2.1, upper case
     letter 2.1 0

      section lrm-section2-10

     22.10. Allowable Replacements of Characters

0     The following replacements are allowed for the vertical bar, sharp, and quotation basic characters:

        - A vertical bar character (|) can be replaced by an exclamation mark (!)  where used as a
          delimiter.

        - The sharp characters (#) of a based literal can be replaced by colons (:) provided that the
          replacement is done for both occurrences.

        - The quotation characters (") used as string brackets at both ends of a string literal can be
          replaced by percent characters (%) provided that the enclosed sequence of characters contains
          no quotation character, and provided that both string brackets are replaced.  Any percent
          character within the sequence of characters must then be doubled and each such doubled percent
          character is interpreted as a single percent character value.

     These replacements do not change the meaning of the program.

     6Notes:

0     It is recommended that use of the replacements for the vertical bar, sharp, and quotation characters be
     restricted to cases where the corresponding graphical symbols are not available.  Note that the vertical
     bar appears as a broken bar on some equipment; replacement is not recommended in this case.

     The rules given for identifiers and numeric literals are such that lower case and upper case letters can
     be used indifferently; these lexical elements can thus be written using only characters of the basic
     character set.  If a string literal of the predefined type STRING contains characters that are not in the
     basic character set, the same sequence of character values can be obtained by catenating string literals
     that contain only characters of the basic character set with suitable character constants declared in the
     predefined package ASCII.  Thus the string literal "AB$CD" could be replaced by "AB" & ASCII.DOLLAR &
     "CD".  Similarly, the string literal "ABcd" with lower case letters could be replaced by "AB" &
     ASCII.LC_C & ASCII.LC_D.

     6References:0 4 ascii predefined package C, based literal 2.4.2, basic character 2.1, catenation
     operation 4.5.3, character value 3.5.2, delimiter 2.2, graphic character 2.1, graphical symbol 2.1,
     identifier 2.3, lexical element 2.2, lower case letter 2.1, numeric literal 2.4, string bracket 2.6,
     string literal 2.6, upper case letter 2.1 0

      chapter lrm-chapter-3



                                             13. Declarations and Types

0     This chapter describes the types in the language and the rules for declaring constants, variables, and
     named numbers.

      section lrm-section3-1

     23.1. Declarations

0     The language defines several kinds of entities that are declared, either explicitly or implicitly, by
     declarations.  Such an entity can be a numeric literal, an object, a discriminant, a record component, a
     loop parameter, an exception, a type, a subtype, a subprogram, a package, a task unit, a generic unit, a
     single entry, an entry family, a formal parameter (of a subprogram, entry, or generic subprogram), a
     generic formal parameter, a named block or loop, a labeled statement, or an operation (in particular, an
     attribute or an enumeration literal; see 3.3.3).

     There are several forms of declaration.  A basic declaration is a form of declaration defined as follows.

         basic_declaration ::=
               object_declaration            | number_declaration
            |  type_declaration              | subtype_declaration
            |  subprogram_declaration        | package_declaration
            |  task_declaration              | generic_declaration
            |  exception_declaration         | generic_instantiation
            |  renaming_declaration          | deferred_constant_declaration

     Certain forms of declaration always occur (explicitly) as part of a basic declaration; these forms are
     discriminant specifications, component declarations, entry declarations, parameter specifications,
     generic parameter declarations, and enumeration literal specifications.  A loop parameter specification
     is a form of declaration that occurs only in certain forms of loop statement.

     The remaining forms of declaration are implicit:  the name of a block, the name of a loop, and a
     statement label are implicitly declared.  Certain operations are implicitly declared (see 3.3.3).

     For each form of declaration the language rules define a certain region of text called the 6scope0 of
     the declaration (see 8.2).  Several forms of declaration associate an identifier with a declared entity.
     Within its scope, and only there, there are places where it is possible to use the identifier to refer to
     the associated declared entity; these places are defined by the visibility rules (see 8.3).  At such
     places the identifier is said to be a 6name0 of the entity (its simple name); the name is said to
     6denote0 the associated entity.

     Certain forms of enumeration literal specification associate a character literal with the corresponding
     declared entity.  Certain forms of declaration associate an operator symbol or some other notation with
     an explicitly or implicitly declared operation.

     The process by which a declaration achieves its effect is called the 6elaboration0 of the declaration;
     this process happens during program execution.

     After its elaboration, a declaration is said to be 6elaborated.0 Prior to the completion of its
     elaboration (including before the elaboration), the declaration is not yet elaborated.  The elaboration
     of any declaration has always at least the effect of achieving this change of state (from not yet
     elaborated to elaborated).  The phrase "6the0 6elaboration0 6has0 6no0 6other0 6effect"0 is
     used in this manual whenever this change of state is the only effect of elaboration for some form of
     declaration.  An elaboration process is also defined for declarative parts, declarative items, and
     compilation units (see 3.9 and 10.5).

     Object, number, type, and subtype declarations are described here.  The remaining basic declarations are
     described in later chapters.

     6Note:

0     The syntax rules use the term 6identifier0 for the first occurrence of an identifier in some form of
     declaration; the term 6simple0 6name0 is used for any occurrence of an identifier that already
     denotes some declared entity.

     6References:0 4 attribute 4.1.4, block name 5.6, block statement 5.6, character literal 2.5, component
     declaration 3.7, declarative item 3.9, declarative part 3.9, deferred constant declaration 7.4,
     discriminant specification 3.7.1, elaboration 3.9, entry declaration 9.5, enumeration literal
     specification 3.5.1, exception declaration 11.1, generic declaration 12.1, generic instantiation 12.3,
     generic parameter declaration 12.1, identifier 2.3, label 5.1, loop name 5.5, loop parameter
     specification 5.5, loop statement 5.5, name 4.1, number declaration 3.2.2, numeric literal 2.4, object
     declaration 3.2.1, operation 3.3, operator symbol 6.1, package declaration 7.1, parameter specification
     6.1, record component 3.7, renaming declaration 8.5, representation clause 13.1, scope 8.2, simple name
     4.1, subprogram body 6.3, subprogram declaration 6.1, subtype declaration 3.3.2, task declaration 9.1,
     type declaration 3.3.1, visibility 8.30

      section lrm-section3-2

     23.2. Objects and Named Numbers

0     An 6object0 is an entity that contains (has) a value of a given type.  An object is one of the
     following:

        - an object declared by an object declaration or by a single task declaration,

        - a formal parameter of a subprogram, entry, or generic subprogram,

        - a generic formal object,

        - a loop parameter,

        - an object designated by a value of an access type,

        - a component or a slice of another object.

     A number declaration is a special form of object declaration that associates an identifier with a value
     of type 6universal_integer0 or 6universal_real0.

         object_declaration ::=
               identifier_list : [1constant0] subtype_indication [:= expression];
            |  identifier_list : [1constant0] constrained_array_definition [:= expression];

         number_declaration ::=
               identifier_list : 1constant0 := 6universal_static0_expression;

         identifier_list ::=  identifier {, identifier}

     An object declaration is called a 6single object declaration0 if its identifier list has a single
     identifier; it is called a 6multiple object declaration0 if the identifier list has two or more
     identifiers.  A multiple object declaration is equivalent to a sequence of the corresponding number of
     single object declarations.  For each identifier of the list, the equivalent sequence has a single object
     declaration formed by this identifier, followed by a colon and by whatever appears at the right of the
     colon in the multiple object declaration; the equivalent sequence is in the same order as the identifier
     list.

     A similar equivalence applies also for the identifier lists of number declarations, component
     declarations, discriminant specifications, parameter specifications, generic parameter declarations,
     exception declarations, and deferred constant declarations.

     In the remainder of this reference manual, explanations are given for declarations with a single
     identifier; the corresponding explanations for declarations with several identifiers follow from the
     equivalence stated above.

     6Example:

0         --  the multiple object declaration

         JOHN, PAUL : PERSON_NAME := 1new0 PERSON(SEX => M);  --  see 3.8.1
         --  is equivalent to the two single object declarations in the order given

         JOHN  : PERSON_NAME := 1new0 PERSON(SEX => M);
         PAUL  : PERSON_NAME := 1new0 PERSON(SEX => M);

     6References:0 4 access type 3.8, constrained array definition 3.6, component 3.3, declaration 3.1,
     deferred constant declaration 7.4, designate 3.8, discriminant specification 3.7.1, entry 9.5, exception
     declaration 11.1, expression 4.4, formal parameter 6.1, generic formal object 12.1.1, generic parameter
     declaration 12.1, generic unit 12, generic subprogram 12.1, identifier 2.3, loop parameter 5.5, numeric
     type 3.5, parameter specification 6.1, scope 8.2, simple name 4.1, single task declaration 9.1, slice
     4.1.2, static expression 4.9, subprogram 6, subtype indication 3.3.2, type 3.3, universal_integer type
     3.5.4, universal_real type 3.5.6 0

      subsection lrm-section3-2-1



     73.2.1. Object Declarations

0     An object declaration declares an object whose type is given either by a subtype indication or by a
     constrained array definition.  If the object declaration includes the assignment compound delimiter
     followed by an expression, the expression specifies an initial value for the declared object; the type of
     the expression must be that of the object.

     The declared object is a 6constant0 if the reserved word 1constant0 appears in the object
     declaration; the declaration must then include an explicit initialization.  The value of a constant
     cannot be modified after initialization.  Formal parameters of mode 1in0 of subprograms and entries,
     and generic formal parameters of mode 1in,0 are also constants; a loop parameter is a constant within
     the corresponding loop; a subcomponent or slice of a constant is a constant.

     An object that is not a constant is called a 6variable0 (in particular, the object declared by an
     object declaration that does not include the reserved word 1constant0 is a variable).  The only ways to
     change the value of a variable are either directly by an assignment, or indirectly when the variable is
     updated (see 6.2) by a procedure or entry call statement (this action can be performed either on the
     variable itself, on a subcomponent of the variable, or on another variable that has the given variable as
     subcomponent).

     The elaboration of an object declaration proceeds as follows:

       (a) The subtype indication or the constrained array definition is first elaborated.  This
           establishes the subtype of the object.

       (b) If the object declaration includes an explicit initialization, the initial value is obtained
           by evaluating the corresponding expression.  Otherwise any implicit initial values for the
           object or for its subcomponents are evaluated.

       (c) The object is created.

       (d) Any initial value (whether explicit or implicit) is assigned to the object or to the
           corresponding subcomponent.

     Implicit initial values are defined for objects declared by object declarations, and for components of
     such objects, in the following cases:

        - If the type of an object is an access type, the implicit initial value is the null value of the
          access type.

        - If the type of an object is a task type, the implicit initial (and only) value designates a
          corresponding task.

        - If the type of an object is a type with discriminants and the subtype of the object is
          constrained, the implicit initial (and only) value of each discriminant is defined by the
          subtype of the object.

        - If the type of an object is a composite type, the implicit initial value of each component that
          has a default expression is obtained by evaluation of this expression, unless the component is
          a discriminant of a constrained object (the previous case).

     In the case of a component that is itself a composite object and whose value is defined neither by an
     explicit initialization nor by a default expression, any implicit initial values for components of the
     composite object are defined by the same rules as for a declared object.

     The steps (a) to (d) are performed in the order indicated.  For step (b), if the default expression for a
     discriminant is evaluated, then this evaluation is performed before that of default expressions for
     subcomponents that depend on discriminants, and also before that of default expressions that include the
     name of the discriminant.  Apart from the previous rule, the evaluation of default expressions is
     performed in some order that is not defined by the language.

     The initialization of an object (the declared object or one of its subcomponents) checks that the initial
     value belongs to the subtype of the object; for an array object declared by an object declaration, an
     implicit subtype conversion is first applied as for an assignment statement, unless the object is a
     constant whose subtype is an unconstrained array type.  The exception CONSTRAINT_ERROR is raised if this
     check fails.

     The value of a scalar variable is undefined after elaboration of the corresponding object declaration
     unless an initial value is assigned to the variable by an initialization (explicitly or implicitly).

     If the operand of a type conversion or qualified expression is a variable that has scalar subcomponents
     with undefined values, then the values of the corresponding subcomponents of the result are undefined.
     The execution of a program is erroneous if it attempts to evaluate a scalar variable with an undefined
     value.  Similarly, the execution of a program is erroneous if it attempts to apply a predefined operator
     to a variable that has a scalar subcomponent with an undefined value.

     6Examples0 6of0 6variable0 6declarations:

0         COUNT, SUM      : INTEGER;
         SIZE                 : INTEGER 1range0 0 .. 10_000 := 0;
         SORTED            : BOOLEAN := FALSE;
         COLOR_TABLE    : 1array0(1 .. N) 1of0 COLOR;
         OPTION             : BIT_VECTOR(1 .. 10) := (1others0 => TRUE);

     6Examples0 6of0 6constant0 6declarations:

0         LIMIT             : 1constant0 INTEGER    := 10_000;
         LOW_LIMIT      : 1constant0 INTEGER    := LIMIT/10;
         TOLERANCE    : 1constant0 REAL := DISPERSION(1.15);

     6Note:

0     The expression initializing a constant object need not be a static expression (see 4.9).  In the above
     examples, LIMIT and LOW_LIMIT are initialized with static expressions, but TOLERANCE is not if DISPERSION
     is a user-defined function.

     6References:0 4 access type 3.8, assignment 5.2, assignment compound delimiter 5.2, component 3.3,
     composite type 3.3, constrained array definition 3.6, constrained subtype 3.3, constraint_error exception
     11.1, conversion 4.6, declaration 3.1, default expression for a discriminant 3.7, default initial value
     for an access type 3.8, depend on a discriminant 3.7.1, designate 3.8, discriminant 3.3, elaboration 3.9,
     entry 9.5, evaluation 4.5, expression 4.4, formal parameter 6.1, generic formal parameter 12.1 12.3,
     generic unit 12, in some order 1.6, limited type 7.4.4, mode in 6.1, package 7, predefined operator 4.5,
     primary 4.4, private type 7.4, qualified expression 4.7, reserved word 2.9, scalar type 3.5, slice 4.1.2,
     subcomponent 3.3, subprogram 6, subtype 3.3, subtype indication 3.3.2, task 9, task type 9.2, type 3.3,
     visible part 7.20

      subsection lrm-section3-2-2



     73.2.2. Number Declarations

0     A number declaration is a special form of constant declaration.  The type of the static expression given
     for the initialization of a number declaration must be either the type 6universal_integer0 or the type
     6universal_real.0 The constant declared by a number declaration is called a 6named0 6number0 and
     has the type of the static expression.

     6Note:

0     The rules concerning expressions of a universal type are explained in section 4.10.  It is a consequence
     of these rules that if every primary contained in the expression is of the type 6universal_integer,
0     then the named number is also of this type.  Similarly, if every primary is of the type
     6universal_real,0 then the named number is also of this type.

     6Examples0 6of0 6number0 6declarations:

0         PI                     : 1constant0 := 3.14159_26536;   -- a real number
         TWO_PI                 : 1constant0 := 2.0*PI;          -- a real number
         MAX                    : 1constant0 := 500;             -- an integer number
         POWER_16               : 1constant0 := 2**16;           -- the integer 65_536
         ONE, UN, EINS          : 1constant0 := 1;               -- three different names for 1

     6References:0 4 identifier 2.3, primary 4.4, static expression 4.9, type 3.3, universal_integer type
     3.5.4, universal_real type 3.5.6, universal type 4.100

      section lrm-section3-3

     23.3. Types and Subtypes

0     A type is characterized by a set of values and a set of operations.

     There exist several 6classes0 of types.  6Scalar0 types are integer types, real types, and types
     defined by enumeration of their values; values of these types have no components.  6Array0 and
     6record0 types are composite; a value of a composite type consists of 6component0 values.  An
     6access0 type is a type whose values provide access to objects.  6Private0 types are types for which
     the set of possible values is well defined, but not directly available to the users of such types.
     Finally, there are 6task0 types.  (Private types are described in chapter 7, task types are described
     in chapter 9, the other classes of types are described in this chapter.)

     Certain record and private types have special components called 6discriminants0 whose values
     distinguish alternative forms of values of one of these types.  If a private type has discriminants, they
     are known to users of the type.  Hence a private type is only known by its name, its discriminants if
     any, and by the corresponding set of operations.

     The set of possible values for an object of a given type can be subjected to a condition that is called a
     6constraint0 (the case where the constraint imposes no restriction is also included); a value is said
     to 6satisfy0 a constraint if it satisfies the corresponding condition.  A 6subtype0 is a type
     together with a constraint; a value is said to 6belong0 6to0 6a0 6subtype0 of a given type if it
     belongs to the type and satisfies the constraint; the given type is called the 6base0 6type0 of the
     subtype.  A type is a subtype of itself; such a subtype is said to be 6unconstrained:0 it corresponds
     to a condition that imposes no restriction.  The base type of a type is the type itself.

     The set of operations defined for a subtype of a given type includes the operations that are defined for
     the type; however the assignment operation to a variable having a given subtype only assigns values that
     belong to the subtype.  Additional operations, such as qualification (in a qualified expression), are
     implicitly defined by a subtype declaration.

     Certain types have 6default0 6initial0 6values0 defined for objects of the type; certain other
     types have 6default0 6expressions0 defined for some or all of their components.  Certain operations
     of types and subtypes are called 6attributes;0 these operations are denoted by the form of name
     described in section 4.1.4.

     The term 6subcomponent0 is used in this manual in place of the term component to indicate either a
     component, or a component of another component or subcomponent.  Where other subcomponents are excluded,
     the term component is used instead.

     A given type must not have a subcomponent whose type is the given type itself.

     The name of a class of types is used in this manual as a qualifier for objects and values that have a
     type of the class considered.  For example, the term "array object" is used for an object whose type is
     an array type; similarly, the term "access value" is used for a value of an access type.

     6Note:

0     The set of values of a subtype is a subset of the values of the base type.  This subset need not be a
     proper subset; it can be an empty subset.

     6References:0 4 access type 3.8, array type 3.6, assignment 5.2, attribute 4.1.4, component of an
     array 3.6, component of a record 3.7, discriminant constraint 3.7.2, enumeration type 3.5.1, integer type
     3.5.4, object 3.2.1, private type 7.4, qualified expression 4.7, real type 3.5.6, record type 3.7,
     subtype declaration 3.3.2, task type 9.1, type declaration 3.3.10

      subsection lrm-section3-3-1



     73.3.1. Type Declarations

0     A type declaration declares a type.

         type_declaration ::=  full_type_declaration
           |  incomplete_type_declaration | private_type_declaration

         full_type_declaration ::=
              1type0 identifier [discriminant_part] 1is0 type_definition;

         type_definition ::=
              enumeration_type_definition  | integer_type_definition
            | real_type_definition         | array_type_definition
            | record_type_definition       | access_type_definition
            | derived_type_definition

     The elaboration of a full type declaration consists of the elaboration of the discriminant part, if any
     (except in the case of the full type declaration for an incomplete or private type declaration), and of
     the elaboration of the type definition.

     The types created by the elaboration of distinct type definitions are distinct types.  Moreover, the
     elaboration of the type definition for a numeric or derived type creates both a base type and a subtype
     of the base type; the same holds for a constrained array definition (one of the two forms of array type
     definition).

     The simple name declared by a full type declaration denotes the declared type, unless the type
     declaration declares both a base type and a subtype of the base type, in which case the simple name
     denotes the subtype, and the base type is anonymous.  A type is said to be 6anonymous0 if it has no
     simple name.  For explanatory purposes, this reference manual sometimes refers to an anonymous type by a
     pseudo-name, written in italics, and uses such pseudo-names at places where the syntax normally requires
     an identifier.

     6Examples0 6of0 6type0 6definitions:

0         (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK)
         1range0 1 .. 72
         1array0(1 .. 10) 1of0 INTEGER

     6Examples0 6of0 6type0 6declarations:

0         1type0 COLOR      1is0 (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
         1type0 COLUMN     1is0 1range0 1 .. 72;
         1type0 TABLE      1is0 1array0(1 .. 10) 1of0 INTEGER;

     6Notes:

0     Two type definitions always define two distinct types, even if they are textually identical.  Thus, the
     array type definitions given in the declarations of A and B below define distinct types.

         A   : 1array0(1 .. 10) 1of0 BOOLEAN;
         B   : 1array0(1 .. 10) 1of0 BOOLEAN;

     If A and B are declared by a multiple object declaration as below, their types are nevertheless
     different, since the multiple object declaration is equivalent to the above two single object
     declarations.

         A, B : 1array0(1 .. 10) 1of0 BOOLEAN;


     Incomplete type declarations are used for the definition of recursive and mutually dependent types (see
     3.8.1).  Private type declarations are used in package specifications and in generic parameter
     declarations (see 7.4 and 12.1).

     6References:0 4 access type definition 3.8, array type definition 3.6, base type 3.3, constrained
     array definition 3.6, constrained subtype 3.3, declaration 3.1, derived type 3.4, derived type definition
     3.4, discriminant part 3.7.1, elaboration 3.9, enumeration type definition 3.5.1, identifier 2.3,
     incomplete type declaration 3.8.1, integer type definition 3.5.4, multiple object declaration 3.2,
     numeric type 3.5, private type declaration 7.4, real type definition 3.5.6, reserved word 2.9, type 3.30

      subsection lrm-section3-3-2



     73.3.2. Subtype Declarations

0     A subtype declaration declares a subtype.

         subtype_declaration ::=
            1subtype0 identifier 1is0 subtype_indication;

         subtype_indication ::=  type_mark [constraint]

         type_mark ::= 6type0_name | 6subtype0_name

         constraint ::=
               range_constraint  | floating_point_constraint | fixed_point_constraint
            |  index_constraint  | discriminant_constraint

     A type mark denotes a type or a subtype.  If a type mark is the name of a type, the type mark denotes
     this type and also the corresponding unconstrained subtype.  The 6base0 6type0 6of0 6a0 6type
0     6mark0 is, by definition, the base type of the type or subtype denoted by the type mark.

     A subtype indication defines a subtype of the base type of the type mark.

     If an index constraint appears after a type mark in a subtype indication, the type mark must not already
     impose an index constraint.  Likewise for a discriminant constraint, the type mark must not already
     impose a discriminant constraint.

     The elaboration of a subtype declaration consists of the elaboration of the subtype indication.  The
     elaboration of a subtype indication creates a subtype.  If the subtype indication does not include a
     constraint, the subtype is the same as that denoted by the type mark.  The elaboration of a subtype
     indication that includes a constraint proceeds as follows:

       (a) The constraint is first elaborated.

       (b) A check is then made that the constraint is 6compatible0 with the type or subtype denoted by
           the type mark.

     The condition imposed by a constraint is the condition obtained after elaboration of the constraint.
     (The rules of constraint elaboration are such that the expressions and ranges of constraints are
     evaluated by the elaboration of these constraints.)  The rules defining compatibility are given for each
     form of constraint in the appropriate section.  These rules are such that if a constraint is compatible
     with a subtype, then the condition imposed by the constraint cannot contradict any condition already
     imposed by the subtype on its values.  The exception CONSTRAINT_ERROR is raised if any check of
     compatibility fails.

     6Examples0 6of0 6subtype0 6declarations:
0         1subtype0 RAINBOW       1is0 COLOR 1range0 RED .. BLUE;       --  see 3.3.1
         1subtype0 RED_BLUE      1is0 RAINBOW;
         1subtype0 INT           1is0 INTEGER;
         1subtype0 SMALL_INT     1is0 INTEGER 1range0 -10 .. 10;
         1subtype0 UP_TO_K       1is0 COLUMN 1range0 1 .. K;           --  see 3.3.1
         1subtype0 SQUARE        1is0 MATRIX(1 .. 10, 1 .. 10);          --  see 3.6
         1subtype0 MALE          1is0 PERSON(SEX => M);                  --  see 3.8

     6Note:

0     A subtype declaration does not define a new type.

     6References:0 4 base type 3.3, compatibility of discriminant constraints 3.7.2, compatibility of fixed
     point constraints 3.5.9, compatibility of floating point constraints 3.5.7, compatibility of index
     constraints 3.6.1, compatibility of range constraints 3.5, constraint_error exception 11.1, declaration
     3.1, discriminant 3.3, discriminant constraint 3.7.2, elaboration 3.9, evaluation 4.5, expression 4.4,
     floating point constraint 3.5.7, fixed point constraint 3.5.9, index constraint 3.6.1, range constraint
     3.5, reserved word 2.9, subtype 3.3, type 3.3, type name 3.3.1, unconstrained subtype 3.30

      subsection lrm-section3-3-3



     73.3.3. Classification of Operations

0     The set of operations of a type includes the explicitly declared subprograms that have a parameter or
     result of the type; such subprograms are necessarily declared after the type declaration.

     The remaining operations are each implicitly declared for a given type declaration, immediately after the
     type definition.  These implicitly declared operations comprise the 6basic0 operations, the predefined
     operators (see 4.5), and enumeration literals.  In the case of a derived type declaration, the implicitly
     declared operations include any derived subprograms.  The operations implicitly declared for a given type
     declaration occur after the type declaration and before the next explicit declaration, if any.  The
     implicit declarations of derived subprograms occur last.

     A basic operation is an operation that is inherent in one of the following:

        - An assignment (in assignment statements and initializations), an allocator, a membership test,
          or a short-circuit control form.

        - A selected component, an indexed component, or a slice.

        - A qualification (in qualified expressions), an explicit type conversion, or an implicit type
          conversion of a value of type 6universal_integer0 or 6universal_real0 to the corresponding
          value of another numeric type.

        - A numeric literal (for a universal type), the literal 1null0 (for an access type), a string
          literal, an aggregate, or an attribute.

     For every type or subtype T, the following attribute is defined:

     T'BASE              The base type of T. This attribute is allowed only as the prefix of the name of
                         another attribute:  for example, T'BASE'FIRST.

     6Note:

0     Each literal is an operation whose evaluation yields the corresponding value (see 4.2).  Likewise, an
     aggregate is an operation whose evaluation yields a value of a composite type (see 4.3).  Some operations
     of a type 6operate0 6on0 values of the type, for example, predefined operators and certain
     subprograms and attributes.  The evaluation of some operations of a type 6returns0 a value of the type,
     for example, literals and certain functions, attributes, and predefined operators.  Assignment is an
     operation that operates on an object and a value.  The evaluation of the operation corresponding to a
     selected component, an indexed component, or a slice, yields the object or value denoted by this form of
     name.  :text

     6References:0 4 aggregate 4.3, allocator 4.8, assignment 5.2, attribute 4.1.4, character literal 2.5,
     composite type 3.3, conversion 4.6, derived subprogram 3.4, enumeration literal 3.5.1, formal parameter
     6.1, function 6.5, indexed component 4.1.1, initial value 3.2.1, literal 4.2, membership test 4.5 4.5.2,
     null literal 3.8, numeric literal 2.4, numeric type 3.5, object 3.2.1, 6.1, predefined operator 4.5,
     qualified expression 4.7, selected component 4.1.3, short-circuit control form 4.5 4.5.1, slice 4.1.2,
     string literal 2.6, subprogram 6, subtype 3.3, type 3.3, type declaration 3.3.1, universal_integer type
     3.5.4, universal_real type 3.5.6, universal type 4.100

      section lrm-section3-4

     23.4. Derived Types

0     A derived type definition defines a new (base) type whose characteristics are derived from those of a
     6parent0 6type;0 the new type is called a 6derived0 6type.0 A derived type definition further
     defines a 6derived0 6subtype,0 which is a subtype of the derived type.

         derived_type_definition ::= 1new0 subtype_indication

     The subtype indication that occurs after the reserved word 1new0 defines the 6parent0 6subtype.
0     The parent type is the base type of the parent subtype.  If a constraint exists for the parent subtype, a
     similar constraint exists for the derived subtype; the only difference is that for a range constraint,
     and likewise for a floating or fixed point constraint that includes a range constraint, the value of each
     bound is replaced by the corresponding value of the derived type.  The characteristics of the derived
     type are defined as follows:

        - The derived type belongs to the same class of types as the parent type.  The set of possible
          values for the derived type is a copy of the set of possible values for the parent type.  If
          the parent type is composite, then the same components exist for the derived type, and the
          subtype of corresponding components is the same.

        - For each basic operation of the parent type, there is a corresponding basic operation of the
          derived type.  Explicit type conversion of a value of the parent type into the corresponding
          value of the derived type is allowed and vice versa as explained in section 4.6.

        - For each enumeration literal or predefined operator of the parent type there is a corresponding
          operation for the derived type.

        - If the parent type is a task type, then for each entry of the parent type there is a
          corresponding entry for the derived type.

        - If a default expression exists for a component of an object having the parent type, then the
          same default expression is used for the corresponding component of an object having the derived
          type.

        - If the parent type is an access type, then the parent and the derived type share the same
          collection; there is a null access value for the derived type and it is the default initial
          value of that type.

        - If an explicit representation clause exists for the parent type and if this clause appears
          before the derived type definition, then there is a corresponding representation clause (an
          implicit one) for the derived type.

        - Certain subprograms that are operations of the parent type are said to be 6derivable.0 For
          each derivable subprogram of the parent type, there is a corresponding derived subprogram for
          the derived type.  Two kinds of derivable subprograms exist.  First, if the parent type is
          declared immediately within the visible part of a package, then a subprogram that is itself
          explicitly declared immediately within the visible part becomes derivable after the end of the
          visible part, if it is an operation of the parent type.  (The explicit declaration is by a
          subprogram declaration, a renaming declaration, or a generic instantiation.)  Second, if the
          parent type is itself a derived type, then any subprogram that has been derived by this parent
          type is further derivable, unless the parent type is declared in the visible part of a package
          and the derived subprogram is hidden by a derivable subprogram of the first kind.

     Each operation of the derived type is implicitly declared at the place of the derived type declaration.
     The implicit declarations of any derived subprograms occur last.

     The specification of a derived subprogram is obtained implicitly by systematic replacement of the parent
     type by the derived type in the specification of the derivable subprogram.  Any subtype of the parent
     type is likewise replaced by a subtype of the derived type with a similar constraint (as for the
     transformation of a constraint of the parent subtype into the corresponding constraint of the derived
     subtype).  Finally, any expression of the parent type is made to be the operand of a type conversion that
     yields a result of the derived type.

     Calling a derived subprogram is equivalent to calling the corresponding subprogram of the parent type, in
     which each actual parameter that is of the derived type is replaced by a type conversion of this actual
     parameter to the parent type (this means that a conversion to the parent type happens before the call for
     the modes 1in0 and 1in0 1out;0 a reverse conversion to the derived type happens after the call for
     the modes 1in0 1out0 and 1out,0 see 6.4.1).  In addition, if the result of a called function is of
     the parent type, this result is converted to the derived type.

     If a derived or private type is declared immediately within the visible part of a package, then, within
     this visible part, this type must not be used as the parent type of a derived type definition.  (For
     private types, see also section 7.4.1.)

     For the elaboration of a derived type definition, the subtype indication is first elaborated, the derived
     type is then created, and finally, the derived subtype is created.

     6Examples:

0         1type0 LOCAL_COORDINATE 1is0 1new0 COORDINATE;    --  two different types
         1type0 MIDWEEK 1is new0 DAY 1range0 TUE .. THU;   --  see 3.5.1
         1type0 COUNTER 1is0 1new0 POSITIVE;               --  same range as POSITIVE

         1type0 SPECIAL_KEY 1is0 1new0 KEY_MANAGER.KEY;    --  see 7.4.2
         -- the derived subprograms have the following specifications:

         -- 1procedure0 GET_KEY(K : 1out0 SPECIAL_KEY);
         -- 1function0 "<"(X,Y : SPECIAL_KEY) 1return0 BOOLEAN;

     6Notes:

0     The rules of derivation of basic operations and enumeration literals imply that the notation for any
     literal or aggregate of the derived type is the same as for the parent type; such literals and aggregates
     are said to be 6overloaded.0 Similarly, it follows that the notation for denoting a component, a
     discriminant, an entry, a slice, or an attribute is the same for the derived type as for the parent type.

     Hiding of a derived subprogram is allowed even within the same declarative region (see 8.3).  A derived
     subprogram hides a predefined operator that has the same parameter and result type profile (see 6.6).

     A generic subprogram declaration is not derivable since it declares a generic unit rather than a
     subprogram.  On the other hand, an instantiation of a generic subprogram is a (nongeneric) subprogram,
     which is derivable if it satisfies the requirements for derivability of subprograms.

     If the parent type is a boolean type, the predefined relational operators of the derived type deliver a
     result of the predefined type BOOLEAN (see 4.5.2).

     If a representation clause is given for the parent type but appears after the derived type declaration,
     then no corresponding representation clause applies to the derived type; hence an explicit representation
     clause for such a derived type is allowed.

     For a derived subprogram, if a parameter belongs to the derived type, the subtype of this parameter need
     not have any value in common with the derived subtype.

     6References:0 4 access value 3.8, actual parameter 6.4.1, aggregate 4.3, attribute 4.1.4, base type
     3.3, basic operation 3.3.3, boolean type 3.5.3, bound of a range 3.5, class of type 3.3, collection 3.8,
     component 3.3, composite type 3.3, constraint 3.3, conversion 4.6, declaration 3.1, declarative region
     8.1, default expression 3.2.1, default initial value for an access type 3.8, discriminant 3.3,
     elaboration 3.9, entry 9.5, enumeration literal 3.5.1, floating point constraint 3.5.7, fixed point
     constraint 3.5.9, formal parameter 6.1, function call 6.4, generic declaration 12.1, immediately within
     8.1, implicit declaration 3.1, literal 4.2, mode 6.1, overloading 6.6 8.7, package 7, package
     specification 7.1, parameter association 6.4, predefined operator 4.5, private type 7.4, procedure 6,
     procedure call statement 6.4, range constraint 3.5, representation clause 13.1, reserved word 2.9, slice
     4.1.2, subprogram 6, subprogram specification 6.1, subtype indication 3.3.2, subtype 3.3, type 3.3, type
     definition 3.3.1, visible part 7.2 0

      section lrm-section3-5

     23.5. Scalar Types

0     Scalar types comprise enumeration types, integer types, and real types.  Enumeration types and integer
     types are called 6discrete0 types; each value of a discrete type has a position number which is an
     integer value.  Integer types and real types are called 6numeric0 types.  All scalar types are ordered,
     that is, all relational operators are predefined for their values.

         range_constraint ::=  1range0 range

         range ::=  6range0_attribute
            | simple_expression .. simple_expression

     A range specifies a subset of values of a scalar type.  The range L .. R specifies the values from L to R
     inclusive if the relation L <= R is true.  The values L and R are called the 6lower0 6bound0 and
     6upper0 6bound0 of the range, respectively.  A value V is said to 6satisfy0 a range constraint if
     it belongs to the range; the value V is said to 6belong0 to the range if the relations L <= V and V <=
     R are both TRUE.  A 6null0 range is a range for which the relation R < L is TRUE; no value belongs to a
     null range.  The operators <= and < in the above definitions are the predefined operators of the scalar
     type.

     If a range constraint is used in a subtype indication, either directly or as part of a floating or fixed
     point constraint, the type of the simple expressions (likewise, of the bounds of a range attribute) must
     be the same as the base type of the type mark of the subtype indication.  A range constraint is
     6compatible0 with a subtype if each bound of the range belongs to the subtype, or if the range
     constraint defines a null range; otherwise the range constraint is not compatible with the subtype.

     The elaboration of a range constraint consists of the evaluation of the range.  The evaluation of a range
     defines its lower bound and its upper bound.  If simple expressions are given to specify the bounds, the
     evaluation of the range evaluates these simple expressions in some order that is not defined by the
     language.

     6Attributes

0     For any scalar type T or for any subtype T of a scalar type, the following attributes are defined:

     T'FIRST             Yields the lower bound of T. The value of this attribute has the same type as T.

     T'LAST              Yields the upper bound of T. The value of this attribute has the same type as T.

     6Note:

0     Indexing and iteration rules use values of discrete types.

     6References:0 4 attribute 4.1.4, constraint 3.3, enumeration type 3.5.1, erroneous 1.6, evaluation
     4.5, fixed point constraint 3.5.9, floating point constraint 3.5.7, index 3.6, integer type 3.5.4, loop
     statement 5.5, range attribute 3.6.2, real type 3.5.6, relational operator 4.5 4.5.2, satisfy a
     constraint 3.3, simple expression 4.4, subtype indication 3.3.2, type mark 3.3.20

      subsection lrm-section3-5-1



     73.5.1. Enumeration Types

0     An enumeration type definition defines an enumeration type.

         enumeration_type_definition ::=
            (enumeration_literal_specification {, enumeration_literal_specification})

         enumeration_literal_specification ::=  enumeration_literal

         enumeration_literal ::=  identifier | character_literal

     The identifiers and character literals listed by an enumeration type definition must be distinct.  Each
     enumeration literal specification is the declaration of the corresponding enumeration literal:  this
     declaration is equivalent to the declaration of a parameterless function, the designator being the
     enumeration literal, and the result type being the enumeration type.  The elaboration of an enumeration
     type definition creates an enumeration type; this elaboration includes that of every enumeration literal
     specification.

     Each enumeration literal yields a different enumeration value.  The predefined order relations between
     enumeration values follow the order of corresponding position numbers.  The position number of the value
     of the first listed enumeration literal is zero; the position number for each other enumeration literal
     is one more than for its predecessor in the list.

     If the same identifier or character literal is specified in more than one enumeration type definition,
     the corresponding literals are said to be 6overloaded.0 At any place where an overloaded enumeration
     literal occurs in the text of a program, the type of the enumeration literal must be determinable from
     the context (see 8.7).

     6Examples:

0         1type0 DAY           1is0 (MON, TUE, WED, THU, FRI, SAT, SUN);
         1type0 SUIT          1is0 (CLUBS, DIAMONDS, HEARTS, SPADES);
         1type0 GENDER      1is0 (M, F);
         1type0 LEVEL        1is0 (LOW, MEDIUM, URGENT);
         1type0 COLOR       1is0 (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
         1type0 LIGHT         1is0 (RED, AMBER, GREEN);  -- RED and GREEN are overloaded

         1type0 HEXA         1is0 ('A', 'B', 'C', 'D', 'E', 'F');
         1type0 MIXED        1is0 ('A', 'B', '*', B, NONE, '?', '%');

         1subtype0 WEEKDAY    1is0 DAY      1range0 MON .. FRI;
         1subtype0 MAJOR        1is0 SUIT     1range0 HEARTS .. SPADES;
         1subtype0 RAINBOW     1is0 COLOR    1range0 RED .. BLUE;  6--  the color RED, not the lig

     Note:

0     If an enumeration literal occurs in a context that does not otherwise suffice to determine the type of
     the literal, then qualification by the name of the enumeration type is one way to resolve the ambiguity
     (see 8.7).

     6References:0 4 character literal 2.5, declaration 3.1, designator 6.1, elaboration 3.9, 6.1, function
     6.5, identifier 2.3, name 4.1, overloading 6.6 8.7, position number 3.5, qualified expression 4.7,
     relational operator 4.5 4.5.2, type 3.3, type definition 3.3.10

      subsection lrm-section3-5-2



     73.5.2. Character Types

0     An enumeration type is said to be a character type if at least one of its enumeration literals is a
     character literal.  The predefined type CHARACTER is a character type whose values are the 128 characters
     of the 6ASCII0 character set.  Each of the 95 graphic characters of this character set is denoted by
     the corresponding character literal.

     6Example:

0         1type0 ROMAN_DIGIT 1is0 ('I', 'V', 'X', 'L', 'C', 'D', 'M');

     6Notes:

0     The predefined package ASCII includes the declaration of constants denoting control characters and of
     constants denoting graphic characters that are not in the basic character set.

     A conventional character set such as 6EBCDIC0 can be declared as a character type; the internal codes
     of the characters can be specified by an enumeration representation clause as explained in section 13.3.

     6References:0 4 ascii predefined package C, basic character 2.1, character literal 2.5, constant
     3.2.1, declaration 3.1, enumeration type 3.5.1, graphic character 2.1, identifier 2.3, literal 4.2,
     predefined type C, type 3.30

      subsection lrm-section3-5-3



     73.5.3. Boolean Types

0     There is a predefined enumeration type named BOOLEAN.  It contains the two literals FALSE and TRUE
     ordered with the relation FALSE < TRUE.  A boolean type is either the type BOOLEAN or a type that is
     derived, directly or indirectly, from a boolean type.

     6References:0 4 derived type 3.4, enumeration literal 3.5.1, enumeration type 3.5.1, relational
     operator 4.5 4.5.2, type 3.30

      subsection lrm-section3-5-4



     73.5.4. Integer Types

0     An integer type definition defines an integer type whose set of values includes at least those of the
     specified range.

         integer_type_definition ::=  range_constraint

     If a range constraint is used as an integer type definition, each bound of the range must be defined by a
     static expression of some integer type, but the two bounds need not have the same integer type.
     (Negative bounds are allowed.)

     A type declaration of the form:

         1type0 T 1is0 1range0 L .. R;

     is, by definition, equivalent to the following declarations:

         1type0 6integer_type0 1is0 1new0 predefined_integer_type;
         1subtype0 T 1is0 6integer_type0 1range0 6integer_type(L)0 .. 6integer_type(R);

0     where 6integer_type0 is an anonymous type, and where the predefined integer type is implicitly selected
     by the implementation, so as to contain the values L to R inclusive.  The integer type declaration is
     illegal if none of the predefined integer types satisfies this requirement, excepting
     6universal_integer.0 The elaboration of the declaration of an integer type consists of the elaboration
     of the equivalent type and subtype declarations.

     The predefined integer types include the type INTEGER.  An implementation may also have predefined types
     such as SHORT_INTEGER and LONG_INTEGER, which have (substantially) shorter and longer ranges,
     respectively, than INTEGER.  The range of each of these types must be symmetric about zero, excepting an
     extra negative value which may exist in some implementations.  The base type of each of these types is
     the type itself.

     Integer literals are the literals of an anonymous predefined integer type that is called
     6universal_integer0 in this reference manual.  Other integer types have no literals.  However, for each
     integer type there exists an implicit conversion that converts a 6universal_integer0 value into the
     corresponding value (if any) of the integer type.  The circumstances under which these implicit
     conversions are invoked are described in section 4.6.

     The position number of an integer value is the corresponding value of the type 6universal_integer.

0     The same arithmetic operators are predefined for all integer types (see 4.5).  The exception
     NUMERIC_ERROR is raised by the execution of an operation (in particular an implicit conversion) that
     cannot deliver the correct result (that is, if the value corresponding to the mathematical result is not
     a value of the integer type).  However, an implementation is not required to raise the exception
     NUMERIC_ERROR if the operation is part of a larger expression whose result can be computed correctly, as
     described in section 11.6.

     6Examples:

0         1type0 PAGE_NUM    1is0 1range0 1 .. 2_000;
         1type0 LINE_SIZE   1is0 1range0 1 .. MAX_LINE_SIZE;

         1subtype0 SMALL_INT       1is0 INTEGER    1range0 -10 .. 10;
         1subtype0 COLUMN_PTR      1is0 LINE_SIZE  1range0 1 .. 10;
         1subtype0 BUFFER_SIZE     1is0 INTEGER    1range0 0 .. MAX;

     6Notes:

0     The name declared by an integer type declaration is a subtype name.  On the other hand, the predefined
     operators of an integer type deliver results whose range is defined by the parent predefined type; such a
     result need not belong to the declared subtype, in which case an attempt to assign the result to a
     variable of the integer subtype raises the exception CONSTRAINT_ERROR.

     The smallest (most negative) value supported by the predefined integer types of an implementation is the
     named number SYSTEM.MIN_INT and the largest (most positive) value is SYSTEM.MAX_INT (see 13.7).

     6References:0 4 anonymous type 3.3.1, belong to a subtype 3.3, bound of a range 3.5, constraint_error
     exception 11.1, conversion 4.6, identifier 2.3, integer literal 2.4, literal 4.2, numeric_error exception
     11.1, parent type 3.4, predefined operator 4.5, range constraint 3.5, static expression 4.9, subtype
     declaration 3.3.2, system predefined package 13.7, type 3.3, type declaration 3.3.1, type definition
     3.3.1, universal type 4.100

      subsection lrm-section3-5-5



     73.5.5. Operations of Discrete Types

0     The basic operations of a discrete type include the operations involved in assignment, the membership
     tests, and qualification; for a boolean type they include the short-circuit control forms; for an integer
     type they include the explicit conversion of values of other numeric types to the integer type, and the
     implicit conversion of values of the type 6universal_integer0 to the type.

     Finally, for every discrete type or subtype T, the basic operations include the attributes listed below.
     In this presentation, T is referred to as being a subtype (the subtype T) for any property that depends
     on constraints imposed by T; other properties are stated in terms of the base type of T.

     The first group of attributes yield characteristics of the subtype T. This group includes the attribute
     BASE (see 3.3.2), the attributes FIRST and LAST (see 3.5), the representation attribute SIZE (see
     13.7.2), and the attribute WIDTH defined as follows:

     T'WIDTH             Yields the maximum image length over all values of the subtype T (the 6image0 is
                         the sequence of characters returned by the attribute IMAGE, see below).  Yields zero
                         for a null range.  The value of this attribute is of the type 6universal_integer.

0     All attributes of the second group are functions with a single parameter.  The corresponding actual
     parameter is indicated below by X.

     T'POS               This attribute is a function.  The parameter X must be a value of the base type of
                         T. The result type is the type 6universal_integer.0 The result is the position
                         number of the value of the parameter.

     T'VAL               This attribute is a special function with a single parameter which can be of any
                         integer type.  The result type is the base type of T. The result is the value whose
                         position number is the 6universal_integer0 value corresponding to X. The exception
                         CONSTRAINT_ERROR is raised if the 6universal_integer0 value corresponding to X is
                         not in the range T'POS(T'BASE'FIRST) .. T'POS(T'BASE'LAST).

     T'SUCC              This attribute is a function.  The parameter X must be a value of the base type of
                         T. The result type is the base type of T. The result is the value whose position
                         number is one greater than that of X. The exception CONSTRAINT_ERROR is raised if X
                         equals T'BASE'LAST.

     T'PRED              This attribute is a function.  The parameter X must be a value of the base type of
                         T. The result type is the base type of T. The result is the value whose position
                         number is one less than that of X. The exception CONSTRAINT_ERROR is raised if X
                         equals T'BASE'FIRST.

     T'IMAGE             This attribute is a function.  The parameter X must be a value of the base type of
                         T. The result type is the predefined type STRING.  The result is the 6image0 of the
                         value of X, that is, a sequence of characters representing the value in display form.
                         The image of an integer value is the corresponding decimal literal; without
                         underlines, leading zeros, exponent, or trailing spaces; but with a single leading
                         character that is either a minus sign or a space.  The lower bound of the image is
                         one.

                         The image of an enumeration value is either the corresponding identifier in upper
                         case or the corresponding character literal (including the two apostrophes); neither
                         leading nor trailing spaces are included.  The image of a character C, other than a
                         graphic character, is implementation-defined; the only requirement is that the image
                         must be such that C equals CHARACTER'VALUE(CHARACTER'IMAGE(C)).

     T'VALUE             This attribute is a function.  The parameter X must be a value of the predefined type
                         STRING.  The result type is the base type of T. Any leading and any trailing spaces
                         of the sequence of characters that corresponds to the parameter are ignored.

                         For an enumeration type, if the sequence of characters has the syntax of an
                         enumeration literal and if this literal exists for the base type of T, the result is
                         the corresponding enumeration value.  For an integer type, if the sequence of
                         characters has the syntax of an integer literal, with an optional single leading
                         character that is a plus or minus sign, and if there is a corresponding value in the
                         base type of T, the result is this value.  In any other case, the exception
                         CONSTRAINT_ERROR is raised.

     In addition, the attributes A'SIZE and A'ADDRESS are defined for an object A of a discrete type (see
     13.7.2).

     Besides the basic operations, the operations of a discrete type include the predefined relational
     operators.  For enumeration types, operations include enumeration literals.  For boolean types,
     operations include the predefined unary logical negation operator 1not,0 and the predefined logical
     operators.  For integer types, operations include the predefined 6arithmetic0 operators:  these are the
     binary and unary adding operators - and +, all multiplying operators, the unary operator 1abs,0 and the
     exponentiating operator.

     The operations of a subtype are the corresponding operations of its base type except for the following:
     assignment, membership tests, qualification, explicit type conversions, and the attributes of the first
     group; the effect of each of these operations depends on the subtype (assignments, membership tests,
     qualifications, and conversions involve a subtype check; attributes of the first group yield a
     characteristic of the subtype).

     6Notes:

0     For a subtype of a discrete type, the results delivered by the attributes SUCC, PRED, VAL, and VALUE need
     not belong to the subtype; similarly, the actual parameters of the attributes POS, SUCC, PRED, and IMAGE
     need not belong to the subtype.  The following relations are satisfied (in the absence of an exception)
     by these attributes:

         T'POS(T'SUCC(X))   = T'POS(X)  +  1
         T'POS(T'PRED(X))   = T'POS(X)  -  1

         T'VAL(T'POS(X))    = X
         T'POS(T'VAL(N))    = N

     6Examples:

0         --  For the types and subtypes declared in section 3.5.1 we have:

         --  COLOR'FIRST       = WHITE,      COLOR'LAST      = BLACK
         --  RAINBOW'FIRST     = RED,        RAINBOW'LAST    = BLUE

         --  COLOR'SUCC(BLUE)  = RAINBOW'SUCC(BLUE) = BROWN
         --  COLOR'POS(BLUE)   = RAINBOW'POS(BLUE)  = 4
         --  COLOR'VAL(0)      = RAINBOW'VAL(0)     = WHITE

     6References:0 4 abs operator 4.5 4.5.6, assignment 5.2, attribute 4.1.4, base type 3.3, basic
     operation 3.3.3, binary adding operator 4.5 4.5.3, boolean type 3.5.3, bound of a range 3.5, character
     literal 2.5, constraint 3.3, constraint_error exception 11.1, conversion 4.6, discrete type 3.5,
     enumeration literal 3.5.1, exponentiating operator 4.5 4.5.6, function 6.5, graphic character 2.1,
     identifier 2.3, integer type 3.5.4, logical operator 4.5 4.5.1, membership test 4.5 4.5.2, multiplying
     operator 4.5 4.5.5, not operator 4.5 4.5.6, numeric literal 2.4, numeric type 3.5, object 3.2, operation
     3.3, position number 3.5, predefined operator 4.5, predefined type C, qualified expression 4.7,
     relational operator 4.5 4.5.2, short-circuit control form 4.5 4.5.1, string type 3.6.3, subtype 3.3, type
     3.3, unary adding operator 4.5 4.5.4, universal_integer type 3.5.4, universal type 4.100

      subsection lrm-section3-5-6



     73.5.6. Real Types

0     Real types provide approximations to the real numbers, with relative bounds on errors for floating point
     types, and with absolute bounds for fixed point types.

         real_type_definition ::=
            floating_point_constraint | fixed_point_constraint

     A set of numbers called 6model0 6numbers0 is associated with each real type.  Error bounds on the
     predefined operations are given in terms of the model numbers.  An implementation of the type must
     include at least these model numbers and represent them exactly.

     An implementation-dependent set of numbers, called the 6safe0 6numbers,0 is also associated with each
     real type.  The set of safe numbers of a real type must include at least the set of model numbers of the
     type.  The range of safe numbers is allowed to be larger than the range of model numbers, but error
     bounds on the predefined operations for safe numbers are given by the same rules as for model numbers.
     Safe numbers therefore provide guaranteed error bounds for operations on an implementation-dependent
     range of numbers; in contrast, the range of model numbers depends only on the real type definition and is
     therefore independent of the implementation.

     Real literals are the literals of an anonymous predefined real type that is called 6universal_real0 in
     this reference manual.  Other real types have no literals.  However, for each real type, there exists an
     implicit conversion that converts a 6universal_real0 value into a value of the real type.  The
     conditions under which these implicit conversions are invoked are described in section 4.6.  If the
     6universal_real0 value is a safe number, the implicit conversion delivers the corresponding value; if
     it belongs to the range of safe numbers but is not a safe number, then the converted value can be any
     value within the range defined by the safe numbers next above and below the 6universal_real0 value.

     The execution of an operation that yields a value of a real type may raise the exception NUMERIC_ERROR,
     as explained in section 4.5.7, if it cannot deliver a correct result (that is, if the value corresponding
     to one of the possible mathematical results does not belong to the range of safe numbers); in particular,
     this exception can be raised by an implicit conversion.  However, an implementation is not required to
     raise the exception NUMERIC_ERROR if the operation is part of a larger expression whose result can be
     computed correctly (see 11.6).

     The elaboration of a real type definition includes the elaboration of the floating or fixed point
     constraint and creates a real type.

     6Note:

0     An algorithm written to rely only upon the minimum numerical properties guaranteed by the type definition
     for model numbers will be portable without further precautions.

     6References:0 4 conversion 4.6, elaboration 3.9, fixed point constraint 3.5.9, floating point
     constraint 3.5.7, literal 4.2, numeric_error exception 11.1, predefined operation 3.3.3, real literal
     2.4, type 3.3, type definition 3.3.1, universal type 4.100

      subsection lrm-section3-5-7



     73.5.7. Floating Point Types

0     For floating point types, the error bound is specified as a relative precision by giving the required
     minimum number of significant decimal digits.

         floating_point_constraint ::=
            floating_accuracy_definition [range_constraint]

         floating_accuracy_definition ::=  1digits0 6static0_simple_expression

     The minimum number of significant decimal digits is specified by the value of the static simple
     expression of the floating accuracy definition.  This value must belong to some integer type and must be
     positive (nonzero); it is denoted by D in the remainder of this section.  If the floating point
     constraint is used as a real type definition and includes a range constraint, then each bound of the
     range must be defined by a static expression of some real type, but the two bounds need not have the same
     real type.

     For a given 6radix,0 the following canonical form is defined for any floating point model number other
     than zero:

         6sign0 * 6mantissa0 * (6radix0 ** 6exponent)

0     In this form: 6sign0 is either +1 or -1; 6mantissa0 is expressed in a number base given by 6radix;
0     and 6exponent0 is an integer number (possibly negative) such that the integer part of mantissa is zero
     and the first digit of its fractional part is not a zero.

     The specified number D is the minimum number of decimal digits required after the point in the decimal
     mantissa (that is, if 6radix0 is ten).  The value of D in turn determines a corresponding number B that
     is the minimum number of binary digits required after the point in the binary mantissa (that is, if
     6radix0 is two).  The number B associated with D is the smallest value such that the relative precision
     of the binary form is no less than that specified for the decimal form.  (The number B is the integer
     next above (D*log(10)/log(2)) + 1.)

     The model numbers defined by a floating accuracy definition comprise zero and all numbers whose binary
     canonical form has exactly B digits after the point in the mantissa and an exponent in the range -4*B ..
     +4*B.  The guaranteed minimum accuracy of operations of a floating point type is defined in terms of the
     model numbers of the floating point constraint that forms the corresponding real type definition (see
     4.5.7).

     The predefined floating point types include the type FLOAT.  An implementation may also have predefined
     types such as SHORT_FLOAT and LONG_FLOAT, which have (substantially) less and more accuracy,
     respectively, than FLOAT.  The base type of each predefined floating point type is the type itself.  The
     model numbers of each predefined floating point type are defined in terms of the number D of decimal
     digits returned by the attribute DIGITS (see 3.5.8).

     For each predefined floating point type (consequently also for each type derived therefrom), a set of
     safe numbers is defined as follows.  The safe numbers have the same number B of mantissa digits as the
     model numbers of the type and have an exponent in the range -E .. +E where E is implementation-defined
     and at least equal to the 4*B of model numbers.  (Consequently, the safe numbers include the model
     numbers.)  The rules defining the accuracy of operations with model and safe numbers are given in section
     4.5.7.  The safe numbers of a subtype are those of its base type.

     A floating point type declaration of one of the two forms (that is, with or without the optional range
     constraint indicated by the square brackets):

         1type0 T 1is0 1digits0 D [1range0 L .. R];

     is, by definition, equivalent to the following declarations:
         1type0 6floating_point_type0 1is0 1new0 predefined_floating_point_type;
         1subtype0 T 1is0 6floating_point_type0 1digits0 D
            [1range0 6floating_point_type(L)0 .. 6floating_point_type(R)0;]

     where 6floating_point_type0 is an anonymous type, and where the predefined floating point type is
     implicitly selected by the implementation so that its model numbers include the model numbers defined by
     D; furthermore, if a range L .. R is supplied, then both L and R must belong to the range of safe
     numbers.  The floating point declaration is illegal if none of the predefined floating point types
     satisfies these requirements, excepting 6universal_real.0 The maximum number of digits that can be
     specified in a floating accuracy definition is given by the system-dependent named number
     SYSTEM.MAX_DIGITS (see 13.7.1).

     The elaboration of a floating point type declaration consists of the elaboration of the equivalent type
     and subtype declarations.

     If a floating point constraint follows a type mark in a subtype indication, the type mark must denote a
     floating point type or subtype.  The floating point constraint is 6compatible0 with the type mark only
     if the number D specified in the floating accuracy definition is not greater than the corresponding
     number D for the type or subtype denoted by the type mark.  Furthermore, if the floating point constraint
     includes a range constraint, the floating point constraint is compatible with the type mark only if the
     range constraint is, itself, compatible with the type mark.

     The elaboration of such a subtype indication includes the elaboration of the range constraint, if there
     is one; it creates a floating point subtype whose model numbers are defined by the corresponding floating
     accuracy definition.  A value of a floating point type belongs to a floating point subtype if and only if
     it belongs to the range defined by the subtype.

     The same arithmetic operators are predefined for all floating point types (see 4.5).

     6Notes:

0     A range constraint is allowed in a floating point subtype indication, either directly after the type
     mark, or as part of a floating point constraint.  In either case the bounds of the range must belong to
     the base type of the type mark (see 3.5).  The imposition of a floating point constraint on a type mark
     in a subtype indication cannot reduce the allowed range of values unless it includes a range constraint
     (the range of model numbers that correspond to the specified number of digits can be smaller than the
     range of numbers of the type mark).  A value that belongs to a floating point subtype need not be a model
     number of the subtype.

     6Examples:

0         1type0 COEFFICIENT 1is0 1digits0 10 1range0 -1.0 .. 1.0;

         1type0 REAL  1is0 1digits0 8;
         1type0 MASS  1is0 1digits0 7 1range0 0.0 .. 1.0E35;

         1subtype0 SHORT_COEFF  1is0 COEFFICIENT 1digits0 5;    --   A subtype with less accuracy
         1subtype0 PROBABILITY  1is0 REAL 1range0 0.0 .. 1.0;   --   A subtype with a smaller range


     6Notes0 6on0 6the0 6examples:

0     The implemented accuracy for COEFFICIENT is that of a predefined type having at least 10 digits of
     precision.  Consequently the specification of 5 digits of precision for the subtype SHORT_COEFF is
     allowed.  The largest model number for the type MASS is approximately 1.27E30 and hence less than the
     specified upper bound (1.0E35).  Consequently the declaration of this type is legal only if this upper
     bound is in the range of the safe numbers of a predefined floating point type having at least 7 digits of
     precision.

     6References:0 4 anonymous type 3.3.1, arithmetic operator 3.5.5 4.5, based literal 2.4.2, belong to a
     subtype 3.3, bound of a range 3.5, compatible 3.3.2, derived type 3.4, digit 2.1, elaboration 3.1 3.9,
     error bound 3.5.6, exponent 2.4.1 integer type 3.5.4, model number 3.5.6, operation 3.3, predefined
     operator 4.5, predefined type C, range constraint 3.5, real type 3.5.6, real type definition 3.5.6, safe
     number 3.5.6, simple expression 4.4, static expression 4.9, subtype declaration 3.3.2, subtype indication
     3.3.2, subtype 3.3, type 3.3, type declaration 3.3.1, type mark 3.3.20

      subsection lrm-section3-5-8



     73.5.8. Operations of Floating Point Types

0     The basic operations of a floating point type include the operations involved in assignment, membership
     tests, qualification, the explicit conversion of values of other numeric types to the floating point
     type, and the implicit conversion of values of the type 6universal_real0 to the type.

     In addition, for every floating point type or subtype T, the basic operations include the attributes
     listed below.  In this presentation, T is referred to as being a subtype (the subtype T) for any property
     that depends on constraints imposed by T; other properties are stated in terms of the base type of T.

     The first group of attributes yield characteristics of the subtype T. The attributes of this group are
     the attribute BASE (see 3.3.2), the attributes FIRST and LAST (see 3.5), the representation attribute
     SIZE (see 13.7.2), and the following attributes:

     T'DIGITS            Yields the number of decimal digits in the decimal mantissa of model numbers of the
                         subtype T. (This attribute yields the number D of section 3.5.7.)  The value of this
                         attribute is of the type 6universal_integer.

0     T'MANTISSA          Yields the number of binary digits in the binary mantissa of model numbers of the
                         subtype T. (This attribute yields the number B of section 3.5.7.)  The value of this
                         attribute is of the type 6universal_integer.

0     T'EPSILON           Yields the absolute value of the difference between the model number 1.0 and the next
                         model number above, for the subtype T. The value of this attribute is of the type
                         6universal_real.

0     T'EMAX              Yields the largest exponent value in the binary canonical form of model numbers of
                         the subtype T. (This attribute yields the product 4*B of section 3.5.7.)  The value
                         of this attribute is of the type 6universal_integer.

0     T'SMALL             Yields the smallest positive (nonzero) model number of the subtype T. The value of
                         this attribute is of the type 6universal_real.

0     T'LARGE             Yields the largest positive model number of the subtype T. The value of this
                         attribute is of the type 6universal_real.

0     The attributes of the second group include the following attributes which yield characteristics of the
     safe numbers:

     T'SAFE_EMAX         Yields the largest exponent value in the binary canonical form of safe numbers of the
                         base type of T. (This attribute yields the number E of section 3.5.7.)  The value of
                         this attribute is of the type 6universal_integer.

0     T'SAFE_SMALL        Yields the smallest positive (nonzero) safe number of the base type of T. The value
                         of this attribute is of the type 6universal_real.

0     T'SAFE_LARGE        Yields the largest positive safe number of the base type of T. The value of this
                         attribute is of the type 6universal_real.

0     In addition, the attributes A'SIZE and A'ADDRESS are defined for an object A of a floating point type
     (see 13.7.2).  Finally, for each floating point type there are machine-dependent attributes that are not
     related to model numbers and safe numbers.  They correspond to the attribute designators MACHINE_RADIX,
     MACHINE_MANTISSA, MACHINE_EMAX, MACHINE_EMIN, MACHINE_ROUNDS, and MACHINE_OVERFLOWS (see 13.7.3).

     Besides the basic operations, the operations of a floating point type include the relational operators,
     and the following predefined arithmetic operators:  the binary and unary adding operators - and +, the
     multiplying operators * and /, the unary operator 1abs,0 and the exponentiating operator.

     The operations of a subtype are the corresponding operations of the type except for the following:
     assignment, membership tests, qualification, explicit conversion, and the attributes of the first group;
     the effects of these operations are redefined in terms of the subtype.

     6Notes:

0     The attributes EMAX, SMALL, LARGE, and EPSILON are provided for convenience.  They are all related to
     MANTISSA by the following formulas:

         T'EMAX       = 4*T'MANTISSA
         T'EPSILON    = 2.0**(1 - T'MANTISSA)
         T'SMALL      = 2.0**(-T'EMAX - 1)
         T'LARGE      = 2.0**T'EMAX * (1.0 - 2.0**(-T'MANTISSA))

     The attribute MANTISSA, giving the number of binary digits in the mantissa, is itself related to DIGITS.
     The following relations hold between the characteristics of the model numbers and those of the safe
     numbers:

         T'BASE'EMAX  <=  T'SAFE_EMAX
         T'BASE'SMALL    >=  T'SAFE_SMALL
         T'BASE'LARGE    <=  T'SAFE_LARGE

     The attributes T'FIRST and T'LAST need not yield model or safe numbers.  If a certain number of digits is
     specified in the declaration of a type or subtype T, the attribute T'DIGITS yields this number.

     6References:0 4 abs operator 4.5 4.5.6, arithmetic operator 3.5.5 4.5, assignment 5.2, attribute
     4.1.4, base type 3.3, basic operation 3.3.3, binary adding operator 4.5 4.5.3, bound of a range 3.5,
     constraint 3.3, conversion 4.6, digit 2.1, exponentiating operator 4.5 4.5.6, floating point type 3.5.7,
     membership test 4.5 4.5.2, model number 3.5.6, multiplying operator 4.5 4.5.5, numeric type 3.5, object
     3.2, operation 3.3, predefined operator 4.5, qualified expression 4.7, relational operator 4.5 4.5.2,
     safe number 3.5.6, subtype 3.3, type 3.3, unary adding operator 4.5 4.5.4, universal type 4.10,
     universal_integer type 3.5.4, universal_real type 3.5.60

      subsection lrm-section3-5-9



     73.5.9. Fixed Point Types

0     For fixed point types, the error bound is specified as an absolute value, called the 6delta0 of the
     fixed point type.

         fixed_point_constraint ::=
            fixed_accuracy_definition [range_constraint]

         fixed_accuracy_definition ::=  1delta0 6static0_simple_expression

     The delta is specified by the value of the static simple expression of the fixed accuracy definition.
     This value must belong to some real type and must be positive (nonzero).  If the fixed point constraint
     is used as a real type definition, then it must include a range constraint; each bound of the specified
     range must be defined by a static expression of some real type but the two bounds need not have the same
     real type.  If the fixed point constraint is used in a subtype indication, the range constraint is
     optional.

     A canonical form is defined for any fixed point model number other than zero.  In this form:  6sign0 is
     either +1 or -1; 6mantissa0 is a positive (nonzero) integer; and any model number is a multiple of a
     certain positive real number called 6small,0 as follows:

         6sign0 * 6mantissa0 * 6small

0     For the model numbers defined by a fixed point constraint, the number 6small0 is chosen as the largest
     power of two that is not greater than the delta of the fixed accuracy definition.  Alternatively, it is
     possible to specify the value of 6small0 by a length clause (see 13.2), in which case model numbers are
     multiples of the specified value.  The guaranteed minimum accuracy of operations of a fixed point type is
     defined in terms of the model numbers of the fixed point constraint that forms the corresponding real
     type definition (see 4.5.7).

     For a fixed point constraint that includes a range constraint, the model numbers comprise zero and all
     multiples of 6small0 whose 6mantissa0 can be expressed using exactly B binary digits, where the value
     of B is chosen as the smallest integer number for which each bound of the specified range is either a
     model number or lies at most 6small0 distant from a model number.  For a fixed point constraint that
     does not include a range constraint (this is only allowed after a type mark, in a subtype indication),
     the model numbers are defined by the delta of the fixed accuracy definition and by the range of the
     subtype denoted by the type mark.

     An implementation must have at least one anonymous predefined fixed point type.  The base type of each
     such fixed point type is the type itself.  The model numbers of each predefined fixed point type comprise
     zero and all numbers for which 6mantissa0 (in the canonical form) has the number of binary digits
     returned by the attribute MANTISSA, and for which the number 6small0 has the value returned by the
     attribute SMALL.

     A fixed point type declaration of the form:

         1type0 T 1is0 1delta0 D 1range0 L .. R;

     is, by definition, equivalent to the following declarations:

         1type0 6fixed_point_type0 1is0 1new0 predefined_fixed_point_type;
         1subtype0 T 1is0 6fixed_point_type
0            1range0 6fixed_point_type(L)0 .. 6fixed_point_type(R);


0     In these declarations, 6fixed_point_type0 is an anonymous type, and the predefined fixed point type is
     implicitly selected by the implementation so that its model numbers include the model numbers defined by
     the fixed point constraint (that is, by D, L, and R, and possibly by a length clause specifying
     6small).

0     The fixed point declaration is illegal if no predefined type satisfies these requirements.  The safe
     numbers of a fixed point type are the model numbers of its base type.

     The elaboration of a fixed point type declaration consists of the elaboration of the equivalent type and
     subtype declarations.

     If the fixed point constraint follows a type mark in a subtype indication, the type mark must denote a
     fixed point type or subtype.  The fixed point constraint is 6compatible0 with the type mark only if the
     delta specified by the fixed accuracy definition is not smaller than the delta for the type or subtype
     denoted by the type mark.  Furthermore, if the fixed point constraint includes a range constraint, the
     fixed point constraint is compatible with the type mark only if the range constraint is, itself,
     compatible with the type mark.

     The elaboration of such a subtype indication includes the elaboration of the range constraint, if there
     is one; it creates a fixed point subtype whose model numbers are defined by the corresponding fixed point
     constraint and also by the length clause specifying small, if there is one.  A value of a fixed point
     type belongs to a fixed point subtype if and only if it belongs to the range defined by the subtype.

     The same arithmetic operators are predefined for all fixed point types (see 4.5).  Multiplication and
     division of fixed point values deliver results of an anonymous predefined fixed point type that is called
     6universal_fixed0 in this reference manual; the accuracy of this type is arbitrarily fine.  The values
     of this type must be converted explicitly to some numeric type.

     6Notes:

0     If S is a subtype of a fixed point type or subtype T, then the set of model numbers of S is a subset of
     those of T. If a length clause has been given for T, then both S and T have the same value for 6small.
0     Otherwise, since 6small0 is a power of two, the 6small0 of S is equal to the 6small0 of T
     multiplied by a nonnegative power of two.

     A range constraint is allowed in a fixed point subtype indication, either directly after the type mark,
     or as part of a fixed point constraint.  In either case the bounds of the range must belong to the base
     type of the type mark (see 3.5).

     6Examples:

0         1type0 VOLT 1is0 1delta0 0.125 1range0 0.0 .. 255.0;
         1subtype0 ROUGH_VOLTAGE 1is0 VOLT 1delta0 1.0;  --  same range as VOLT

         --  A pure fraction which requires all the available space in a word
         --  on a two's complement machine can be declared as the type FRACTION:

         DEL : 1constant0 := 1.0/2**(WORD_LENGTH - 1);
         1type0 FRACTION 1is0 1delta0 DEL 1range0 -1.0 .. 1.0 - DEL;

     6References:0 4 anonymous type 3.3.1, arithmetic operator 3.5.5 4.5, base type 3.3, belong to a
     subtype 3.3, bound of a range 3.5, compatible 3.3.2, conversion 4.6, elaboration 3.9, error bound 3.5.6,
     length clause 13.2, model number 3.5.6, numeric type 3.5, operation 3.3, predefined operator 4.5, range
     constraint 3.5, real type 3.5.6, real type definition 3.5.6, safe number 3.5.6, simple expression 4.4,
     static expression 4.9, subtype 3.3, subtype declaration 3.3.2, subtype indication 3.3.2, type 3.3, type
     declaration 3.3.1, type mark 3.3.20

      subsection lrm-section3-5-10



     73.5.10. Operations of Fixed Point Types

0     The basic operations of a fixed point type include the operations involved in assignment, membership
     tests, qualification, the explicit conversion of values of other numeric types to the fixed point type,
     and the implicit conversion of values of the type 6universal_real0 to the type.

     In addition, for every fixed point type or subtype T the basic operations include the attributes listed
     below.  In this presentation T is referred to as being a subtype (the subtype T) for any property that
     depends on constraints imposed by T; other properties are stated in terms of the base type of T.

     The first group of attributes yield characteristics of the subtype T. The attributes of this group are
     the attributes BASE (see 3.3.2), the attributes FIRST and LAST (see 3.5), the representation attribute
     SIZE (see 13.7.2) and the following attributes:

     T'DELTA             Yields the value of the delta specified in the fixed accuracy definition for the
                         subtype T. The value of this attribute is of the type 6universal_real.

0     T'MANTISSA          Yields the number of binary digits in the mantissa of model numbers of the subtype
                         T. (This attribute yields the number B of section 3.5.9.)  The value of this
                         attribute is of the type 6universal_integer.

0     T'SMALL             Yields the smallest positive (nonzero) model number of the subtype T. The value of
                         this attribute is of the type 6universal_real.

0     T'LARGE             Yields the largest positive model number of the subtype T. The value of this
                         attribute is of the type 6universal_real.

0     T'FORE              Yields the minimum number of characters needed for the integer part of the decimal
                         representation of any value of the subtype T, assuming that the representation does
                         not include an exponent, but includes a one-character prefix that is either a minus
                         sign or a space.  (This minimum number does not include superfluous zeros or
                         underlines, and is at least two.)  The value of this attribute is of the type
                         6universal_integer.

0     T'AFT               Yields the number of decimal digits needed after the point to accommodate the
                         precision of the subtype T, unless the delta of the subtype T is greater than 0.1, in
                         which case the attribute yields the value one.  (T'AFT is the smallest positive
                         integer N for which (10**N)*T'DELTA is greater than or equal to one.)  The value of
                         this attribute is of the type 6universal_integer.

0     The attributes of the second group include the following attributes which yield characteristics of the
     safe numbers:

     T'SAFE_SMALL        Yields the smallest positive (nonzero) safe number of the base type of T. The value
                         of this attribute is of the type 6universal_real.

0     T'SAFE_LARGE        Yields the largest positive safe number of the base type of T. The value of this
                         attribute is of the type 6universal_real.
0     In addition, the attributes A'SIZE and A'ADDRESS are defined for an object A of a fixed point type (see
     13.7.2).  Finally, for each fixed point type or subtype T, there are the machine-dependent attributes
     T'MACHINE_ROUNDS and T'MACHINE_OVERFLOWS (see 13.7.3).

     Besides the basic operations, the operations of a fixed point type include the relational operators, and
     the following predefined arithmetic operators:  the binary and unary adding operators - and +, the
     multiplying operators * and /, and the operator 1abs.

0     The operations of a subtype are the corresponding operations of the type except for the following:
     assignment, membership tests, qualification, explicit conversion, and the attributes of the first group;
     the effects of these operations are redefined in terms of the subtype.

     6Notes:

0     The value of the attribute T'FORE depends only on the range of the subtype T. The value of the attribute
     T'AFT depends only on the value of T'DELTA.  The following relations exist between attributes of a fixed
     point type:

         T'LARGE             = (2**T'MANTISSA - 1) * T'SMALL
         T'SAFE_LARGE        = T'BASE'LARGE
         T'SAFE_SMALL        = T'BASE'SMALL

     6References:0 4 abs operator 4.5 4.5.6, arithmetic operator 3.5.5 4.5, assignment 5.2, base type 3.3,
     basic operation 3.3.3, binary adding operator 4.5 4.5.3, bound of a range 3.5, conversion 4.6, delta
     3.5.9, fixed point type 3.5.9, membership test 4.5 4.5.2, model number 3.5.6, multiplying operator 4.5
     4.5.5, numeric type 3.5, object 3.2, operation 3.3, qualified expression 4.7, relational operator 4.5
     4.5.2, safe number 3.5.6, subtype 3.3, unary adding operator 4.5 4.5.4, universal_integer type 3.5.4,
     universal_real type 3.5.60

      section lrm-section3-6

     23.6. Array Types

0     An array object is a composite object consisting of components that have the same subtype.  The name for
     a component of an array uses one or more index values belonging to specified discrete types.  The value
     of an array object is a composite value consisting of the values of its components.

         array_type_definition ::=
            unconstrained_array_definition | constrained_array_definition

         unconstrained_array_definition ::=
            1array0(index_subtype_definition {, index_subtype_definition}) 1of
0                     6component0_subtype_indication

         constrained_array_definition ::=
            1array0 index_constraint 1of0 6component_0subtype_indication

         index_subtype_definition ::= type_mark 1range0 <>

         index_constraint   ::=  (discrete_range {, discrete_range})

         discrete_range ::= 6discrete_0subtype_indication | range

     An array object is characterized by the number of indices (the 6dimensionality0 of the array), the type
     and position of each index, the lower and upper bounds for each index, and the type and possible
     constraint of the components.  The order of the indices is significant.

     A one-dimensional array has a distinct component for each possible index value.  A multidimensional array
     has a distinct component for each possible sequence of index values that can be formed by selecting one
     value for each index position (in the given order).  The possible values for a given index are all the
     values between the lower and upper bounds, inclusive; this range of values is called the 6index
0     6range.

0     An unconstrained array definition defines an array type.  For each object that has the array type, the
     number of indices, the type and position of each index, and the subtype of the components are as in the
     type definition; the values of the lower and upper bounds for each index belong to the corresponding
     index subtype, except for null arrays as explained in section 3.6.1.  The 6index0 6subtype0 for a
     given index position is, by definition, the subtype denoted by the type mark of the corresponding index
     subtype definition.  The compound delimiter <> (called a 6box)0 of an index subtype definition stands
     for an undefined range (different objects of the type need not have the same bounds).  The elaboration of
     an unconstrained array definition creates an array type; this elaboration includes that of the component
     subtype indication.

     A constrained array definition defines both an array type and a subtype of this type:

        - The array type is an implicitly declared anonymous type; this type is defined by an (implicit)
          unconstrained array definition, in which the component subtype indication is that of the
          constrained array definition, and in which the type mark of each index subtype definition
          denotes the subtype defined by the corresponding discrete range.

        - The array subtype is the subtype obtained by imposition of the index constraint on the array
          type.

     If a constrained array definition is given for a type declaration, the simple name declared by this
     declaration denotes the array subtype.

     The elaboration of a constrained array definition creates the corresponding array type and array subtype.
     For this elaboration, the index constraint and the component subtype indication are elaborated.  The
     evaluation of each discrete range of the index constraint and the elaboration of the component subtype
     indication are performed in some order that is not defined by the language.

     6Examples0 6of0 6type0 6declarations0 6with0 6unconstrained0 6array0 6definitions:

0         1type0 VECTOR           1is0 1array0(INTEGER   1range0 <>) of REAL;
         1type0 MATRIX           1is0 1array0(INTEGER   1range0 <>, INTEGER 1range0 <>) of REAL;
         1type0 BIT_VECTOR       1is0 1array0(INTEGER   1range0 <>) of BOOLEAN;
         1type0 ROMAN            1is0 1array0(POSITIVE  1range0 <>) of ROMAN_DIGIT;

     6Examples0 6of0 6type0 6declarations0 6with0 6constrained0 6array0 6definitions:

0         1type0 TABLE        1is0 1array0(1 .. 10) 1of0 INTEGER;
         1type0 SCHEDULE     1is0 1array0(DAY) 1of0 BOOLEAN;
         1type0 LINE         1is0 1array0(1 .. MAX_LINE_SIZE) 1of0 CHARACTER;

     6Examples0 6of0 6object0 6declarations0 6with0 6constrained0 6array0 6definitions:

0         GRID     : 1array0(1 .. 80, 1 .. 100) 1of0 BOOLEAN;
         MIX      : 1array0(COLOR 1range0 RED .. GREEN) 1of0 BOOLEAN;
         PAGE     : 1array0(1 .. 50) 1of0 LINE;  --  an array of arrays

     6Note:

0     For a one-dimensional array, the rule given means that a type declaration with a constrained array
     definition such as

         1type0 T 1is0 1array0(POSITIVE 1range0 MIN .. MAX) 1of0 COMPONENT;

     is equivalent (in the absence of an incorrect order dependence) to the succession of declarations

         1subtype0 6index_subtype0 1is0 POSITIVE 1range0 MIN .. MAX;
         1type0 6array_type0 1is0 1array(6index_subtype0 1range0 <>) 1of0 COMPONENT;
         1subtype0 T 1is0 6array_type(index_subtype);

0     where 6index_subtype0 and 6array_type0 are both anonymous.  Consequently, T is the name of a subtype
     and all objects declared with this type mark are arrays that have the same bounds.  Similar
     transformations apply to multidimensional arrays.

     A similar transformation applies to an object whose declaration includes a constrained array definition.
     A consequence of this is that no two such objects have the same type.

     6References:0 4 anonymous type 3.3.1, bound of a range 3.5, component 3.3, constraint 3.3, discrete
     type 3.5, elaboration 3.1 3.9, in some order 1.6, name 4.1, object 3.2, range 3.5, subtype 3.3, subtype
     indication 3.3.2, type 3.3, type declaration 3.3.1, type definition 3.3.1, type mark 3.3.20

      subsection lrm-section3-6-1



     73.6.1. Index Constraints and Discrete Ranges

0     An index constraint determines the range of possible values for every index of an array type, and thereby
     the corresponding array bounds.

     For a discrete range used in a constrained array definition and defined by a range, an implicit
     conversion to the predefined type INTEGER is assumed if each bound is either a numeric literal, a named
     number, or an attribute, and the type of both bounds (prior to the implicit conversion) is the type
     6universal_integer.0 Otherwise, both bounds must be of the same discrete type, other than
     6universal_integer;0 this type must be determinable independently of the context, but using the fact
     that the type must be discrete and that both bounds must have the same type.  These rules apply also to a
     discrete range used in an iteration rule (see 5.5) or in the declaration of a family of entries (see
     9.5).

     If an index constraint follows a type mark in a subtype indication, then the type or subtype denoted by
     the type mark must not already impose an index constraint.  The type mark must denote either an
     unconstrained array type or an access type whose designated type is such an array type.  In either case,
     the index constraint must provide a discrete range for each index of the array type and the type of each
     discrete range must be the same as that of the corresponding index.

     An index constraint is 6compatible0 with the type denoted by the type mark if and only if the
     constraint defined by each discrete range is compatible with the corresponding index subtype.  If any of
     the discrete ranges defines a null range, any array thus constrained is a 6null0 6array,0 having no
     components.  An array value 6satisfies0 an index constraint if at each index position the array value
     and the index constraint have the same index bounds.  (Note, however, that assignment and certain other
     operations on arrays involve an implicit subtype conversion.)

     The bounds of each array object are determined as follows:

        - For a variable declared by an object declaration, the subtype indication of the corresponding
          object declaration must define a constrained array subtype (and, thereby, the bounds).  The
          same requirement exists for the subtype indication of a component declaration, if the type of
          the record component is an array type; and for the component subtype indication of an array
          type definition, if the type of the array components is itself an array type.

        - For a constant declared by an object declaration, the bounds of the constant are defined by the
          initial value if the subtype of the constant is unconstrained; they are otherwise defined by
          this subtype (in the latter case, the initial value is the result of an implicit subtype
          conversion).  The same rule applies to a generic formal parameter of mode 1in.

0        - For an array object designated by an access value, the bounds must be defined by the allocator
          that creates the array object.  (The allocated object is constrained with the corresponding
          values of the bounds.)

        - For a formal parameter of a subprogram or entry, the bounds are obtained from the corresponding
          actual parameter.  (The formal parameter is constrained with the corresponding values of the
          bounds.)

        - For a renaming declaration and for a generic formal parameter of mode 1in0 1out,0 the
          bounds are those of the renamed object or of the corresponding generic actual parameter.

     For the elaboration of an index constraint, the discrete ranges are evaluated in some order that is not
     defined by the language.

     6Examples0 6of0 6array0 6declarations0 6including0 6an0 6index0 6constraint:

0         BOARD           : MATRIX(1 .. 8,   1 .. 8);    --  see 3.6
         RECTANGLE       : MATRIX(1 .. 20,  1 .. 30);
         INVERSE         : MATRIX(1 .. N,   1 .. N);    --  N need not be static
         FILTER          : BIT_VECTOR(0 .. 31);

     6Example0 6of0 6array0 6declaration0 6with0 6a0 6constrained0 6array0 6subtype:

0         MY_SCHEDULE  : SCHEDULE;  --  all arrays of type SCHEDULE have the same bounds

     6Example0 6of0 6record0 6type0 6with0 6a0 6component0 6that0 6is0 6an0 6array:

0         1type0 VAR_LINE(LENGTH : INTEGER) 1is
0            1record
0               IMAGE : STRING(1 .. LENGTH);
            1end0 1record0;

         NULL_LINE : VAR_LINE(0);  --  NULL_LINE.IMAGE is a null array

     6Notes:

0     The elaboration of a subtype indication consisting of a type mark followed by an index constraint checks
     the compatibility of the index constraint with the type mark (see 3.3.2).

     All components of an array have the same subtype.  In particular, for an array of components that are
     one-dimensional arrays, this means that all components have the same bounds and hence the same length.

     6References:0 4 access type 3.8, access type definition 3.8, access value 3.8, actual parameter 6.4.1,
     allocator 4.8, array bound 3.6, array component 3.6, array type 3.6, array type definition 3.6, bound of
     a range 3.5, compatible 3.3.2, component declaration 3.7, constant 3.2.1, constrained array definition
     3.6, constrained array subtype 3.6, conversion 4.6, designate 3.8, designated type 3.8, discrete range
     3.6, entry 9.5, entry family declaration 9.5, expression 4.4, formal parameter 6.1, function 6.5, generic
     actual parameter 12.3, generic formal parameter 12.1 12.3, generic parameter 12.1, index 3.6, index
     constraint 3.6.1, index subtype 3.6, initial value 3.2.1, integer literal 2.4, integer type 3.5.4,
     iteration rule 5.5, mode 12.1.1, name 4.1, null range 3.5, object 3.2, object declaration 3.2.1,
     predefined type C, range 3.5, record component 3.7, renaming declaration 8.5, result subtype 6.1, satisfy
     3.3, subprogram 6, subtype conversion 4.6, subtype indication 3.3.2, type mark 3.3.2, unconstrained array
     type 3.6, unconstrained subtype 3.3, universal type 4.10, universal_integer type 3.5.4, variable 3.2.10

      subsection lrm-section3-6-2



     73.6.2. Operations of Array Types

0     The basic operations of an array type include the operations involved in assignment and aggregates
     (unless the array type is limited), membership tests, indexed components, qualification, and explicit
     conversion; for one-dimensional arrays the basic operations also include the operations involved in
     slices, and also string literals if the component type is a character type.

     If A is an array object, an array value, or a constrained array subtype, the basic operations also
     include the attributes listed below.  These attributes are not allowed for an unconstrained array type.
     The argument N used in the attribute designators for the N-th dimension of an array must be a static
     expression of type 6universal_integer.0 The value of N must be positive (nonzero) and no greater than
     the dimensionality of the array.

     A'FIRST             Yields the lower bound of the first index range.  The value of this attribute has the
                         same type as this lower bound.

     A'FIRST(N)          Yields the lower bound of the N-th index range.  The value of this attribute has the
                         same type as this lower bound.

     A'LAST              Yields the upper bound of the first index range.  The value of this attribute has the
                         same type as this upper bound.

     A'LAST(N)           Yields the upper bound of the N-th index range.  The value of this attribute has the
                         same type as this upper bound.

     A'RANGE             Yields the first index range, that is, the range A'FIRST .. A'LAST.

     A'RANGE(N)          Yields the N-th index range, that is, the range A'FIRST(N) .. A'LAST(N).

     A'LENGTH            Yields the number of values of the first index range (zero for a null range).  The
                         value of this attribute is of the type 6universal_integer.

0     A'LENGTH(N)         Yields the number of values of the N-th index range (zero for a null range).  The
                         value of this attribute is of the type 6universal_integer.

0     In addition, the attribute T'BASE is defined for an array type or subtype T (see 3.3.3); the attribute
     T'SIZE is defined for an array type or subtype T, and the attributes A'SIZE and A'ADDRESS are defined for
     an array object A (see 13.7.2).

     Besides the basic operations, the operations of an array type include the predefined comparison for
     equality and inequality, unless the array type is limited.  For one-dimensional arrays, the operations
     include catenation, unless the array type is limited; if the component type is a discrete type, the
     operations also include all predefined relational operators; if the component type is a boolean type,
     then the operations also include the unary logical negation operator 1not,0 and the logical operators.

     6Examples0 (6using0 6arrays0 6declared0 6in0 6the0 6examples0 6of0 6section
0     63.6.1):

0             --  FILTER'FIRST             =     0   FILTER'LAST  =  31     FILTER'LENGTH     =  32
             --  RECTANGLE'LAST(1)        =    20   RECTANGLE'LAST(2)                        = 30

     6Notes:

0     The attributes A'FIRST and A'FIRST(1) yield the same value.  A similar relation exists for the attributes
     A'LAST, A'RANGE, and A'LENGTH.  The following relations are satisfied (except for a null array) by the
     above attributes if the index type is an integer type:

         A'LENGTH      = A'LAST      - A'FIRST      + 1
         A'LENGTH(N)   = A'LAST(N)   - A'FIRST(N)   + 1

     An array type is limited if its component type is limited (see 7.4.4).

     6References:0 4 aggregate 4.3, array type 3.6, assignment 5.2, attribute 4.1.4, basic operation 3.3.3,
     bound of a range 3.5, catenation operator 4.5 4.5.3, character type 3.5.2, constrained array subtype 3.6,
     conversion 4.6, designator 6.1, dimension 3.6, index 3.6, indexed component 4.1.1, limited type 7.4.4,
     logical operator 4.5 4.5.1, membership test 4.5 4.5.2, not operator 4.5 4.5.6, null range 3.5, object
     3.2, operation 3.3, predefined operator 4.5, qualified expression 4.7, relational operator 4.5 4.5.2,
     slice 4.1.2, static expression 4.9, string literal 2.6, subcomponent 3.3, type 3.3, unconstrained array
     type 3.6, universal type 4.10, universal_integer type 3.5.40

      subsection lrm-section3-6-3



     73.6.3. The Type String

0     The values of the predefined type STRING are one-dimensional arrays of the predefined type CHARACTER,
     indexed by values of the predefined subtype POSITIVE:

         1subtype0 POSITIVE 1is0 INTEGER 1range0 1 .. INTEGER'LAST;
         1type0 STRING 1is0 1array0(POSITIVE 1RANGE0 <>) of CHARACTER;

     6Examples:

0         STARS        : STRING(1 .. 120)     := (1 .. 120 => '*' );
         QUESTION     : 1constant0 STRING  := "HOW MANY CHARACTERS?";
         --  QUESTION'FIRST = 1, QUESTION'LAST = 20 (the number of characters)

         ASK_TWICE     : 1constant0 STRING   := QUESTION & QUESTION;
         NINETY_SIX    : 1constant0 ROMAN    := "XCVI";        --  see 3.6

     6Notes:

0     String literals (see 2.6 and 4.2) are basic operations applicable to the type STRING and to any other
     one-dimensional array type whose component type is a character type.  The catenation operator is a
     predefined operator for the type STRING and for one-dimensional array types; it is represented as &.  The
     relational operators <, <=, >, and >= are defined for values of these types, and correspond to
     lexicographic order (see 4.5.2).

     6References:0 4 aggregate 4.3, array 3.6, catenation operator 4.5 4.5.3, character type 3.5.2,
     component type (of an array) 3.6, dimension 3.6, index 3.6, lexicographic order 4.5.2, positional
     aggregate 4.3, predefined operator 4.5, predefined type C, relational operator 4.5 4.5.2, string literal
     2.6, subtype 3.3, type 3.30

      section lrm-section3-7

     23.7. Record Types

0     A record object is a composite object consisting of named components.  The value of a record object is a
     composite value consisting of the values of its components.

         record_type_definition ::=
            1record
0               component_list
            1end0 1record

0         component_list ::=
               component_declaration {component_declaration}
           | { component_declaration} variant_part
           |   1null;

0         component_declaration ::=
           identifier_list : component_subtype_definition [:= expression];

         component_subtype_definition ::=  subtype_indication

     Each component declaration declares a component of the record type.  Besides components declared by
     component declarations, the components of a record type include any components declared by discriminant
     specifications of the record type declaration.  The identifiers of all components of a record type must
     be distinct.  The use of a name that denotes a record component other than a discriminant is not allowed
     within the record type definition that declares the component.

     A component declaration with several identifiers is equivalent to a sequence of single component
     declarations, as explained in section 3.2.  Each single component declaration declares a record component
     whose subtype is specified by the component subtype definition.

     If a component declaration includes the assignment compound delimiter followed by an expression, the
     expression is the default expression of the record component; the default expression must be of the type
     of the component.  Default expressions are not allowed for components that are of a limited type.

     If a record type does not have a discriminant part, the same components are present in all values of the
     type.  If the component list of a record type is defined by the reserved word 1null0 and there is no
     discriminant part, then the record type has no components and all records of the type are 6null
0     records.

     The elaboration of a record type definition creates a record type; it consists of the elaboration of any
     corresponding (single) component declarations, in the order in which they appear, including any component
     declaration in a variant part.  The elaboration of a component declaration consists of the elaboration of
     the component subtype definition.

     For the elaboration of a component subtype definition, if the constraint does not depend on a
     discriminant (see 3.7.1), then the subtype indication is elaborated.  If, on the other hand, the
     constraint depends on a discriminant, then the elaboration consists of the evaluation of any included
     expression that is not a discriminant.

     6Examples0 6of0 6record0 6type0 6declarations:

0         1type0 DATE 1is
0              1record
0                   DAY        : INTEGER 1range0 1 .. 31;
                   MONTH      : MONTH_NAME;
                   YEAR       : INTEGER 1range0 0 .. 4000;
              1end0 1record0;

         1type0 COMPLEX 1is
0              1record
0                   RE   : REAL := 0.0;
                   IM   : REAL := 0.0;
              1end0 1record0;

     6Examples0 6of0 6record0 6variables:

0         TOMORROW, YESTERDAY : DATE;
         A, B, C : COMPLEX;

         -- both components of A, B, and C are implicitly initialized to zero

     6Notes:

0     The default expression of a record component is implicitly evaluated by the elaboration of the
     declaration of a record object, in the absence of an explicit initialization (see 3.2.1).  If a component
     declaration has several identifiers, the expression is evaluated once for each such component of the
     object (since the declaration is equivalent to a sequence of single component declarations).

     Unlike the components of an array, the components of a record need not be of the same type.

     6References:0 4 assignment compound delimiter 2.2, component 3.3, composite value 3.3, constraint 3.3,
     declaration 3.1, depend on a discriminant 3.7.1, discriminant 3.3, discriminant part 3.7 3.7.1,
     elaboration 3.9, expression 4.4, identifier 2.3, identifier list 3.2, limited type 7.4.4, name 4.1,
     object 3.2, subtype 3.3, type 3.3, type mark 3.3.2, variant part 3.7.30

      subsection lrm-section3-7-1



     73.7.1. Discriminants

0     A discriminant part specifies the discriminants of a type.  A discriminant of a record is a component of
     the record.  The type of a discriminant must be discrete.

         discriminant_part ::=
            (discriminant_specification {; discriminant_specification})

         discriminant_specification ::=
            identifier_list : type_mark [:= expression]

     A discriminant part is only allowed in the type declaration for a record type, in a private type
     declaration or an incomplete type declaration (the corresponding full declaration must then declare a
     record type), and in the generic parameter declaration for a formal private type.

     A discriminant specification with several identifiers is equivalent to a sequence of single discriminant
     specifications, as explained in section 3.2.  Each single discriminant specification declares a
     discriminant.  If a discriminant specification includes the assignment compound delimiter followed by an
     expression, the expression is the default expression of the discriminant; the default expression must be
     of the type of the discriminant.  Default expressions must be provided either for all or for none of the
     discriminants of a discriminant part.

     The use of the name of a discriminant is not allowed in default expressions of a discriminant part if the
     specification of the discriminant is itself given in the discriminant part.

     Within a record type definition the only allowed uses of the name of a discriminant of the record type
     are:  in the default expressions for record components; in a variant part as the discriminant name; and
     in a component subtype definition, either as a bound in an index constraint, or to specify a discriminant
     value in a discriminant constraint.  A discriminant name used in these component subtype definitions must
     appear by itself, not as part of a larger expression.  Such component subtype definitions and such
     constraints are said to 6depend0 6on0 6a0 6discriminant.

0     A component is said to 6depend0 6on0 6a0 6discriminant0 if it is a record component declared in a
     variant part, or a record component whose component subtype definition depends on a discriminant, or
     finally, one of the subcomponents of a component that itself depends on a discriminant.

     Each record value includes a value for each discriminant specified for the record type; it also includes
     a value for each record component that does not depend on a discriminant.  The values of the
     discriminants determine which other component values are in the record value.

     Direct assignment to a discriminant of an object is not allowed; furthermore a discriminant is not
     allowed as an actual parameter of mode 1in0 1out0 or 1out,0 or as a generic actual parameter of
     mode 1in0 1out.0 The only allowed way to change the value of a discriminant of a variable is to
     assign a (complete) value to the variable itself.  Similarly, an assignment to the variable itself is the
     only allowed way to change the constraint of one of its components, if the component subtype definition
     depends on a discriminant of the variable.

     The elaboration of a discriminant part has no other effect.

     6Examples:

0         1type0 BUFFER(SIZE : BUFFER_SIZE := 100) 1is0        -- see 3.5.4
             1record
0                  POS       : BUFFER_SIZE := 0;
                  VALUE     : STRING(1 .. SIZE);
             1end0 1record0;

         1type0 SQUARE(SIDE : INTEGER) 1is
0             1record
0                  MAT  : MATRIX(1 .. SIDE, 1 .. SIDE);       -- see 3.6
             1end0 1record0;

         1type0 DOUBLE_SQUARE(NUMBER : INTEGER) 1is
0             1record
0                  LEFT  : SQUARE (NUMBER);
                  RIGHT     : SQUARE (NUMBER);
             1end0 1record0;

         1type0 ITEM(NUMBER : POSITIVE) 1is
0             1record
0                  CONTENT : INTEGER;
                  --  no component depends on the discriminant
             1end0 1record0;

     6References:0 4 assignment 5.2, assignment compound delimiter 2.2, bound of a range 3.5, component
     3.3, component declaration 3.7, component of a record 3.7, declaration 3.1, discrete type 3.5,
     discriminant 3.3, discriminant constraint 3.7.2, elaboration 3.9, expression 4.4, generic formal type
     12.1, generic parameter declaration 12.1, identifier 2.3, identifier list 3.2, incomplete type
     declaration 3.8.1, index constraint 3.6.1, name 4.1, object 3.2, private type 7.4, private type
     declaration 7.4, record type 3.7, scope 8.2, simple name 4.1, subcomponent 3.3, subtype indication 3.3.2,
     type declaration 3.3.1, type mark 3.3.2, variant part 3.7.3 0

      subsection lrm-section3-7-2



     73.7.2. Discriminant Constraints

0     A discriminant constraint is only allowed in a subtype indication, after a type mark.  This type mark
     must denote either a type with discriminants, or an access type whose designated type is a type with
     discriminants.  A discriminant constraint specifies the values of these discriminants.

         discriminant_constraint ::=
            (discriminant_association {, discriminant_association})
         discriminant_association ::=
            [6discriminant_0simple_name {| 6discriminant_0simple_name} =>] expression

     Each discriminant association associates an expression with one or more discriminants.  A discriminant
     association is said to be 6named0 if the discriminants are specified explicitly by their names; it is
     otherwise said to be 6positional.0 For a positional association, the (single) discriminant is
     implicitly specified by position, in textual order.  Named associations can be given in any order, but if
     both positional and named associations are used in the same discriminant constraint, then positional
     associations must occur first, at their normal position.  Hence once a named association is used, the
     rest of the discriminant constraint must use only named associations.

     For a named discriminant association, the discriminant names must denote discriminants of the type for
     which the discriminant constraint is given.  A discriminant association with more than one discriminant
     name is only allowed if the named discriminants are all of the same type.  Furthermore, for each
     discriminant association (whether named or positional), the expression and the associated discriminants
     must have the same type.  A discriminant constraint must provide exactly one value for each discriminant
     of the type.

     A discriminant constraint is compatible with the type denoted by a type mark, if and only if each
     discriminant value belongs to the subtype of the corresponding discriminant.  In addition, for each
     subcomponent whose component subtype specification depends on a discriminant, the discriminant value is
     substituted for the discriminant in this component subtype specification and the compatibility of the
     resulting subtype indication is checked.

     A composite value satisfies a discriminant constraint if and only if each discriminant of the composite
     value has the value imposed by the discriminant constraint.

     The initial values of the discriminants of an object of a type with discriminants are determined as
     follows:

        - For a variable declared by an object declaration, the subtype indication of the corresponding
          object declaration must impose a discriminant constraint unless default expressions exist for
          the discriminants; the discriminant values are defined either by the constraint or, in its
          absence, by the default expressions.  The same requirement exists for the subtype indication of
          a component declaration, if the type of the record component has discriminants; and for the
          component subtype indication of an array type, if the type of the array components is a type
          with discriminants.

        - For a constant declared by an object declaration, the values of the discriminants are those of
          the initial value if the subtype of the constant is unconstrained; they are otherwise defined
          by this subtype (in the latter case, an exception is raised if the initial value does not
          belong to this subtype).  The same rule applies to a generic parameter of mode 1in.

0        - For an object designated by an access value, the discriminant values must be defined by the
          allocator that creates the object.  (The allocated object is constrained with the corresponding
          discriminant values.)

        - For a formal parameter of a subprogram or entry, the discriminants of the formal parameter are
          initialized with those of the corresponding actual parameter.  (The formal parameter is
          constrained if the corresponding actual parameter is constrained, and in any case if the mode
          is 1in0 or if the subtype of the formal parameter is constrained.)

        - For a renaming declaration and for a generic formal parameter of mode 1in0 1out,0 the
          discriminants are those of the renamed object or of the corresponding generic actual parameter.

     For the elaboration of a discriminant constraint, the expressions given in the discriminant associations
     are evaluated in some order that is not defined by the language; the expression of a named association is
     evaluated once for each named discriminant.

     6Examples0 (6using0 6types0 6declared0 6in0 6the0 6previous0 6section):

0         LARGE       : BUFFER(200);  --  constrained, always 200 characters (explicit discriminant value)
         MESSAGE     : BUFFER;       --  unconstrained, initially 100 characters (default discriminant val

         BASIS       : SQUARE(5);    --  constrained, always 5 by 5
         ILLEGAL     : SQUARE;       --  illegal, a SQUARE must be constrained

     6Note:

0     The above rules and the rules defining the elaboration of an object declaration (see 3.2) ensure that
     discriminants always have a value.  In particular, if a discriminant constraint is imposed on an object
     declaration, each discriminant is initialized with the value specified by the constraint.  Similarly, if
     the subtype of a component has a discriminant constraint, the discriminants of the component are
     correspondingly initialized.

     6References:0 4 access type 3.8, access type definition 3.8, access value 3.8, actual parameter 6.4.1,
     allocator 4.8, array type definition 3.6, bound of a range 3.5, compatible 3.3.2, component 3.3,
     component declaration 3.7, component subtype indication 3.7, composite value 3.3, constant 3.2.1,
     constrained subtype 3.3, constraint 3.3, declaration 3.1, default expression for a discriminant 3.7,
     depend on a discriminant 3.7.1, designate 3.8, designated type 3.8, discriminant 3.3, elaboration 3.9,
     entry 9.5, evaluation 4.5, expression 4.4, formal parameter 6.1, generic actual parameter 12.3, generic
     formal parameter 12.1 12.3, mode in 6.1, mode in out 6.1, name 4.1, object 3.2, object declaration 3.2.1,
     renaming declaration 8.5, reserved word 2.9, satisfy 3.3, simple name 4.1, subcomponent 3.3, subprogram
     6, subtype 3.3, subtype indication 3.3.2, type 3.3, type mark 3.3.2, variable 3.2.1 0

      subsection lrm-section3-7-3



     73.7.3. Variant Parts

0     A record type with a variant part specifies alternative lists of components.  Each variant defines the
     components for the corresponding value or values of the discriminant.

         variant_part ::=
            1case0 6discriminant_0simple_name 1is
0                     variant
                 {   variant}
            1end0 1case;

0         variant ::=
            1when0 choice {| choice} =>
                 component_list

         choice ::= simple_expression
            | discrete_range | 1others0 | 6component0_simple_name

     Each variant starts with a list of choices which must be of the same type as the discriminant of the
     variant part.  The type of the discriminant of a variant part must not be a generic formal type.  If the
     subtype of the discriminant is static, then each value of this subtype must be represented once and only
     once in the set of choices of the variant part, and no other value is allowed.  Otherwise, each value of
     the (base) type of the discriminant must be represented once and only once in the set of choices.

     The simple expressions and discrete ranges given as choices in a variant part must be static.  A choice
     defined by a discrete range stands for all values in the corresponding range (none if a null range).  The
     choice 1others0 is only allowed for the last variant and as its only choice; it stands for all values
     (possibly none) not given in the choices of previous variants.  A component simple name is not allowed as
     a choice of a variant (although it is part of the syntax of choice).

     A record value contains the values of the components of a given variant if and only if the discriminant
     value is equal to one of the values specified by the choices of the variant.  This rule applies in turn
     to any further variant that is, itself, included in the component list of the given variant.  If the
     component list of a variant is specified by 1null,0 the variant has no components.

     6Example0 6of0 6record0 6type0 6with0 6a0 6variant0 6part:

0         1type0 DEVICE 1is0 (PRINTER, DISK, DRUM);
         1type0 STATE  1is0 (OPEN, CLOSED);

         1type0 PERIPHERAL(UNIT : DEVICE := DISK) 1is
0              1record
0                   STATUS : STATE;
                   1case0 UNIT 1is
0                        1when0 PRINTER =>
                            LINE_COUNT    : INTEGER 1range0 1 .. PAGE_SIZE;
                        1when0 1others0 =>
                            CYLINDER      : CYLINDER_INDEX;
                            TRACK         : TRACK_NUMBER;
                   1end0 1case0;
              1end0 1record0;


     6Examples0 6of0 6record0 6subtypes:

0         1subtype0 DRUM_UNIT   1is0 PERIPHERAL(DRUM);
         1subtype0 DISK_UNIT   1is0 PERIPHERAL(DISK);

     6Examples0 6of0 6constrained0 6record0 6variables:

0         WRITER    : PERIPHERAL(UNIT => PRINTER);
         ARCHIVE   : DISK_UNIT;

     6Note:

0     Choices with discrete values are also used in case statements and in array aggregates.  Choices with
     component simple names are used in record aggregates.

     6References:0 4 array aggregate 4.3.2, base type 3.3, component 3.3, component list 3.7, discrete
     range 3.6, discriminant 3.3, generic formal type 12.1.2, null range 3.5, record aggregate 4.3.1, range
     3.5, record type 3.7, simple expression 4.4, simple name 4.1, static discrete range 4.9, static
     expression 4.9, static subtype 4.9, subtype 3.3 0

      subsection lrm-section3-7-4



     73.7.4. Operations of Record Types

0     The basic operations of a record type include the operations involved in assignment and aggregates
     (unless the type is limited), membership tests, selection of record components, qualification, and type
     conversion (for derived types).

     For any object A of a type with discriminants, the basic operations also include the following attribute:

     A'CONSTRAINED       Yields the value TRUE if a discriminant constraint applies to the object A, or if the
                         object is a constant (including a formal parameter or generic formal parameter of
                         mode 1in0); yields the value FALSE otherwise.  If A is a generic formal parameter
                         of mode 1in0 1out,0 or if A is a formal parameter of mode 1in0 1out0 or
                         1out0 and the type mark given in the corresponding parameter specification denotes
                         an unconstrained type with discriminants, then the value of this attribute is
                         obtained from that of the corresponding actual parameter.  The value of this
                         attribute is of the predefined type BOOLEAN.

     In addition, the attributes T'BASE and T'SIZE are defined for a record type or subtype T (see 3.3.3); the
     attributes A'SIZE and A'ADDRESS are defined for a record object A (see 13.7.2).

     Besides the basic operations, the operations of a record type include the predefined comparison for
     equality and inequality, unless the type is limited.

     6Note:

0     A record type is limited if the type of any of its components is limited (see 7.4.4).

     6References:0 4 actual parameter 6.4.1, aggregate 4.3, assignment 5.2, attribute 4.1.4, basic
     operation 3.3.3, boolean type 3.5.3, constant 3.2.1, conversion 4.6, derived type 3.4, discriminant 3.3,
     discriminant constraint 3.7.2, formal parameter 6.1, generic actual parameter 12.3, generic formal
     parameter 12.1 12.3, limited type 7.4.4, membership test 4.5 4.5.2, mode 6.1, object 3.2.1, operation
     3.3, predefined operator 4.5, predefined type C, qualified expression 4.7, record type 3.7, relational
     operator 4.5 4.5.2, selected component 4.1.3, subcomponent 3.3, subtype 3.3, type 3.3 0

      section lrm-section3-8

     23.8. Access Types

0     An object declared by an object declaration is created by the elaboration of the object declaration and
     is denoted by a simple name or by some other form of name.  In contrast, there are objects that are
     created by the evaluation of 6allocators0 (see 4.8) and that have no simple name.  Access to such an
     object is achieved by an 6access0 6value0 returned by an allocator; the access value is said to
     6designate0 the object.

         access_type_definition ::= 1access0 subtype_indication

     For each access type, there is a literal 1null0 which has a null access value designating no object at
     all.  The null value of an access type is the default initial value of the type.  Other values of an
     access type are obtained by evaluation of a special operation of the type, called an allocator.  Each
     such access value designates an object of the subtype defined by the subtype indication of the access
     type definition; this subtype is called the 6designated0 6subtype;0 the base type of this subtype is
     called the 6designated0 6type.0 The objects designated by the values of an access type form a
     6collection0 implicitly associated with the type.

     The elaboration of an access type definition consists of the elaboration of the subtype indication and
     creates an access type.

     If an access object is constant, the contained access value cannot be changed and always designates the
     same object.  On the other hand, the value of the designated object need not remain the same (assignment
     to the designated object is allowed unless the designated type is limited).

     The only forms of constraint that are allowed after the name of an access type in a subtype indication
     are index constraints and discriminant constraints.  (See sections 3.6.1 and 3.7.2 for the rules
     applicable to these subtype indications.)  An access value 6belongs0 to a corresponding subtype of an
     access type either if the access value is the null value or if the value of the designated object
     satisfies the constraint.

     6Examples:

0         1type0 FRAME 1is0 1access0 MATRIX;                  --  see 3.6

         1type0 BUFFER_NAME 1is0 1access0 BUFFER;            --  see 3.7.1

     6Notes:

0     An access value delivered by an allocator can be assigned to several access objects.  Hence it is
     possible for an object created by an allocator to be designated by more than one variable or constant of
     the access type.  An access value can only designate an object created by an allocator; in particular, it
     cannot designate an object declared by an object declaration.

     If the type of the objects designated by the access values is an array type or a type with discriminants,
     these objects are constrained with either the array bounds or the discriminant values supplied implicitly
     or explicitly for the corresponding allocators (see 4.8).

     Access values are called 6pointers0 or 6references0 in some other languages.

     6References:0 4 allocator 4.8, array type 3.6, assignment 5.2, belong to a subtype 3.3, constant
     3.2.1, constraint 3.3, discriminant constraint 3.7.2, elaboration 3.9, index constraint 3.6.1, index
     specification 3.6, limited type 7.4.4, literal 4.2, name 4.1, object 3.2.1, object declaration 3.2.1,
     reserved word 2.9, satisfy 3.3, simple name 4.1, subcomponent 3.3, subtype 3.3, subtype indication 3.3.2,
     type 3.3, variable 3.2.1 0

      subsection lrm-section3-8-1



     73.8.1. Incomplete Type Declarations

0     There are no particular limitations on the designated type of an access type.  In particular, the type of
     a component of the designated type can be another access type, or even the same access type.  This
     permits mutually dependent and recursive access types.  Their declarations require a prior incomplete (or
     private) type declaration for one or more types.

         incomplete_type_declaration ::= 1type0 identifier [discriminant_part];

     For each incomplete type declaration, there must be a corresponding declaration of a type with the same
     identifier.  The corresponding declaration must be either a full type declaration or the declaration of a
     task type.  In the rest of this section, explanations are given in terms of full type declarations; the
     same rules apply also to declarations of task types.  If the incomplete type declaration occurs
     immediately within either a declarative part or the visible part of a package specification, then the
     full type declaration must occur later and immediately within this declarative part or visible part.  If
     the incomplete type declaration occurs immediately within the private part of a package, then the full
     type declaration must occur later and immediately within either the private part itself, or the
     declarative part of the corresponding package body.

     A discriminant part must be given in the full type declaration if and only if one is given in the
     incomplete type declaration; if discriminant parts are given, then they must conform (see 6.3.1 for the
     conformance rules).  Prior to the end of the full type declaration, the only allowed use of a name that
     denotes a type declared by an incomplete type declaration is as the type mark in the subtype indication
     of an access type definition; the only form of constraint allowed in this subtype indication is a
     discriminant constraint.

     The elaboration of an incomplete type declaration creates a type.  If the incomplete type declaration has
     a discriminant part, this elaboration includes that of the discriminant part:  in such a case, the
     discriminant part of the full type declaration is not elaborated.

     6Example0 6of0 6a0 6recursive0 6type:

0         1type0 CELL;  --  incomplete type declaration
         1type0 LINK 1is0 1access0 CELL;

         1type0 CELL 1is
0            1record
0               VALUE  : INTEGER;
               SUCC   : LINK;
               PRED   : LINK;
            1end0 1record0;

         HEAD   : LINK := 1new0 CELL'(0, NULL, NULL);
         NEXT   : LINK := HEAD.SUCC;

     6Examples0 6of0 6mutually0 6dependent0 6access0 6types:

0         1type0 PERSON(SEX : GENDER);  --  incomplete type declaration
         1type0 CAR;                   --  incomplete type declaration

         1type0 PERSON_NAME 1is0 1access0 PERSON;
         1type0 CAR_NAME    1is0 1access0 CAR;

         1type0 CAR 1is
0            1record
0               NUMBER   : INTEGER;
               OWNER    : PERSON_NAME;
            1end0 1record0;

         1type0 PERSON(SEX : GENDER) 1is
0              1record
0                   NAME       : STRING(1 .. 20);
                   BIRTH      : DATE;
                   AGE        : INTEGER 1range0 0 .. 130;
                   VEHICLE    : CAR_NAME;
                   1case0 SEX 1is
0                        1when0 M => WIFE        : PERSON_NAME(SEX => F);
                        1when0 F               => HUSBAND                                               
                   1end0 1case0;
              1end0 1record0;

         MY_CAR, YOUR_CAR, NEXT_CAR : CAR_NAME;  --  implicitly initialized with null value

     6References:0 4 access type 3.8, access type definition 3.8, component 3.3, conform 6.3.1, constraint
     3.3, declaration 3.1, declarative item 3.9, designate 3.8, discriminant constraint 3.7.2, discriminant
     part 3.7.1, elaboration 3.9, identifier 2.3, name 4.1, subtype indication 3.3.2, type 3.3, type mark
     3.3.20

      subsection lrm-section3-8-2



     73.8.2. Operations of Access Types

0     The basic operations of an access type include the operations involved in assignment, allocators for the
     access type, membership tests, qualification, explicit conversion, and the literal 1null.0 If the
     designated type is a type with discriminants, the basic operations include the selection of the
     corresponding discriminants; if the designated type is a record type, they include the selection of the
     corresponding components; if the designated type is an array type, they include the formation of indexed
     components and slices; if the designated type is a task type, they include selection of entries and entry
     families.  Furthermore, the basic operations include the formation of a selected component with the
     reserved word 1all0 (see 4.1.3).

     If the designated type is an array type, the basic operations include the attributes that have the
     attribute designators FIRST, LAST, RANGE, and LENGTH (likewise, the attribute designators of the N-th
     dimension).  The prefix of each of these attributes must be a value of the access type.  These attributes
     yield the corresponding characteristics of the designated object (see 3.6.2).

     If the designated type is a task type, the basic operations include the attributes that have the
     attribute designators TERMINATED and CALLABLE (see 9.9).  The prefix of each of these attributes must be
     a value of the access type.  These attributes yield the corresponding characteristics of the designated
     task objects.

     In addition, the attribute T'BASE (see 3.3.3) and the representation attributes T'SIZE and T'STORAGE_SIZE
     (see 13.7.2) are defined for an access type or subtype T; the attributes A'SIZE and A'ADDRESS are defined
     for an access object A (see 13.7.2).

     Besides the basic operations, the operations of an access type include the predefined comparison for
     equality and inequality.

     6References:0 4 access type 3.8, allocator 4.8, array type 3.6, assignment 5.2, attribute 4.1.4,
     attribute designator 4.1.4, base type 3.3, basic operation 3.3.3, collection 3.8, constrained array
     subtype 3.6, conversion 4.6, designate 3.8, designated subtype 3.8, designated type 3.8, discriminant
     3.3, indexed component 4.1.1, literal 4.2, membership test 4.5 4.5.2, object 3.2.1, operation 3.3,
     private type 7.4, qualified expression 4.7, record type 3.7, selected component 4.1.3, slice 4.1.2,
     subtype 3.3, task type 9.1, type 3.3 0

      section lrm-section3-9

     23.9. Declarative Parts

0     A declarative part contains declarative items (possibly none).

         declarative_part ::=
            {basic_declarative_item} {later_declarative_item}

         basic_declarative_item ::= basic_declaration
            | representation_clause | use_clause
         later_declarative_item ::= body 
            |  subprogram_declaration    | package_declaration
            |  task_declaration          | generic_declaration
            |  use_clause                 |generic_instantiation

         body ::= proper_body | body_stub

         proper_body ::= subprogram_body | package_body | task_body

     The elaboration of a declarative part consists of the elaboration of the declarative items, if any, in
     the order in which they are given in the declarative part.  After its elaboration, a declarative item is
     said to be 6elaborated.0 Prior to the completion of its elaboration (including before the elaboration),
     the declarative item is not yet elaborated.

     For several forms of declarative item, the language rules (in particular scope and visibility rules) are
     such that it is either impossible or illegal to use an entity before the elaboration of the declarative
     item that declares this entity.  For example, it is not possible to use the name of a type for an object
     declaration if the corresponding type declaration is not yet elaborated.  In the case of bodies, the
     following checks are performed:

        - For a subprogram call, a check is made that the body of the subprogram is already elaborated.

        - For the activation of a task, a check is made that the body of the corresponding task unit is
          already elaborated.

        - For the instantiation of a generic unit that has a body, a check is made that this body is
          already elaborated.

     The exception PROGRAM_ERROR is raised if any of these checks fails.

     If a subprogram declaration, a package declaration, a task declaration, or a generic declaration is a
     declarative item of a given declarative part, then the body (if there is one) of the program unit
     declared by the declarative item must itself be a declarative item of this declarative part (and must
     appear later).  If the body is a body stub, then a separately compiled subunit containing the
     corresponding proper body is required for the program unit (see 10.2).

     6References:0 4 activation 9.3, instantiation 12.3, program_error exception 11.1, scope 8.2,
     subprogram call 6.4, type 3.3, visibility 8.3 3.1, component declaration 3.7, deferred constant declaration
     7.4.3, discriminant specification 3.7.1, entry declaration 9.5, enumeration literal specification 3.5.1,
     generic declaration 12.1, generic instantiation 12.3, incomplete type declaration 3.8.1, loop parameter
     specification 5.5, number declaration 3.2.2, object declaration 3.2.1, package declaration 7.2, parameter
     specification 6.1, private type declaration 7.4.1, renaming declaration 8.5, subprogram declaration 6.1,
     subtype declaration 3.3.2, task declaration 9.1, type declaration 3.3.1, access type definition 3.8, array type
     definition 3.6, derived type definition 3.4, enumeration type definition 3.5.1, integer type definition
     3.5.4, real type definition 3.5.6, record type definition 3.7 context clause 10.1, body stub 10.2, compilation unit
     10.1, discriminant part 3.7.1, generic body 12.2, generic formal parameter 12.1 12.3, library unit 10.5,
     package body 7.1, representation clause 13.1, subprogram body 6.3, subunit 10.2, task body 9.1, task
     object 9.2, task specification 9.1, use clause 8.4, with clause 10.1.1 0

      chapter lrm-chapter-4



                                             14. Names and Expressions

0     The rules applicable to the different forms of name and expression, and to their evaluation, are given in
     this chapter.

      section lrm-section4-1

     24.1. Names

0     Names can denote declared entities, whether declared explicitly or implicitly (see 3.1).  Names can also
     denote objects designated by access values; subcomponents and slices of objects and values; single
     entries, entry families, and entries in families of entries.  Finally, names can denote attributes of any
     of the foregoing.

         name ::= simple_name
            | character_literal   | operator_symbol
            | indexed_component   | slice
            | selected_component  | attribute

         simple_name ::= identifier

         prefix ::= name | function_call

     A simple name for an entity is either the identifier associated with the entity by its declaration, or
     another identifier associated with the entity by a renaming declaration.

     Certain forms of name (indexed and selected components, slices, and attributes) include a 6prefix0 that
     is either a name or a function call.  If the type of a prefix is an access type, then the prefix must not
     be a name that denotes a formal parameter of mode 1out0 or a subcomponent thereof.

     If the prefix of a name is a function call, then the name denotes a component, a slice, an attribute, an
     entry, or an entry family, either of the result of the function call, or (if the result is an access
     value) of the object designated by the result.

     A prefix is said to be 6appropriate0 6for0 6a0 6type0 in either of the following cases:

        - The type of the prefix is the type considered.

        - The type of the prefix is an access type whose designated type is the type considered.

     The evaluation of a name determines the entity denoted by the name.  This evaluation has no other effect
     for a name that is a simple name, a character literal, or an operator symbol.

     The evaluation of a name that has a prefix includes the evaluation of the prefix, that is, of the
     corresponding name or function call.  If the type of the prefix is an access type, the evaluation of the
     prefix includes the determination of the object designated by the corresponding access value; the
     exception CONSTRAINT_ERROR is raised if the value of the prefix is a null access value, except in the
     case of the prefix of a representation attribute (see 13.7.2).

     6Examples0 6of0 6simple0 6names:

0         PI            6--  the simple name of a number       0        6(see 3.2.2)
0         LIMIT       6--  the simple name of a constant        0      6(see 3.2.1)
0         COUNT    6--  the simple name of a scalar variable       0 6(see 3.2.1)
0         BOARD     6--  the simple name of an array variable       (see 3.6.1)
0         MATRIX    6--  the simple name of a type         0          6(see 3.6)
0         RANDOM   6--  the simple name of a function        0       6(see 6.1)
0         ERROR     6--  the simple name of an exception         0   6(see 11.1)

0     6References:0 4 access type 3.8, access value 3.8, attribute 4.1.4, belong to a type 3.3, character
     literal 2.5, component 3.3, constraint_error exception 11.1, declaration 3.1, designate 3.8, designated
     type 3.8, entity 3.1, entry 9.5, entry family 9.5, evaluation 4.5, formal parameter 6.1, function call
     6.4, identifier 2.3, indexed component 4.1.1, mode 6.1, null access value 3.8, object 3.2.1, operator
     symbol 6.1, raising of exceptions 11, renaming declarations 8.5, selected component 4.1.3, slice 4.1.2,
     subcomponent 3.3, type 3.3 0

      subsection lrm-section4-1-1



     74.1.1. Indexed Components

0     An indexed component denotes either a component of an array or an entry in a family of entries.

         indexed_component ::= prefix(expression {, expression})

     In the case of a component of an array, the prefix must be appropriate for an array type.  The
     expressions specify the index values for the component; there must be one such expression for each index
     position of the array type.  In the case of an entry in a family of entries, the prefix must be a name
     that denotes an entry family of a task object, and the expression (there must be exactly one) specifies
     the index value for the individual entry.

     Each expression must be of the type of the corresponding index.  For the evaluation of an indexed
     component, the prefix and the expressions are evaluated in some order that is not defined by the
     language.  The exception CONSTRAINT_ERROR is raised if an index value does not belong to the range of the
     corresponding index of the prefixing array or entry family.

     6Examples0 6of0 6indexed0 6components:

0         MY_SCHEDULE(SAT)      6--  a component of a one-dimensional array      (see 3.6.1)
0         PAGE(10)     6--  a component of a one-dimensional array      (see 3.6)
0         BOARD(M, J + 1)       6--  a component of a two-dimensional array      (see 3.6.1)
0         PAGE(10)(20)       6--  a component of a component      (see 3.6)
0         REQUEST(MEDIUM)       6--  an entry in a family of entries    (see 9.5)
0         NEXT_FRAME(L)(M, N)      6--  a component of a function call     (see 6.1)

0     6Notes0 6on0 6the0 6examples:

0     Distinct notations are used for components of multidimensional arrays (such as BOARD) and arrays of
     arrays (such as PAGE).  The components of an array of arrays are arrays and can therefore be indexed.
     Thus PAGE(10)(20) denotes the 20th component of PAGE(10).  In the last example NEXT_FRAME(L) is a
     function call returning an access value which designates a two-dimensional array.

     6References:0 4 appropriate for a type 4.1, array type 3.6, component 3.3, component of an array 3.6,
     constraint_error exception 11.1, dimension 3.6, entry 9.5, entry family 9.5, evaluation 4.5, expression
     4.4, function call 6.4, in some order 1.6, index 3.6, name 4.1, prefix 4.1, raising of exceptions 11,
     returned value 5.8 6.5, task object 9.20

      subsection lrm-section4-1-2



     74.1.2. Slices

0     A slice denotes a one-dimensional array formed by a sequence of consecutive components of a
     one-dimensional array.  A slice of a variable is a variable; a slice of a constant is a constant; a slice
     of a value is a value.

         slice ::= prefix(discrete_range)

     The prefix of a slice must be appropriate for a one-dimensional array type.  The type of the slice is the
     base type of this array type.  The bounds of the discrete range define those of the slice and must be of
     the type of the index; the slice is a 6null0 6slice0 denoting a null array if the discrete range is a
     null range.

     For the evaluation of a name that is a slice, the prefix and the discrete range are evaluated in some
     order that is not defined by the language.  The exception CONSTRAINT_ERROR is raised by the evaluation of
     a slice, other than a null slice, if any of the bounds of the discrete range does not belong to the index
     range of the prefixing array.  (The bounds of a null slice need not belong to the subtype of the index.)

     6Examples0 6of0 6slices:

0         STARS(1 .. 15)                   6--  a slice of 15 characters              0     6(see 3.6.3)
0         PAGE(10 .. 10 + SIZE)          6--  a slice of 1 + SIZE components           (see 3.6 and 3.2.1)
0         PAGE(L)(A .. B)                   6--  a slice of the array PAGE(L)           0  6(see 3.6)
0         STARS(1 .. 0)                    6--  a null slice             0                     6(see 3.6.3)
0         MY_SCHEDULE(WEEKDAY)    6--  bounds given by subtype           0       6(see 3.6 and 3.5.1)
0         STARS(5 .. 15)(K)               6--  same as STARS(K)             0           6(see 3.6.3)
0                                             6--  provided that K is in 5 .. 15

0     6Notes:

0     For a one-dimensional array A, the name A(N .. N) is a slice of one component; its type is the base type
     of A. On the other hand, A(N) is a component of the array A and has the corresponding component type.

     6References:0 4 appropriate for a type 4.1, array 3.6, array type 3.6, array value 3.8, base type 3.3,
     belong to a subtype 3.3, bound of a discrete range 3.6.1, component 3.3, component type 3.3, constant
     3.2.1, constraint 3.3, constraint_error exception 11.1, dimension 3.6, discrete range 3.6, evaluation
     4.5, index 3.6, index range 3.6, name 4.1, null array 3.6.1, null range 3.5, prefix 4.1, raising of
     exceptions 11, type 3.3, variable 3.2.10

      subsection lrm-section4-1-3



     74.1.3. Selected Components

0     Selected components are used to denote record components, entries, entry families, and objects designated
     by access values; they are also used as 6expanded0 6names0 as described below.

         selected_component ::= prefix.selector

         selector ::= simple_name
            | character_literal | operator_symbol | 1all

0     The following four forms of selected components are used to denote a discriminant, a record component, an
     entry, or an object designated by an access value:

        - A discriminant:

        - The selector must be a simple name denoting a discriminant of an object or value.  The prefix
          must be appropriate for the type of this object or value.

        - A component of a record:

        - The selector must be a simple name denoting a component of a record object or value.  The
          prefix must be appropriate for the type of this object or value.

        - For a component of a variant, a check is made that the values of the discriminants are such
          that the record has this component.  The exception CONSTRAINT_ERROR is raised if this check
          fails.

        - A single entry or an entry family of a task:

        - The selector must be a simple name denoting a single entry or an entry family of a task.  The
          prefix must be appropriate for the type of this task.

        - An object designated by an access value:

        - The selector must be the reserved word 1all.0 The value of the prefix must belong to an
          access type.

     A selected component of one of the remaining two forms is called an 6expanded0 6name.0 In each case
     the selector must be either a simple name, a character literal, or an operator symbol.  A function call
     is not allowed as the prefix of an expanded name.  An expanded name can denote:
        - An entity declared in the visible part of a package:

        - The prefix must denote the package.  The selector must be the simple name, character literal,
          or operator symbol of the entity.

        - An entity whose declaration occurs immediately within a named construct:

        - The prefix must denote a construct that is either a program unit, a block statement, a loop
          statement, or an accept statement.  In the case of an accept statement, the prefix must be
          either the simple name of the entry or entry family, or an expanded name ending with such a
          simple name (that is, no index is allowed).  The selector must be the simple name, character
          literal, or operator symbol of an entity whose declaration occurs immediately within the
          construct.

        - This form of expanded name is only allowed within the construct itself (including the body and
          any subunits, in the case of a program unit).  A name declared by a renaming declaration is not
          allowed as the prefix.  If the prefix is the name of a subprogram or accept statement and if
          there is more than one visible enclosing subprogram or accept statement of this name, the
          expanded name is ambiguous, independently of the selector.

     If, according to the visibility rules, there is at least one possible interpretation of the prefix of a
     selected component as the name of an enclosing subprogram or accept statement, then the only
     interpretations considered are those of rule (f), as expanded names (no interpretations of the prefix as
     a function call are then considered).

     The evaluation of a name that is a selected component includes the evaluation of the prefix.

     6Examples0 6of0 6selected0 6components:

0         TOMORROW.MONTH        6--  a record component         0                    6(see 3.7)
0         NEXT_CAR.OWNER          6--  a record component              0               6(see 3.8.1)
0         NEXT_CAR.OWNER.AGE     6--  a record component          0                  6(see 3.8.1)
0         WRITER.UNIT                 6--  a record component (a discriminant)       0 6 (see 3.7.3)
0         MIN_CELL(H).VALUE         6--  a record component of the result     0        6(see 6.1 and 3.8.1)
0                                         6--  of the function call MIN_CELL(H)                      

0         CONTROL.SEIZE            6--  an entry of the task CONTROL             0    6(see 9.1 and 9.2)
0         POOL(K).WRITE              6--  an entry of the task POOL(K)             0     6(see 9.1 and 9.2)

0         NEXT_CAR.all               6--  the object designated by
0                                        6--  the access variable NEXT_CAR  (see 3.8.1)

0     6Examples0 6of0 6expanded0 6names:

0         TABLE_MANAGER.INSERT   6--  a procedure of the visible part of a package      (see 7.5)
0         KEY_MANAGER."<"            6--  an operator of the visible part of a package   0   6(see 7.4.2)

0         DOT_PRODUCT.SUM         6--  a variable declared in a procedure body       0    6(see 6.5)
0         BUFFER.POOL                  6--  a variable declared in a task unit         0         6(see 9.12)
0         BUFFER.READ                  6--  an entry of a task unit                    0          6(see 9.12)
0         SWAP.TEMP                    6--  a variable declared in a block statement     0     6(see 5.6)
0         STANDARD.BOOLEAN         6--  the name of a predefined type        0            6 (see 8.6 and C)

0     6Note:

0     For a record with components that are other records, the above rules imply that the simple name must be
     given at each level for the name of a subcomponent.  For example, the name NEXT_CAR.OWNER.BIRTH.MONTH
     cannot be shortened (NEXT_CAR.OWNER.MONTH is not allowed).

     6References:0 4 accept statement 9.5, access type 3.8, access value 3.8, appropriate for a type 4.1,
     block statement 5.6, body of a program unit 3.9, character literal 2.5, component of a record 3.7,
     constraint_error exception 11.1, declaration 3.1, designate 3.8, discriminant 3.3, entity 3.1, entry 9.5,
     entry family 9.5, function call 6.4, index 3.6, loop statement 5.5, object 3.2.1, occur immediately
     within 8.1, operator 4.5, operator symbol 6.1, overloading 8.3, package 7, predefined type C, prefix 4.1,
     procedure body 6.3, program unit 6, raising of exceptions 11, record 3.7, record component 3.7, renaming
     declaration 8.5, reserved word 2.9, simple name 4.1, subprogram 6, subunit 10.2, task 9, task object 9.2,
     task unit 9, variable 3.7.3, variant 3.7.3, visibility 8.3, visible part 3.7.30

      subsection lrm-section4-1-4



     74.1.4. Attributes

0     An attribute denotes a basic operation of an entity given by a prefix.

         attribute ::= prefix'attribute_designator

         attribute_designator ::= simple_name [(6universal0_6static0_expression)]

     The applicable attribute designators depend on the prefix.  An attribute can be a basic operation
     delivering a value; alternatively it can be a function, a type, or a range.  The meaning of the prefix of
     an attribute must be determinable independently of the attribute designator and independently of the fact
     that it is the prefix of an attribute.

     The attributes defined by the language are summarized in Annex A. In addition, an implementation may
     provide implementation-defined attributes; their description must be given in Appendix F. The attribute
     designator of any implementation-defined attribute must not be the same as that of any language-defined
     attribute.

     The evaluation of a name that is an attribute consists of the evaluation of the prefix.

     6Notes:

0     The attribute designators DIGITS, DELTA, and RANGE have the same identifier as a reserved word.  However,
     no confusion is possible since an attribute designator is always preceded by an apostrophe.  The only
     predefined attribute designators that have a universal expression are those for certain operations of
     array types (see 3.6.2).

     6Examples0 6of0 6attributes:

0         COLOR'FIRST             6-- Minimum value of the enumeration type COLOR   (see 3.3.1  and 3.5)
0         RAINBOW'BASE'FIRST    6-- Same as COLOR'FIRST   0                            6(see 3.3.2  and 3.3.3)
0         REAL'DIGITS               6-- Precision of the type REAL  0                       6(see 3.5.7  and 3.5.8)
0         BOARD'LAST(2)           6-- Upper bound of the second dimension of BOARD (see 3.6.1  and 3.6.2)
0         BOARD'RANGE(1)         6-- Index range of the first dimension of BOARD   0  6(see 3.6.1  and 3.6.2)
0         POOL(K)'TERMINATED   6-- TRUE if task POOL(K) is terminated   0           6(see 9.2    and 9.9)
0         DATE'SIZE                 6-- Number of bits for records of type DATE    0    6(see 3.7    and 13.7.2)
0         MESSAGE'ADDRESS      6-- Address of the record variable message  0        6(see 3.7.2  and 13.7.2)

0     6References:0 4 appropriate for a type 4.1, basic operation 3.3.3, declared entity 3.1, name 4.1,
     prefix 4.1, reserved word 2.9, simple name 4.1, static expression 4.9, type 3.3, universal expression
     4.100

      section lrm-section4-2

     24.2. Literals

0     A literal is either a numeric literal, an enumeration literal, the literal 1null,0 or a string literal.
     The evaluation of a literal yields the corresponding value.

     Numeric literals are the literals of the types 6universal0_6integer0 and 6universal0_6real.
0     Enumeration literals include character literals and yield values of the corresponding enumeration types.
     The literal 1null0 yields a null access value which designates no objects at all.

     A string literal is a basic operation that combines a sequence of characters into a value of a
     one-dimensional array of a character type; the bounds of this array are determined according to the rules
     for positional array aggregates (see 4.3.2).  For a null string literal, the upper bound is the
     predecessor, as given by the PRED attribute, of the lower bound.  The evaluation of a null string literal
     raises the exception CONSTRAINT_ERROR if the lower bound does not have a predecessor (see 3.5.5).

     The type of a string literal and likewise the type of the literal 1null0 must be determinable solely
     from the context in which this literal appears, excluding the literal itself, but using the fact that the
     literal 1null0 is a value of an access type, and similarly that a string literal is a value of a
     one-dimensional array type whose component type is a character type.

     The character literals corresponding to the graphic characters contained within a string literal must be
     visible at the place of the string literal (although these characters themselves are not used to
     determine the type of the string literal).

     6Examples:

0         3.14159_26536    6--  a real literal
0         1_345               6--  an integer literal
0         CLUBS               6--  an enumeration literal
0         'A'                    6--  a character literal
0         "SOME TEXT"      6--  a string literal

0     6References:0 4 access type 3.8, aggregate 4.3, array 3.6, array bound 3.6, array type 3.6, character
     literal 2.5, character type 3.5.2, component type 3.3, constraint_error exception 11.1, designate 3.8,
     dimension 3.6, enumeration literal 3.5.1, graphic character 2.1, integer literal 2.4, null access value
     3.8, null literal 3.8, numeric literal 2.4, object 3.2.1, real literal 2.4, string literal 2.6, type 3.3,
     universal_integer type 3.5.4, universal_real type 3.5.6, visibility 8.30

      section lrm-section4-3

     24.3. Aggregates

0     An aggregate is a basic operation that combines component values into a composite value of a record or
     array type.

         aggregate ::=
            (component_association   {, component_association})

         component_association ::=
            [choice {| choice} => ] expression

     Each component association associates an expression with components (possibly none).  A component
     association is said to be 6named0 if the components are specified explicitly by choices; it is
     otherwise said to be 6positional.0 For a positional association, the (single) component is implicitly
     specified by position, in the order of the corresponding component declarations for record components, in
     index order for array components.

     Named associations can be given in any order (except for the choice 1others0), but if both positional
     and named associations are used in the same aggregate, then positional associations must occur first, at
     their normal position.  Hence once a named association is used, the rest of the aggregate must use only
     named associations.  Aggregates containing a single component association must always be given in named
     notation.  Specific rules concerning component associations exist for record aggregates and array
     aggregates.

     Choices in component associations have the same syntax as in variant parts (see 3.7.3).  A choice that is
     a component simple name is only allowed in a record aggregate.  For a component association, a choice
     that is a simple expression or a discrete range is only allowed in an array aggregate; a choice that is a
     simple expression specifies the component at the corresponding index value; similarly a discrete range
     specifies the components at the index values in the range.  The choice 1others0 is only allowed in a
     component association if the association appears last and has this single choice; it specifies all
     remaining components, if any.

     Each component of the value defined by an aggregate must be represented once and only once in the
     aggregate.  Hence each aggregate must be complete and a given component is not allowed to be specified by
     more than one choice.

     The type of an aggregate must be determinable solely from the context in which the aggregate appears,
     excluding the aggregate itself, but using the fact that this type must be composite and not limited.  The
     type of an aggregate in turn determines the required type for each of its components.

     6Notes:

0     The above rule implies that the determination of the type of an aggregate cannot use any information from
     within the aggregate.  In particular, this determination cannot use the type of the expression of a
     component association, or the form or the type of a choice.  An aggregate can always be distinguished
     from an expression enclosed by parentheses:  this is a consequence of the fact that named notation is
     required for an aggregate with a single component.

     6References:0 4 array aggregate 4.3.2, array type 3.6, basic operation 3.3.3, choice 3.7.3, component
     3.3, composite type 3.3, composite value 3.3, discrete range 3.6, expression 4.4, index 3.6, limited type
     7.4.4, primary 4.4, record aggregate 4.3.1, record type 3.7, simple expression 4.4, simple name 4.1, type
     3.3, variant part 3.7.30

      subsection lrm-section4-3-1



     74.3.1. Record Aggregates

0     If the type of an aggregate is a record type, the component names given as choices must denote components
     (including discriminants) of the record type.  If the choice 1others0 is given as a choice of a record
     aggregate, it must represent at least one component.  A component association with the choice 1others
0     or with more than one choice is only allowed if the represented components are all of the same type.  The
     expression of a component association must have the type of the associated record components.

     The value specified for a discriminant that governs a variant part must be given by a static expression
     (note that this value determines which dependent components must appear in the record value).

     For the evaluation of a record aggregate, the expressions given in the component associations are
     evaluated in some order that is not defined by the language.  The expression of a named association is
     evaluated once for each associated component.  A check is made that the value of each subcomponent of the
     aggregate belongs to the subtype of this subcomponent.  The exception CONSTRAINT_ERROR is raised if this
     check fails.

     6Example0 6of0 6a0 6record0 6aggregate0 6with0 6positional0 6associations:

0         (4, JULY, 1776)                         --  see 3.7

     6Examples0 6of0 6record0 6aggregates0 6with0 6named0 6associations:

0         (DAY => 4, MONTH => JULY, YEAR => 1776)
         (MONTH => JULY, DAY => 4, YEAR => 1776)

         (DISK, CLOSED, TRACK => 5, CYLINDER => 12)          6--  see 3.7.3
0         (UNIT => DISK, STATUS => CLOSED, CYLINDER => 9, TRACK => 1)

     6Example0 6of0 6component0 6association0 6with0 6several0 6choices:

0         (VALUE => 0, SUCC|PRED => 1new0 CELL'(0, 1null0, 1null0))        6--  see 3.8.1
0         6--  The allocator is evaluated twice:  SUCC and PRED designate different cells

0     6Note:

0     For an aggregate with positional associations, discriminant values appear first since the discriminant
     part is given first in the record type declaration; they must be in the same order as in the discriminant
     part.

     6References:0 4 aggregate 4.3, allocator 4.8, choice 3.7.3, component association 4.3, component name
     3.7, constraint 3.3, constraint_error exception 11.1, depend on a discriminant 3.7.1, discriminant 3.3,
     discriminant part 3.7.1, evaluate 4.5, expression 4.4, in some order 1.6, program 10, raising of
     exceptions 11, record component 3.7, record type 3.7, satisfy 3.3, static expression 4.9, subcomponent
     3.3, subtype 3.3.2, type 3.3, variant part 3.7.30

      subsection lrm-section4-3-2



     74.3.2. Array Aggregates

0     If the type of an aggregate is a one-dimensional array type, then each choice must specify values of the
     index type, and the expression of each component association must be of the component type.  }

     If the type of an aggregate is a multidimensional array type, an n-dimensional aggregate is written as a
     one-dimensional aggregate, in which the expression specified for each component association is itself
     written as an (n-1)-dimensional aggregate which is called a 6subaggregate;0 the index subtype of the
     one-dimensional aggregate is given by the first index position of the array type.  The same rule is used
     to write a subaggregate if it is again multidimensional, using successive index positions.  A string
     literal is allowed in a multidimensional aggregate at the place of a one-dimensional array of a character
     type.  In what follows, the rules concerning array aggregates are formulated in terms of one-dimensional
     aggregates.

     Apart from a final component association with the single choice 1others0, the rest (if any) of the
     component associations of an array aggregate must be either all positional or all named.  A named
     association of an array aggregate is only allowed to have a choice that is not static, or likewise a
     choice that is a null range, if the aggregate includes a single component association and this component
     association has a single choice.  An 1others0 choice is static if the applicable index constraint is
     static.

     The bounds of an array aggregate that has an 1others0 choice are determined by the applicable index
     constraint.  An 1others0 choice is only allowed if the aggregate appears in one of the following
     contexts (which defines the applicable index constraint):

        - The aggregate is an actual parameter, a generic actual parameter, the result expression of a
          function, or the expression that follows an assignment compound delimiter.  Moreover, the
          subtype of the corresponding formal parameter, generic formal parameter, function result, or
          object is a constrained array subtype.

        - For an aggregate that appears in such a context and contains an association with an 1others
0          choice, named associations are allowed for other associations only in the case of a
          (nongeneric) actual parameter or function result.  If the aggregate is a multidimensional
          array, this restriction also applies to each of its subaggregates.

        - The aggregate is the operand of a qualified expression whose type mark denotes a constrained
          array subtype.

        - The aggregate is the expression of the component association of an enclosing (array or record)
          aggregate.  Moreover, if this enclosing aggregate is a multidimensional array aggregate then it
          is itself in one of these three contexts.

     The bounds of an array aggregate that does not have an 1others0 choice are determined as follows.  For
     an aggregate that has named associations, the bounds are determined by the smallest and largest choices
     given.  For a positional aggregate, the lower bound is determined by the applicable index constraint if
     the aggregate appears in one of the contexts (a) through (c); otherwise, the lower bound is given by
     S'FIRST where S is the index subtype; in either case, the upper bound is determined by the number of
     components.

     The evaluation of an array aggregate that is not a subaggregate proceeds in two steps.  First, the
     choices of this aggregate and of its subaggregates, if any, are evaluated in some order that is not
     defined by the language.  Second, the expressions of the component associations of the array aggregate
     are evaluated in some order that is not defined by the language; the expression of a named association is
     evaluated once for each associated component.  The evaluation of a subaggregate consists of this second
     step (the first step is omitted since the choices have already been evaluated).

     For the evaluation of an aggregate that is not a null array, a check is made that the index values
     defined by choices belong to the corresponding index subtypes, and also that the value of each
     subcomponent of the aggregate belongs to the subtype of this subcomponent.  For an n-dimensional
     multidimensional aggregate, a check is made that all (n-1)-dimensional subaggregates have the same
     bounds.  The exception CONSTRAINT_ERROR is raised if any of these checks fails.

     6Note:

0     The allowed contexts for an array aggregate including an 1others0 choice are such that the bounds of
     such an aggregate are always known from the context.

     6Examples0 6of0 6array0 6aggregates0 6with0 6positional0 6associations:

0         (7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
         TABLE'(5, 8, 4, 1, 1others0 => 0)  --  see 3.6

     6Examples0 6of0 6array0 6aggregates0 6with0 6named0 6associations:

0         (1 .. 5 => (1 .. 8 => 0.0))        --  two-dimensional
         (1 .. N => 1new0 CELL)        --  N new cells, in particular for N = 0

         TABLE'(2 | 4 | 10 =>  1, 1others   0 => 0)
         SCHEDULE'(MON .. FRI  => TRUE,    1others0 => FALSE)     --  see 3.6
         SCHEDULE'(WED | SUN   => FALSE,   1others0 => TRUE)

     6Examples0 6of0 6two-dimensional0 6array0 6aggregates:

0         -- Three aggregates for the same value of type MATRIX (see 3.6):

         ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3))
         (1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3))
         (1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))

     6Examples0 6of0 6aggregates0 6as0 6initial0 6values:

0         A   :  TABLE := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0);  -- A(1)=7,  A(10)=0
         B   :  TABLE := TABLE'(2 | 4 | 10 => 1, 1others0 => 0);    -- B(1)=0,  B(10)=1
         C   :  1constant0 MATRIX := (1 .. 5 => (1 .. 8 => 0.0));   -- C'FIRST(1)=1, C'LAST(2)=8

         D   :  BIT_VECTOR(M .. N) := (M .. N    => TRUE);  -- SEE 3.6
         E   :  BIT_VECTOR(M .. N) := (1others0   => TRUE);
         F   :  STRING(1 .. 1) := (1 => 'F');  -- A ONE COMPONENT AGGREGATE: SAME AS "F"

     6References:0 4 actual parameter 6.4.1, aggregate 4.3, array type 3.6, assignment compound delimiter
     5.2, choice 3.7.3, component 3.3, component association 4.3, component type 3.3, constrained array
     subtype 3.6, constraint 3.3, constraint_error exception 11.1, dimension 3.6, evaluate 4.5, expression
     4.4, formal parameter 6.1, function 6.5, in some order 1.6, index constraint 3.6.1, index range 3.6,
     index subtype 3.6, index type 3.6, named component association 4.3, null array 3.6.1, object 3.2,
     positional component association 4.3, qualified expression 4.7, raising of exceptions 11, static
     expression 4.9, subcomponent 3.3, type 3.30

      section lrm-section4-4

     24.4. Expressions

0     An expression is a formula that defines the computation of a value.

         expression ::=
             relation {1and0 relation}   | relation {1and0 1then0 relation}
            |   relation {1or0 relation}    | relation {1or0 1else0 relation}
            |   relation {1xor0 relation}

         relation ::=
             simple_expression [relational_operator simple_expression]
            |   simple_expression [1not0] 1in0 range
            |   simple_expression [1not0] 1in0 type_mark

         simple_expression ::= [unary_adding_operator] term {binary_adding_operator term}

         term ::= factor {multiplying_operator factor}

         factor ::= primary [** primary] | 1abs0 primary | 1not0 primary
         primary ::=
             numeric_literal | 1null0 | aggregate | string_literal | name | allocator
            |   function_call | type_conversion | qualified_expression | (expression)

     Each primary has a value and a type.  The only names allowed as primaries are named numbers; attributes
     that yield values; and names denoting objects (the value of such a primary is the value of the object) or
     denoting values.  Names that denote formal parameters of mode 1out0 are not allowed as primaries; names
     of their subcomponents are only allowed in the case of discriminants.

     The type of an expression depends only on the type of its constituents and on the operators applied; for
     an overloaded constituent or operator, the determination of the constituent type, or the identification
     of the appropriate operator, depends on the context.  For each predefined operator, the operand and
     result types are given in section 4.5.

     6Examples0 6of0 6primaries:

0         4.0                       --  real literal
         PI                         --  named number
         (1 .. 10 => 0)            --  array aggregate
         SUM                     --  variable
         INTEGER'LAST         --  attribute
         SINE(X)                  --  function call
         COLOR'(BLUE)          --  qualified expression
         REAL(M*N)              --  conversion
         (LINE_COUNT + 10)   --  parenthesized expression

     6Examples0 6of0 6expressions:

0         VOLUME   			--  primary
         1not0 DESTROYED		--  factor
         2*LINE_COUNT		--  term
         -4.0     			   --  simple expression
         -4.0 + A    			   --  simple expression
         B**2 - 4.0*A*C		   --  simple expression
         PASSWORD(1 .. 3) = "BWV"      --  relation
         COUNT 1in0 SMALL_INT           --  relation
         COUNT 1not0 1in0 SMALL_INT      --  relation
         INDEX = 0 1or0 ITEM_HIT                  --  expression
         (COLD 1and0 SUNNY) 1or0 WARM          --  expression (parentheses are required)
         A**(B**C)			              --  expression (parentheses are required)

     6References:0 4 aggregate 4.3, allocator 4.8, array aggregate 4.3.2, attribute 4.1.4, binary adding
     operator 4.5 4.5.3, context of overload resolution 8.7, exponentiating operator 4.5 4.5.6, function call
     6.4, multiplying operator 4.5 4.5.5, name 4.1, named number 3.2, null literal 3.8, numeric literal 2.4,
     object 3.2, operator 4.5, overloading 8.3, overloading an operator 6.7, qualified expression 4.7, range
     3.5, real literal 2.4, relation 4.5.1, relational operator 4.5 4.5.2, result type 6.1, string literal
     2.6, type 3.3, type conversion 4.6, type mark 3.3.2, unary adding operator 4.5 4.5.4, variable 3.2.10

      section lrm-section4-5

     24.5. Operators and Expression Evaluation

0     The language defines the following six classes of operators.  The corresponding operator symbols (except
     /=), and only those, can be used as designators in declarations of functions for user-defined operators.
     They are given in the order of increasing precedence.

         logical_operator                    ::=  1and   0 | 1or   0 | 1xor  

0         relational_operator                ::=   =       | /=     | <     | <=     | >     | >=

         binary_adding_operator           ::=   +      | -      | &

         unary_adding_operator            ::=   +      | -

         multiplying_operator                ::=   *      | /      | 1mod 0 | 1rem
0         highest_precedence_operator     ::=   **     | 1abs 0  | 1not

0     The short-circuit control forms 1and0 1then0 and 1or0 1else0 have the same precedence as logical
     operators.  The membership tests 1in0 and 1not0 1in0 have the same precedence as relational
     operators.

     For a term, simple expression, relation, or expression, operators of higher precedence are associated
     with their operands before operators of lower precedence.  In this case, for a sequence of operators of
     the same precedence level, the operators are associated in textual order from left to right; parentheses
     can be used to impose specific associations.

     The operands of a factor, of a term, of a simple expression, or of a relation, and the operands of an
     expression that does not contain a short-circuit control form, are evaluated in some order that is not
     defined by the language (but before application of the corresponding operator).  The right operand of a
     short-circuit control form is evaluated if and only if the left operand has a certain value (see 4.5.1).

     For each form of type declaration, certain of the above operators are 6predefined,0 that is, they are
     implicitly declared by the type declaration.  For each such implicit operator declaration, the names of
     the parameters are LEFT and RIGHT for binary operators; the single parameter is called RIGHT for unary
     adding operators and for the unary operators 1abs0 and 1not.0 The effect of the predefined operators
     is explained in subsections 4.5.1 through 4.5.7.

     The predefined operations on integer types either yield the mathematically correct result or raise the
     exception NUMERIC_ERROR.  A predefined operation that delivers a result of an integer type (other than
     6universal0_[integer]) can only raise the exception NUMERIC_ERROR if the mathematical result is not a
     value of the type.  The predefined operations on real types yield results whose accuracy is defined in
     section 4.5.7.  A predefined operation that delivers a result of a real type (other than
     6universal0_[real]) can only raise the exception NUMERIC_ERROR if the result is not within the range of
     the safe numbers of the type, as explained in section 4.5.7.

     6Examples0 6of0 6precedence:

0         1not0 SUNNY 1or0 WARM    6--  same as (1not0 SUNNY) 1or0 WARM
         X > 4.0 1and0 Y > 0.0      6--  same as (X > 4.0) 1and0 (Y > 0.0)

         -4.0*A**2                 6--  same as -(4.0 * (A**2))
0         1abs0(1 + A) + B           6--  same as (1abs0 (1 + A)) + B
         Y**(-3)                   6--  parentheses are necessary
0         A / B * C                6--  same as (A/B)*C
0         A + (B + C)              6--  evaluate B + C before adding it to A

0     6References:0 4 designator 6.1, expression 4.4, factor 4.4, implicit declaration 3.1, in some order
     1.6, integer type 3.5.4, membership test 4.5.2, name 4.1, numeric_error exception 11.1, overloading 6.6
     8.7, raising of an exception 11, range 3.5, real type 3.5.6, relation 4.4, safe number 3.5.6,
     short-circuit control form 4.5 4.5.1, simple expression 4.4, term 4.4, type 3.3, type declaration 3.3.1,
     universal0_4integer type 3.5.4, universal0_4real type 3.5.60

      subsection lrm-section4-5-1



     74.5.1. Logical Operators and Short-circuit Control Forms

0     The following logical operators are predefined for any boolean type and any one-dimensional array type
     whose components are of a boolean type; in either case the two operands have the same type.

6         Operator    Operation                 Operand type                  0   6Result type

0         1and0         conjunction              any boolean type                  same boolean type
                                                 array of boolean components    same array type

         1or0          inclusive disjunction     any boolean type                  same boolean type
                                                 array of boolean components    same array type

         1xor0         exclusive disjunction    any boolean type                  same boolean type
                                                 array of boolean components    same array type
     The operations on arrays are performed on a component-by-component basis on matching components, if any
     (as for equality, see 4.5.2).  The bounds of the resulting array are those of the left operand.  A check
     is made that for each component of the left operand there is a matching component of the right operand,
     and vice versa.  The exception CONSTRAINT_ERROR is raised if this check fails.

     The short-circuit control forms 1and0 1then0 and 1or0 1else0 are defined for two operands of a
     boolean type and deliver a result of the same type.  The left operand of a short-circuit control form is
     always evaluated first.  If the left operand of an expression with the control form 1and0 1then
0     evaluates to FALSE, the right operand is not evaluated and the value of the expression is FALSE.  If the
     left operand of an expression with the control form 1or0 1else0 evaluates to TRUE, the right operand
     is not evaluated and the value of the expression is TRUE.  If both operands are evaluated, 1and
0     1then0 delivers the same result as 1and,0 and 1or0 1else0 delivers the same result as 1or.

0     6Note:0 6The0 6conventional0 6meaning0 6of0 6the0 6logical0 6operators0 6is0 6given
0     6by0 6the0 6following0 6truth0 6table:

0         A          B        (A 1and0 B)     (A 1or0 B)       (A 1xor0 B)

         TRUE    TRUE    TRUE          TRUE          FALSE
         TRUE    FALSE   FALSE         TRUE          TRUE
         FALSE   TRUE    FALSE         TRUE          TRUE
         FALSE   FALSE   FALSE         FALSE         FALSE


     6Examples0 6of0 6logical0 6operators:

0         SUNNY 1or0 WARM
         FILTER(1 .. 10) 1and0 FILTER(15 .. 24)     --   see 3.6.1

     6Examples0 6of0 6short-circuit0 6control0 6forms:

0         NEXT_CAR.OWNER /= 1null0 1and0 1then0 NEXT_CAR.OWNER.AGE > 25     --   see 3.8.1
         N = 0 1or0 1else0 A(N) = HIT_VALUE

     6References:0 4 array type 3.6, boolean type 3.5.3, bound of an index range 3.6.1, component of an
     array 3.6, constraint_error exception 11.1, dimension 3.6, false boolean value 3.5.3, index subtype 3.6,
     matching components of arrays 4.5.2, null array 3.6.1, operation 3.3, operator 4.5, predefined operator
     4.5, raising of exceptions 11, true boolean value 3.5.3, type 3.3 0

      subsection lrm-section4-5-2



     74.5.2. Relational Operators and Membership Tests

0     The equality and inequality operators are predefined for any type that is not limited.  The other
     relational operators are the ordering operators < (less than), <= (less than or equal), > (greater than),
     and >= (greater than or equal).  The ordering operators are predefined for any scalar type, and for any
     discrete array type, that is, a one-dimensional array type whose components are of a discrete type.  The
     operands of each predefined relational operator have the same type.  The result type is the predefined
     type BOOLEAN.

     The relational operators have their conventional meaning:  the result is equal to TRUE if the
     corresponding relation is satisfied; the result is FALSE otherwise.  The inequality operator gives the
     complementary result to the equality operator:  FALSE if equal, TRUE if not equal.

         Operator    Operation                   Operand type          Result type

         = /=          equality and inequality     any type                BOOLEAN

         < <= > >=     test for ordering           any scalar type        BOOLEAN
                                                      discrete array type    BOOLEAN

     Equality for the discrete types is equality of the values.  For real operands whose values are 6nearly
0     equal, the results of the predefined relational operators are given in section 4.5.7.  Two access values
     are equal either if they designate the same object, or if both are equal to the null value of the access
     type.

     For two array values or two record values of the same type, the left operand is equal to the right
     operand if and only if for each component of the left operand there is a 6matching0 6component0 of
     the right operand and vice versa; and the values of matching components are equal, as given by the
     predefined equality operator for the component type.  In particular, two null arrays of the same type are
     always equal; two null records of the same type are always equal.

     For comparing two records of the same type, 6matching0 6components0 are those which have the same
     component identifier.

     For comparing two one-dimensional arrays of the same type, 6matching0 6components0 are those (if any)
     whose index values match in the following sense:  the lower bounds of the index ranges are defined to
     match, and the successors of matching indices are defined to match.  For comparing two multidimensional
     arrays, matching components are those whose index values match in successive index positions.

     If equality is explicitly defined for a limited type, it does not extend to composite types having
     subcomponents of the limited type (explicit definition of equality is allowed for such composite types).

     The ordering operators <, <=, >, and >= that are defined for discrete array types correspond to
     6lexicographic0 order using the predefined order relation of the component type.  A null array is
     lexicographically less than any array having at least one component.  In the case of nonnull arrays, the
     left operand is lexicographically less than the right operand if the first component of the left operand
     is less than that of the right; otherwise the left operand is lexicographically less than the right
     operand only if their first components are equal and the tail of the left operand is lexicographically
     less than that of the right (the tail consists of the remaining components beyond the first and can be
     null).

     The membership tests 1in0 and 1not0 1in0 are predefined for all types.  The result type is the
     predefined type BOOLEAN.  For a membership test with a range, the simple expression and the bounds of the
     range must be of the same scalar type; for a membership test with a type mark, the type of the simple
     expression must be the base type of the type mark.  The evaluation of the membership test 1in0 yields
     the result TRUE if the value of the simple expression is within the given range, or if this value belongs
     to the subtype denoted by the given type mark; otherwise this evaluation yields the result FALSE (for a
     value of a real type, see 4.5.7).  The membership test 1not0 1in0 gives the complementary result to
     the membership test 1in.

0     6Examples:

0         X /= Y

         "" < "A" 1and0 "A" < "AA"        6--  TRUE
0         "AA" < "B" 1and0 "A" < "A  "     6--  TRUE

0         MY_CAR = 1null0                   -- true 1if0 MY_CAR has been set to 1null   0 (SEE 3.8.1)
         MY_CAR = YOUR_CAR          -- true 1if0 we both share the same car
         MY_CAR.1all0 = YOUR_CAR.1all0    -- true 1if0 the two cars are identical

         N 1not0 1in0 1 .. 10           -- 1range0 membership test
         TODAY 1in0 MON .. FRI    -- 1range0 membership test
         TODAY 1in0 WEEKDAY    -- 1subtype0 membership test   (SEE 3.5.1)
         ARCHIVE 1in0 DISK_UNIT   -- 1subtype0 membership test   (SEE 3.7.3)

     6Notes:

0     No exception is ever raised by a predefined relational operator or by a membership test, but an exception
     can be raised by the evaluation of the operands.

     If a record type has components that depend on discriminants, two values of this type have matching
     components if and only if their discriminants are equal.  Two nonnull arrays have matching components if
     and only if the value of the attribute LENGTH(N) for each index position N is the same for both.

     6References:0 4 access value 3.8, array type 3.6, base type 3.3, belong to a subtype 3.3, boolean
     predefined type 3.5.3, bound of a range 3.5, component 3.3, component identifier 3.7, component type 3.3,
     composite type 3.3, designate 3.8, dimension 3.6, discrete type 3.5, evaluation 4.5, exception 11, index
     3.6, index range 3.6, limited type 7.4.4, null access value 3.8, null array 3.6.1, null record 3.7,
     object 3.2.1, operation 3.3, operator 4.5, predefined operator 4.5, raising of exceptions 11, range 3.5,
     record type 3.7, scalar type 3.5, simple expression 4.4, subcomponent 3.3, successor 3.5.5, type 3.3,
     type mark 3.3.20

      subsection lrm-section4-5-3



     74.5.3. Binary Adding Operators

0     The binary adding operators + and - are predefined for any numeric type and have their conventional
     meaning.  The catenation operators & are predefined for any one-dimensional array type that is not
     limited.

         Operator    Operation    Left operand type     Right operand type    Result type

         +            addition       any numeric type       same numeric type     same numeric type

         -            subtraction   any numeric type       same numeric type     same numeric type

         &            catenation   any array type          same array type        same array type
                                      any array type          the component type    same array type
                                      the component type    any array type          same array type
                                      the component type    the component type    any array type

     For real types, the accuracy of the result is determined by the operand type (see 4.5.7).

     If both operands are one-dimensional arrays, the result of the catenation is a one-dimensional array
     whose length is the sum of the lengths of its operands, and whose components comprise the components of
     the left operand followed by the components of the right operand.  The lower bound of this result is the
     lower bound of the left operand, unless the left operand is a null array, in which case the result of the
     catenation is the right operand.

     If either operand is of the component type of an array type, the result of the catenation is given by the
     above rules, using in place of this operand an array having this operand as its only component and having
     the lower bound of the index subtype of the array type as its lower bound.

     The exception CONSTRAINT_ERROR is raised by catenation if the upper bound of the result exceeds the range
     of the index subtype, unless the result is a null array.  This exception is also raised if any operand is
     of the component type but has a value that does not belong to the component subtype.

     6Examples:

0         Z + 0.1        6--  Z must be of a real type

0         "A" & "BCD"   6--  catenation of two string literals
0         'A' & "BCD"    6--  catenation of a character literal and a string literal
0         'A' & 'A'        6--  catenation of two character literals

0     6References:0 4 array type 3.6, character literal 2.5, component type 3.3, constraint_error exception
     11.1, dimension 3.6, index subtype 3.6, length of an array 3.6.2, limited type 7.4.4, null array 3.6.1,
     numeric type 3.5, operation 3.3, operator 4.5, predefined operator 4.5, raising of exceptions 11, range
     of an index subtype 3.6.1, real type 3.5.6, string literal 2.6, type 3.30

      subsection lrm-section4-5-4



     74.5.4. Unary Adding Operators

0     The unary adding operators + and - are predefined for any numeric type and have their conventional
     meaning.  For each of these operators, the operand and the result have the same type.

6         Operator    Operation   Operand type       Result type

0         +             identity     any numeric type   same numeric type

         -             negation    any numeric type   same numeric type

     6References:0 4 numeric type 3.5, operation 3.3, operator 4.5, predefined operator 4.5, type 3.30

      subsection lrm-section4-5-5



     74.5.5. Multiplying Operators

0     The operators * and / are predefined for any integer and any floating point type and have their
     conventional meaning; the operators 1mod0 and 1rem0 are predefined for any integer type.  For each of
     these operators, the operands and the result have the same base type.  For floating point types, the
     accuracy of the result is determined by the operand type (see 4.5.7).

6         Operator    Operation         Operand type                  Result type

0         *              multiplication     any integer type               same integer type
                                            any floating point type       same floating point type

         /              integer division   any integer type              same integer type
                        floating division  any floating point type       same floating point type

         1mod0          modulus           any integer type               same integer type

         1rem0           remainder         any integer type              same integer type

     Integer division and remainder are defined by the relation

         A = (A/B)*B + (A 1rem0 B)

     where (A 1rem0 B) has the sign of A and an absolute value less than the absolute value of B. Integer
     division satisfies the identity

         (-A)/B = -(A/B) = A/(-B)

     The result of the modulus operation is such that (A 1mod0 B) has the sign of B and an absolute value
     less than the absolute value of B; in addition, for some integer value N, this result must satisfy the
     relation

         A = B*N + (A 1mod0 B)

     For each fixed point type, the following multiplication and division operators, with an operand of the
     predefined type INTEGER, are predefined.

6         Operator  Operation        Left operand type       Right operand type    0   6Result type

0         *         multiplication     any fixed point type       INTEGER                   same as left
                                       INTEGER                    any fixed point type      same as right

         /         division           any fixed point type       INTEGER                   same as left


     Integer multiplication of fixed point values is equivalent to repeated addition.  Division of a fixed
     point value by an integer does not involve a change in type but is approximate (see 4.5.7).

     Finally, the following multiplication and division operators are declared in the predefined package
     STANDARD.  These two special operators apply to operands of all fixed point types (it is a consequence of
     other rules that they cannot be renamed or given as generic actual parameters).

6         Operator    Operation         Left operand type     Right operand type     Result type

0         *           multiplication        any fixed point type  any fixed point type   6universal_fixed

0         /           division              any fixed point type  any fixed point type  6 universal_fixed
0     Multiplication of operands of the same or of different fixed point types is exact and delivers a result
     of the anonymous predefined fixed point type 6universal0_6fixed0 whose delta is arbitrarily small.
     The result of any such multiplication must always be explicitly converted to some numeric type.  This
     ensures explicit control of the accuracy of the computation.  The same considerations apply to division
     of a fixed point value by another fixed point value.  No other operators are defined for the type
     6universal0_6fixed.

0     The exception NUMERIC_ERROR is raised by integer division, 1rem,0 and 1mod0 if the right operand is
     zero.

     6Examples:

0         I     : INTEGER := 1;
         J    : INTEGER := 2;
         K    : INTEGER := 3;

         X    : REAL 1digits0 6 := 1.0;                    --     see 3.5.7
         Y    : REAL 1digits0 6 := 2.0;

         F    : FRACTION 1delta0 0.0001 := 0.1;        --     see 3.5.9
         G    : FRACTION 1delta0 0.0001 := 0.1;

         Expression              Value         Result Type

         I*J                       2             same as I and J, that is, INTEGER
         K/J                      1             same as K and J, that is, INTEGER
         k mod J                 1             same as K and J, that is, INTEGER

         X/Y                     0.5           same as X and Y, that is, REAL
         F/2                      0.05          same as F, THAT is, fraction

         3*F                      0.3           same as F, that is, fraction
         F*G                      0.01          6universal0_6fixed0, conversion needed
         FRACTION(F*G)        0.01          FRACTION, as stated by the conversion
         REAL(J)*Y               4.0           REAL, the type of both operands after conversion of J


     6Notes:

0     For positive A and B, A/B is the quotient and A 1rem0 B is the remainder when A is divided by B. The
     following relations are satisfied by the 1rem0 operator:

         A    1rem0 (-B)  =   A 1rem0 B
         (-A) 1rem0   B   = -(A 1rem0 B)

     For any integer K, the following identity holds:

           A     1mod0   B    =  (A + K*B) 1mod0 B

     The relations between integer division, remainder, and modulus are illustrated by the following table:

         A       B     A/B   A 1rem0 B  A 1mod0 B              A     B     A/B   A 1rem0 B       A 1mod0 B

         10      5     2     0          0                    -10     5     -2      0             0
         11      5     2     1          1                    -11     5     -2     -1            4
         12      5     2     2          2                    -12     5     -2     -2            3
         13      5     2     3          3                    -13     5     -2     -3            2
         14      5     2     4          4                    -14     5     -2     -4            1

         10      -5    -2    0          0                    -10   -5     2       0             0
         11      -5    -2    1        -4                     -11   -5     2     -1            -1
         12      -5    -2    2        -3                     -12   -5     2     -2            -2
         13      -5    -2    3        -2                     -13   -5     2     -3            -3
         14      -5    -2    4        -1                     -14   -5     2     -4            -4

     6References:0 4 actual parameter 6.4.1, base type 3.3, declaration 3.1, delta of a fixed point type
     3.5.9, fixed point type 3.5.9, floating point type 3.5.7, generic formal subprogram 12.1, integer type
     3.5.4, numeric type 3.5, numeric_error exception 11.1, predefined operator 4.5, raising of exceptions 11,
     renaming declaration 8.5, standard predefined package 8.6, type conversion 4.60

      subsection lrm-section4-5-6



     74.5.6. Highest Precedence Operators

0     The highest precedence unary operator 1abs0 is predefined for any numeric type.  The highest precedence
     unary operator 1not0 is predefined for any boolean type and any one-dimensional array type whose
     components have a boolean type.

6         Operator        Operation          Operand type                     Result type

0         1abs0             absolute value     any numeric type                 same numeric type

         1not0             logical negation    any boolean type                 same boolean type
                                               array of boolean components   same array type

     The operator 1not0 that applies to a one-dimensional array of boolean components yields a
     one-dimensional boolean array with the same bounds; each component of the result is obtained by logical
     negation of the corresponding component of the operand (that is, the component that has the same index
     value).

     The highest precedence 6exponentiating0 operator ** is predefined for each integer type and for each
     floating point type.  In either case the right operand, called the exponent, is of the predefined type
     INTEGER.

6         Operator   Operation      Left operand type         Right operand type    Result type

0         **         exponentiation  any integer type           INTEGER                same as left
                                       any floating point type    INTEGER               same as left

     Exponentiation with a positive exponent is equivalent to repeated multiplication of the left operand by
     itself, as indicated by the exponent and from left to right.  For an operand of a floating point type,
     the exponent can be negative, in which case the value is the reciprocal of the value with the positive
     exponent.  Exponentiation by a zero exponent delivers the value one.  Exponentiation of a value of a
     floating point type is approximate (see 4.5.7).  Exponentiation of an integer raises the exception
     CONSTRAINT_ERROR for a negative exponent.

     6References:0 4 array type 3.6, boolean type 3.5.3, bound of an array 3.6.1, component of an array
     3.6, constraint_error exception 11.1, dimensionality 3.6, floating point type 3.5.9, index 3.6, integer
     type 3.5.4, multiplication operation 4.5.5, predefined operator 4.5, raising of exceptions 110

      subsection lrm-section4-5-7



     74.5.7. Accuracy of Operations with Real Operands

0     A real subtype specifies a set of model numbers.  Both the accuracy required from any basic or predefined
     operation giving a real result, and the result of any predefined relation between real operands are
     defined in terms of these model numbers.

     A 6model0 6interval0 of a subtype is any interval whose bounds are model numbers of the subtype.  The
     model interval associated with a value that belongs to a real subtype is the smallest model interval (of
     the subtype) that includes the value.  (The model interval associated with a model number of a subtype
     consists of that number only.)

     For any basic operation or predefined operator that yields a result of a real subtype, the required
     bounds on the result are given by a model interval defined as follows:

        - The result model interval is the smallest model interval (of the result subtype) that includes
          the minimum and the maximum of all the values obtained by applying the (exact) mathematical
          operation, when each operand is given any value of the model interval (of the operand subtype)
          defined for the operand.

        - The model interval of an operand that is itself the result of an operation, other than an
          implicit conversion, is the result model interval of this operation.

        - The model interval of an operand whose value is obtained by implicit conversion of a universal
          expression is the model interval associated with this value within the operand subtype.

     The result model interval is undefined if the absolute value of one of the above mathematical results
     exceeds the largest safe number of the result type.  Whenever the result model interval is undefined, it
     is highly desirable that the exception NUMERIC_ERROR be raised if the implementation cannot produce an
     actual result that is in the range of safe numbers.  This is, however, not required by the language
     rules, in recognition of the fact that certain target machines do not permit easy detection of overflow
     situations.  The value of the attribute MACHINE_OVERFLOWS indicates whether the target machine raises the
     exception NUMERIC_ERROR in overflow situations (see 13.7.3).

     The safe numbers of a real type are defined (see 3.5.6) as a superset of the model numbers, for which
     error bounds follow the same rules as for model numbers.  Any definition given in this section in terms
     of model intervals can therefore be extended to safe intervals of safe numbers.  A consequence of this
     extension is that an implementation is not allowed to raise the exception NUMERIC_ERROR when the result
     interval is a safe interval.

     For the result of exponentiation, the model interval defining the bounds on the result is obtained by
     applying the above rules to the sequence of multiplications defined by the exponent, and to the final
     division in the case of a negative exponent.

     For the result of a relation between two real operands, consider for each operand the model interval (of
     the operand subtype) defined for the operand; the result can be any value obtained by applying the
     mathematical comparison to values arbitrarily chosen in the corresponding operand model intervals.  If
     either or both of the operand model intervals is undefined (and if neither of the operand evaluations
     raises an exception) then the result of the comparison is allowed to be any possible value (that is,
     either TRUE or FALSE).

     The result of a membership test is defined in terms of comparisons of the operand value with the lower
     and upper bounds of the given range or type mark (the usual rules apply to these comparisons).

     6Note:

0     For a floating point type the numbers 15.0, 3.0, and 5.0 are always model numbers.  Hence X/Y where X
     equals 15.0 and Y equals 3.0 yields exactly 5.0 according to the above rules.  In the general case,
     division does not yield model numbers and in consequence one cannot assume that (1.0/X)*X = 1.0.

     6References:0 4 attribute 4.1.4, basic operation 3.3.3, bound of a range 3.5, error bound 3.5.6,
     exponentiation operation 4.5.6, false boolean value 3.5.3, floating point type 3.5.9, machine_overflows
     attribute 13.7.1, membership test 4.5.2, model number 3.5.6, multiplication operation 4.5.5,
     numeric_error exception 11.1, predefined operation 3.3.3, raising of exceptions 11, range 3.5, real type
     3.5.6, relation 4.4, relational operator 4.5.2 4.5, safe number 3.5.6, subtype 3.3, true boolean value
     3.5.3, type conversion 4.6, type mark 3.3.2, universal expression 4.100

      section lrm-section4-6

     24.6. Type Conversions

0     The evaluation of an explicit type conversion evaluates the expression given as the operand, and converts
     the resulting value to a specified 6target0 type.  Explicit type conversions are allowed between
     closely related types as defined below.

         type_conversion ::= type_mark(expression)

     The target type of a type conversion is the base type of the type mark.  The type of the operand of a
     type conversion must be determinable independently of the context (in particular, independently of the
     target type).  Furthermore, the operand of a type conversion is not allowed to be a literal 1null,0 an
     allocator, an aggregate, or a string literal; an expression enclosed by parentheses is allowed as the
     operand of a type conversion only if the expression alone is allowed.

     A conversion to a subtype consists of a conversion to the target type followed by a check that the result
     of the conversion belongs to the subtype.  A conversion of an operand of a given type to the type itself
     is allowed.

     The other allowed explicit type conversions correspond to the following three cases:

        - Numeric types

        - The operand can be of any numeric type; the value of the operand is converted to the target
          type which must also be a numeric type.  For conversions involving real types, the result is
          within the accuracy of the specified subtype (see 4.5.7).  The conversion of a real value to an
          integer type rounds to the nearest integer; if the operand is halfway between two integers
          (within the accuracy of the real subtype) rounding may be either up or down.

        - Derived types

        - The conversion is allowed if one of the target type and the operand type is derived from the
          other, directly or indirectly, or if there exists a third type from which both types are
          derived, directly or indirectly.

        - Array types

        - The conversion is allowed if the operand type and the target type are array types that satisfy
          the following conditions:  both types must have the same dimensionality; for each index
          position the index types must either be the same or be convertible to each other; the component
          types must be the same; finally, if the component type is a type with discriminants or an
          access type, the component subtypes must be either both constrained or both unconstrained.  If
          the type mark denotes an unconstrained array type, then, for each index position, the bounds of
          the result are obtained by converting the bounds of the operand to the corresponding index type
          of the target type.  If the type mark denotes a constrained array subtype, then the bounds of
          the result are those imposed by the type mark.  In either case, the value of each component of
          the result is that of the matching component of the operand (see 4.5.2).

     In the case of conversions of numeric types and derived types, the exception CONSTRAINT_ERROR is raised
     by the evaluation of a type conversion if the result of the conversion fails to satisfy a constraint
     imposed by the type mark.

     In the case of array types, a check is made that any constraint on the component subtype is the same for
     the operand array type as for the target array type.  If the type mark denotes an unconstrained array
     type and if the operand is not a null array, then, for each index position, a check is made that the
     bounds of the result belong to the corresponding index subtype of the target type.  If the type mark
     denotes a constrained array subtype, a check is made that for each component of the operand there is a
     matching component of the target subtype, and vice versa.  The exception CONSTRAINT_ERROR is raised if
     any of these checks fails.

     If a conversion is allowed from one type to another, the reverse conversion is also allowed. This reverse
     conversion is used where an actual parameter of mode 1in0 1out0 or 1out0 has the form of a type
     conversion of a (variable) name as explained in section 6.4.1.

     Apart from the explicit type conversions, the only allowed form of type conversion is the implicit
     conversion of a value of the type 6universal0_6integer0 or 6universal0_6real0 into another
     numeric type.  An implicit conversion of an operand of type 6universal0_6integer0 to another integer
     type, or of an operand of type 6universal0_6real0 to another real type, can only be applied if the
     operand is either a numeric literal, a named number, or an attribute; such an operand is called a
     6convertible0 universal operand in this section.  An implicit conversion of a convertible universal
     operand is applied if and only if the innermost complete context (see 8.7) determines a unique (numeric)
     target type for the implicit conversion, and there is no legal interpretation of this context without
     this conversion.

     6Notes:

0     The rules for implicit conversions imply that no implicit conversion is ever applied to the operand of an
     explicit type conversion.  Similarly, implicit conversions are not applied if both operands of a
     predefined relational operator are convertible universal operands.

     The language allows implicit subtype conversions in the case of array types (see 5.2.1).  An explicit
     type conversion can have the effect of a change of representation (in particular see 13.6).  Explicit
     conversions are also used for actual parameters (see 6.4).

     6Examples0 6of0 6numeric0 6type0 6conversion:

0         REAL(2*J)         6--  value is converted to floating point
0         INTEGER(1.6)     6--  value is 2
0         INTEGER(-0.4)    6--  value is 0

0     6Example0 6of0 6conversion0 6between0 6derived0 6types:

0         1type0 A_FORM 1is0 1new0 B_FORM;

         X   : A_FORM;
         Y   : B_FORM;

         X   := A_FORM(Y);
         Y   := B_FORM(X);    6--  the reverse conversion

0     6Examples0 6of0 6conversions0 6between0 6array0 6types:

0         1type0 SEQUENCE 1is0 1array0 (INTEGER 1RANGE0 <>) of INTEGER;
         1subtype0 DOZEN 1is0 SEQUENCE(1 .. 12);
         LEDGER : 1array0(1 .. 100) 1of0 INTEGER;

         SEQUENCE(LEDGER)              6--  bounds are those of LEDGER
0         SEQUENCE(LEDGER(31 .. 42))   6--  bounds are 31 and 42
0         DOZEN(LEDGER(31 .. 42))        6--  bounds are those of DOZEN

0     6Examples0 6of0 6implicit0 6conversions:

0         X : INTEGER := 2;

         X + 1 + 2                        6-- Implicit conversion of each integer literal
0         1 + 2 + X                        6-- Implicit conversion of each integer literal
0         X + (1 + 2)                      6-- Implicit conversion of each integer literal

0         2 = (1 + 1)                      6-- No implicit conversion:  the type is universal_integer
0         A'LENGTH = B'LENGTH        6-- No implicit conversion:  the type is universal_integer
0         C : 1constant0 := 3 + 2;          6-- No implicit conversion:  the type is universal_integer

0         X = 3 1and0 1 = 2                6-- Implicit conversion of 3, but not of 1 and 2

0     6References:0 4 actual parameter 6.4.1, array type 3.6, attribute 4.1.4, base type 3.3, belong to a
     subtype 3.3, component 3.3, constrained array subtype 3.6, constraint_error exception 11.1, derived type
     3.4, dimension 3.6, expression 4.4, floating point type 3.5.7, index 3.6, index subtype 3.6, index type
     3.6, integer type 3.5.4, matching component 4.5.2, mode 6.1, name 4.1, named number 3.2, null array
     3.6.1, numeric literal 2.4, numeric type 3.5, raising of exceptions 11, real type 3.5.6, representation
     13.1, statement 5, subtype 3.3, type 3.3, type mark 3.3.2, unconstrained array type 3.6,
     universal_integer type 3.5.4, universal_real type 3.5.6, variable 3.2.10

      section lrm-section4-7

     24.7. Qualified Expressions

0     A qualified expression is used to state explicitly the type, and possibly the subtype, of an operand that
     is the given expression or aggregate.

         qualified_expression ::=
            type_mark'(expression) | type_mark'aggregate

     The operand must have the same type as the base type of the type mark.  The value of a qualified
     expression is the value of the operand.  The evaluation of a qualified expression evaluates the operand
     and checks that its value belongs to the subtype denoted by the type mark.  The exception
     CONSTRAINT_ERROR is raised if this check fails.

     6Examples:

0         1type0 MASK   1is0 (FIX, DEC, EXP, SIGNIF);
         1type0 CODE   1is0 (FIX, CLA, DEC, TNZ, SUB);

         PRINT (MASK'(DEC));    6--  0DEC is of type MASK
         PRINT (CODE'(DEC));    6--  0DEC is of type CODE

         1for0 J 1in0 CODE'(FIX) .. CODE'(DEC) 1loop0 ...   -- Qualification needed for FIX or DEC
         1for0 J 1in0 CODE 1range0 FIX .. DEC 1loop0 ...      -- Qualification unnecessary
         1for0 J 1in0 CODE'(FIX) .. DEC 1loop0 ...            -- Qualification unnecessary for DEC

         DOZEN'(1 | 3 | 5 | 7 => 2, OTHERS => 0)    6-- See 4.6

0     6Notes:

0     Whenever the type of an enumeration literal or aggregate is not known from the context, a qualified
     expression can be used to state the type explicitly.  For example, an overloaded enumeration literal must
     be qualified in the following cases:  when given as a parameter in a subprogram call to an overloaded
     subprogram that cannot otherwise be identified on the basis of remaining parameter or result types, in a
     relational expression where both operands are overloaded enumeration literals, or in an array or loop
     parameter range where both bounds are overloaded enumeration literals.  Explicit qualification is also
     used to specify which one of a set of overloaded parameterless functions is meant, or to constrain a
     value to a given subtype.

     6References:0 4 aggregate 4.3, array 3.6, base type 3.3, bound of a range 3.5, constraint_error
     exception 11.1, context of overload resolution 8.7, enumeration literal 3.5.1, expression 4.4, function
     6.5, loop parameter 5.5, overloading 8.5, raising of exceptions 11, range 3.3, relation 4.4, subprogram
     6, subprogram call 6.4, subtype 3.3, type 3.3, type mark 3.3.20

      section lrm-section4-8

     24.8. Allocators

0     The evaluation of an allocator creates an object and yields an access value that designates the object.

         allocator ::=
            1new0 subtype_indication | 1new0 qualified_expression

     The type of the object created by an allocator is the base type of the type mark given in either the
     subtype indication or the qualified expression.  For an allocator with a qualified expression, this
     expression defines the initial value of the created object.  The type of the access value returned by an
     allocator must be determinable solely from the context, but using the fact that the value returned is of
     an access type having the named designated type.

     The only allowed forms of constraint in the subtype indication of an allocator are index and discriminant
     constraints.  If an allocator includes a subtype indication and if the type of the object created is an
     array type or a type with discriminants that do not have default expressions, then the subtype indication
     must either denote a constrained subtype, or include an explicit index or discriminant constraint.

     If the type of the created object is an array type or a type with discriminants, then the created object
     is always constrained.  If the allocator includes a subtype indication, the created object is constrained
     either by the subtype or by the default discriminant values.  If the allocator includes a qualified
     expression, the created object is constrained by the bounds or discriminants of the initial value.  For
     other types, the subtype of the created object is the subtype defined by the subtype indication of the
     access type definition.

     For the evaluation of an allocator, the elaboration of the subtype indication or the evaluation of the
     qualified expression is performed first.  The new object is then created.  Initializations are then
     performed as for a declared object (see 3.2.1); the initialization is considered explicit in the case of
     a qualified expression; any initializations are implicit in the case of a subtype indication.  Finally,
     an access value that designates the created object is returned.

     An implementation must guarantee that any object created by the evaluation of an allocator remains
     allocated for as long as this object or one of its subcomponents is accessible directly or indirectly,
     that is, as long as it can be denoted by some name.  Moreover, if an object or one of its subcomponents
     belongs to a task type, it is considered to be accessible as long as the task is not terminated.  An
     implementation may (but need not) reclaim the storage occupied by an object created by an allocator, once
     this object has become inaccessible.

     When an application needs closer control over storage allocation for objects designated by values of an
     access type, such control may be achieved by one or more of the following means:

        - The total amount of storage available for the collection of objects of an access type can be
          set by means of a length clause (see 13.2).

        - The pragma CONTROLLED informs the implementation that automatic storage reclamation must not be
          performed for objects designated by values of the access type, except upon leaving the
          innermost block statement, subprogram body, or task body that encloses the access type
          declaration, or after leaving the main program.

        - 1pragma0 CONTROLLED (6access0_6type0_simple_name);

        - A pragma CONTROLLED for a given access type is allowed at the same places as a representation
          clause for the type (see 13.1).  This pragma is not allowed for a derived type.

        - The explicit deallocation of the object designated by an access value can be achieved by
          calling a procedure obtained by instantiation of the predefined generic library procedure
          UNCHECKED_DEALLOCATION (see 13.10.1).

     The exception STORAGE_ERROR is raised by an allocator if there is not enough storage.  Note also that the
     exception CONSTRAINT_ERROR can be raised by the evaluation of the qualified expression, by the
     elaboration of the subtype indication, or by the initialization.

     6Examples0 (6for0 6access0 6types0 6declared0 6in0 6section0 63.8):

0         1new0 CELL'(0, 1NULL,0 1null0)                                      6-- Initialized explicitly
0         1new0 CELL'(VALUE => 0, SUCC => 1null,0 PRED => null)      6-- Initialized explicitly
0         1new0 CELL                                                      6-- not initialized

0         1new0 MATRIX(1 .. 10, 1 .. 20)                                6-- The bounds only are given
0         1new0 MATRIX'(1 .. 10 => (1 .. 20 => 0.0))                   6-- Initialized explicitly

0         1new0 BUFFER(100)                                             6-- The discriminant only is given

0         1new0 BUFFER'(SIZE => 80, POS => 0, VALUE => (1 .. 80 => 'A'))   6-- Initialized explicitly

0     6References:0 4 access type 3.8, access type definition 3.8, access value 3.8, array type 3.6, block
     statement 5.6, bound of an array 3.6.1, collection 3.8, constrained subtype 3.3, constraint 3.3,
     constraint_error exception 11.1, context of overload resolution 8.7, derived type 3.4, designate 3.8,
     discriminant 3.3, discriminant constraint 3.7.2, elaboration 3.9, evaluation of a qualified expression
     4.7, generic procedure 12.1, index constraint 3.6.1, initial value 3.2.1, initialization 3.2.1,
     instantiation 12.3, length clause 13.2, library unit 10.1, main program 10.1, name 4.1, object 3.2.1,
     object declaration 3.2.1, pragma 2.8, procedure 6, qualified expression 4.7, raising of exceptions 11,
     representation clause 13.1, simple name 4.1, storage0_4error exception 11.1, subcomponent 3.3,
     subprogram body 6.3, subtype 3.3, subtype indication 3.3.2, task body 9.1, task type 9.2, terminated task
     9.4, type 3.3, type declaration 3.3.1, type mark 3.3.2 type with discriminants 3.30

      section lrm-section4-9

     24.9. Static Expressions and Static Subtypes

0     Certain expressions of a scalar type are said to be 6static.0 Similarly, certain discrete ranges are
     said to be static, and the type marks of certain scalar subtypes are said to denote static subtypes.

     An expression of a scalar type is said to be static if and only if every primary is one of those listed
     in (a) through (h) below, every operator denotes a predefined operator, and the evaluation of the
     expression delivers a value (that is, it does not raise an exception):

        (a) An enumeration literal (including a character literal).

        (b) A numeric literal.

        (c) A named number.

        (d) A constant explicitly declared by a constant declaration with a static subtype, and initialized
            with a static expression.

        (e) A function call whose function name is an operator symbol that denotes a predefined operator,
            including a function name that is an expanded name; each actual parameter must also be a static
            expression.

        (f)  A language-defined attribute of a static subtype; for an attribute that is a function, the
            actual parameter must also be a static expression.

        (g) A qualified expression whose type mark denotes a static subtype and whose operand is a static
            expression.

        (h) A static expression enclosed in parentheses.

     A static range is a range whose bounds are static expressions.  A static range constraint is a range
     constraint whose range is static.  A static subtype is either a scalar base type, other than a generic
     formal type; or a scalar subtype formed by imposing on a static subtype either a static range constraint,
     or a floating or fixed point constraint whose range constraint, if any, is static.  A static discrete
     range is either a static subtype or a static range.  A static index constraint is an index constraint for
     which each index subtype of the corresponding array type is static, and in which each discrete range is
     static.  A static discriminant constraint is a discriminant constraint for which the subtype of each
     discriminant is static, and in which each expression is static.

     6Notes:

0     The accuracy of the evaluation of a static expression having a real type is defined by the rules given in
     section 4.5.7.  If the result is not a model number (or a safe number) of the type, the value obtained by
     this evaluation at compilation time need not be the same as the value that would be obtained by an
     evaluation at run time.

     Array attributes are not static:  in particular, the RANGE attribute is not static.

     6References:0 4 actual parameter 6.4.1, attribute 4.1.4, base type 3.3, bound of a range 3.5,
     character literal 2.5, constant 3.2.1, constant declaration 3.2.1, discrete range 3.6, discrete type 3.5,
     enumeration literal 3.5.1, exception 11, expression 4.4, function 6.5, generic actual parameter 12.3,
     generic formal type 12.1.2, implicit declaration 3.1, initialize 3.2.1, model number 3.5.6, named number
     3.2, numeric literal 2.4, predefined operator 4.5, qualified expression 4.7, raising of exceptions 11,
     range constraint 3.5, safe number 3.5.6, scalar type 3.5, subtype 3.3, type mark 3.3.20

      section lrm-section4-10

     24.10. Universal Expressions

0     A 6universal0_6expression0 is either an expression that delivers a result of type
     6universal0_6integer0 or one that delivers a result of type 6universal0_6real.

0     The same operations are predefined for the type 6universal0_6integer0 as for any integer type.  The
     same operations are predefined for the type 6universal0_6real0 as for any floating point type.  In
     addition, these operations include the following multiplication and division operators:

6         Operator   Operation        Left operand type   Right operand type   Result type

0         *            multiplication     universal_real        universal_integer    universal_real
                                          universal_integer    universal_real        universal_real

         /            division           universal_real        universal_integer    universal_real

     The accuracy of the evaluation of a universal expression of type 6universal0_6real0 is at least as
     good as that of the most accurate predefined floating point type supported by the implementation, apart
     from 6universal0_6real0 itself.  Furthermore, if a universal expression is a static expression, then
     the evaluation must be exact.

     For the evaluation of an operation of a nonstatic universal expression, an implementation is allowed to
     raise the exception NUMERIC_ERROR only if the result of the operation is a real value whose absolute
     value exceeds the largest safe number of the most accurate predefined floating point type (excluding
     6universal0_6real),0 or an integer value greater than SYSTEM.MAX_INT or less than SYSTEM.MIN_INT.

     6Note:

0     It is a consequence of the above rules that the type of a universal expression is
     6universal0_6integer0 if every primary contained in the expression is of this type (excluding actual
     parameters of attributes that are functions, and excluding right operands of exponentiation operators)
     and that otherwise the type is 6universal0_6real.

0     6Examples:

0         1 + 1            6-- 2
0         1ABS(-10)*3   0  6-- 30

0         KILO     :  1constant0 := 1000;
         MEGA   :  1constant0 := KILO*KILO;           6-- 10_60000_6000
0         LONG   :  1constant0 := FLOAT'DIGITS*2;

         HALF_PI   	     :  1constant0 := PI/2;   		     6-- see 3.2.2
0         DEG_TO_RAD   :  1constant0 := HALF_PI/90;
         RAD_TO_DEG   :  1constant0 := 1.0/DEG_TO_RAD;  6-- Equivalent to 1.0/((3.14159_26536/2)/90)

0     6References:0 4 actual parameter 6.4.1, attribute 4.1.4, evaluation of an expression 4.5, floating
     point type 3.5.9, function 6.5, integer type 3.5.4, multiplying operator 4.5 4.5.5, predefined operation
     3.3.3, primary 4.4, real type 3.5.6, safe number 3.5.6, system.max_int 13.7, system.min_int 13.7, type
     3.3, universal_integer type 3.5.4, universal_real type 3.5.60

      chapter lrm-chapter-5



                                                   15. Statements

0     A 6statement0 defines an action to be performed; the process by which a statement achieves its action
     is called 6execution0 of the statement.

     This chapter describes the general rules applicable to all statements.  Some specific statements are
     discussed in later chapters.  Procedure call statements are described in Chapter 6 on subprograms.  Entry
     call, delay, accept, select, and abort statements are described in Chapter 9 on tasks.  Raise statements
     are described in Chapter 11 on exceptions, and code statements in Chapter 13.  The remaining forms of
     statements are presented in this chapter.

     6References:0 4 abort statement 9.10, accept statement 9.5, code statement 13.8, delay statement 9.6,
     entry call statement 9.5, procedure call statement 6.4, raise statement 11.3, select statement 9.7 0

      section lrm-section5-1

     25.1. Simple and Compound Statements - Sequences of Statements

0     A statement is either simple or compound.  A simple statement encloses no other statement.  A compound
     statement can enclose simple statements and other compound statements.

         sequence_of_statements ::= statement {statement}

         statement ::=
            {label} simple_statement     | {label} compound_statement

         simple_statement ::= null_statement
            |   assignment_statement    | procedure_call_statement
            |   exit_statement            | return_statement
            |   goto_statement           | entry_call_statement
            |   delay_statement          | abort_statement
            |   raise_statement          | code_statement

         compound_statement ::=
                if_statement              | case_statement
            |   loop_statement           | block_statement
            |   accept_statement        | select_statement

         label ::= <<6label0_simple_name>>

         null_statement ::= 1null0;

     A statement is said to be 6labeled0 by the label name of any label of the statement.  A label name, and
     similarly a loop or block name, is implicitly declared at the end of the declarative part of the
     innermost block statement, subprogram body, package body, task body, or generic body that encloses the
     labeled statement, the named loop statement, or the named block statement, as the case may be.  For a
     block statement without a declarative part, an implicit declarative part (and preceding 1declare0) is
     assumed.

     The implicit declarations for different label names, loop names, and block names occur in the same order
     as the beginnings of the corresponding labeled statements, loop statements, and block statements.
     Distinct identifiers must be used for all label, loop, and block names that are implicitly declared
     within the body of a program unit, including within block statements enclosed by this body, but excluding
     within other enclosed program units (a program unit is either a subprogram, a package, a task unit, or a
     generic unit).

     Execution of a null statement has no other effect than to pass to the next action.

     The execution of a sequence of statements consists of the execution of the individual statements in
     succession until the sequence is completed, or a transfer of control takes place.  A transfer of control
     is caused either by the execution of an exit, return, or goto statement; by the selection of a terminate
     alternative; by the raising of an exception; or (indirectly) by the execution of an abort statement.

     6Examples0 6of0 6labeled0 6statements:

0         <<HERE>> <<ICI>> <<AQUI>> <<HIER>> 1null0;

         <<AFTER>> X := 1;

     6Note:

0     The scope of a declaration starts at the place of the declaration itself (see 8.2).  In the case of a
     label, loop, or block name, it follows from this rule that the scope of the 6implicit0 declaration
     starts before the first 6explicit0 occurrence of the corresponding name, since this occurrence is
     either in a statement label, a loop statement, a block statement, or a goto statement.  An implicit
     declaration in a block statement may hide a declaration given in an outer program unit or block statement
     (according to the usual rules of hiding explained in section 8.3).

     6References:0 4 abort statement 9.10, accept statement 9.5, assignment statement 5.2, block name 5.6,
     block statement 5.6, case statement 5.4, code statement 13.8, declaration 3.1, declarative part 3.9,
     delay statement 9.6, entry call statement 9.5, exception 11, exit statement 5.7, generic body 12.1,
     generic unit 12, goto statement 5.9, hiding 8.3, identifier 2.3, if statement 5.3, implicit declaration
     3.1, loop name 5.5, loop statement 5.5, package 7, package body 7.1, procedure call statement 6.4,
     program unit 6, raise statement 11.3, raising of exceptions 11, return statement 5.8, scope 8.2, select
     statement 9.7, simple name 4.1, subprogram 6, subprogram body 6.3, task 9, task body 9.1, task unit 9.1,
     terminate alternative 9.7.1, terminated task 9.4 0

      section lrm-section5-2

     25.2. Assignment Statement

0     An assignment statement replaces the current value of a variable with a new value specified by an
     expression.  The named variable and the right-hand side expression must be of the same type; this type
     must not be a limited type.

         assignment_statement ::=
            6variable_0name := expression;

     For the execution of an assignment statement, the variable name and the expression are first evaluated,
     in some order that is not defined by the language.  A check is then made that the value of the expression
     belongs to the subtype of the variable, except in the case of a variable that is an array (the assignment
     then involves a subtype conversion as described in section 5.2.1).  Finally, the value of the expression
     becomes the new value of the variable.

     The exception CONSTRAINT_ERROR is raised if the above-mentioned subtype check fails; in such a case the
     current value of the variable is left unchanged.  If the variable is a subcomponent that depends on
     discriminants of an unconstrained record variable, then the execution of the assignment is erroneous if
     the value of any of these discriminants is changed by this execution.

     6Examples:

0         VALUE  := MAX_VALUE - 1;
         SHADE  := BLUE;

         NEXT_FRAME(F)(M, N) := 2.5;        --  6see 4.1.1
0         U := DOT_PRODUCT(V, W);          --  6see 6.5

0         WRITER := (STATUS => OPEN, UNIT => PRINTER, LINE_COUNT => 60);  -- 6see 3.7.3
0         NEXT_CAR.1all0 := (72074, 1null0);      --  6see 3.8.1

0     6Examples0 6of0 6constraint0 6checks:

0         I, J   : INTEGER 1range0 1 .. 10;
         K     : INTEGER 1range0 1 .. 20;
          ...

         I    := J;      --  6identical ranges
0         K   := J;      6--  compatible ranges
0         J    := K;     6--  will raise the exception CONSTRAINT_ERROR if K > 10

0     6Notes:

0     The values of the discriminants of an object designated by an access value cannot be changed (not even by
     assigning a complete value to the object itself) since such objects, created by allocators, are always
     constrained (see 4.8); however, subcomponents of such objects may be unconstrained.

     If the right-hand side expression is either a numeric literal or named number, or an attribute that
     yields a result of type 6universal0_6integer0 or 6universal0_6real,0 then an implicit type
     conversion is performed, as described in section 4.6.

     The determination of the type of the variable of an assignment statement may require consideration of the
     expression if the variable name can be interpreted as the name of a variable designated by the access
     value returned by a function call, and similarly, as a component or slice of such a variable (see section
     8.7 for the context of overload resolution).

     6References:0 4 access type 3.8, allocator 4.8, array 3.6, array assignment 5.2.1, component 3.6 3.7,
     constraint_error exception 11.1, designate 3.8, discriminant 3.7.1, erroneous 1.6, evaluation 4.5,
     expression 4.4, function call 6.4, implicit type conversion 4.6, name 4.1, numeric literal 2.4, object
     3.2, overloading 6.6 8.7, slice 4.1.2, subcomponent 3.3, subtype 3.3, subtype conversion 4.6, type 3.3,
     universal_integer type 3.5.4, universal_real type 3.5.6, variable 3.2.1 0

      subsection lrm-section5-2-1



     75.2.1. Array Assignments

0     If the variable of an assignment statement is an array variable (including a slice variable), the value
     of the expression is implicitly converted to the subtype of the array variable; the result of this
     subtype conversion becomes the new value of the array variable.

     This means that the new value of each component of the array variable is specified by the matching
     component in the array value obtained by evaluation of the expression (see 4.5.2 for the definition of
     matching components).  The subtype conversion checks that for each component of the array variable there
     is a matching component in the array value, and vice versa.  The exception CONSTRAINT_ERROR is raised if
     this check fails; in such a case the value of each component of the array variable is left unchanged.

     6Examples:

0         A   : STRING(1 .. 31);
         B   : STRING(3 .. 33);
          ...

         A   := B;     6--  same number of components

0         A(1 .. 9)    := "TAR SAUCE";
         A(4 .. 12)   := A(1 .. 9);   6--  A(1 .. 12) = "tartar sauce"

0     6Notes:

0     Array assignment is defined even in the case of overlapping slices, because the expression on the
     right-hand side is evaluated before performing any component assignment.  In the above example, an
     implementation yielding A(1 .. 12) = "tartartartar" would be incorrect.

     The implicit subtype conversion described above for assignment to an array variable is performed only for
     the value of the right-hand side expression as a whole; it is not performed for subcomponents that are
     array values.

     6References:0 4 array 3.6, assignment 5.2, constraint_error exception 11.1, matching array components
     4.5.2, slice 4.1.2, subtype conversion 4.6, type 3.3, variable 3.2.1 0

      section lrm-section5-3

     25.3. If Statements

0     An if statement selects for execution one or none of the enclosed sequences of statements, depending on
     the (truth) value of one or more corresponding conditions.

         if_statement ::=
            1if0 condition 1then
0               sequence_of_statements
            {  1elsif0 condition 1then
0               sequence_of_statements}
            [  1else
0               sequence_of_statements]
            1end0 1if;

0         condition ::= 6boolean_0expression

     An expression specifying a condition must be of a boolean type.

     For the execution of an if statement, the condition specified after 1if,0 and any conditions specified
     after 1elsif,0 are evaluated in succession (treating a final 1else0 as 1elsif0 TRUE 1then),
0     until one evaluates to TRUE or all conditions are evaluated and yield FALSE.  If one condition evaluates
     to TRUE, then the corresponding sequence of statements is executed; otherwise none of the sequences of
     statements is executed.

     6Examples:

0         1if0 MONTH    = DECEMBER 1and0 DAY = 31 1then
0            MONTH  := JANUARY;
            DAY    := 1;
            YEAR   := YEAR + 1;
         1end0 1if0;

         1if0 LINE_TOO_SHORT 1then
0            1raise0 LAYOUT_ERROR;
         1elsif0 LINE_FULL 1then
0            NEW_LINE;
            PUT(ITEM);
         1else
0            PUT(ITEM);
         1end0 1if0;

         1if0 MY_CAR.OWNER.VEHICLE /= MY_CAR 1then0            6--  see 3.8
0            REPORT ("INCORRECT DATA");
         1end0 1if0;

     6References:0 4 boolean type 3.5.3, evaluation 4.5, expression 4.4, sequence of statements 5.10

      section lrm-section5-4

     25.4. Case Statements

0     A case statement selects for execution one of a number of alternative sequences of statements; the chosen
     alternative is defined by the value of an expression.

         case_statement ::=
            1case0 expression 1is
0            case_statement_alternative
               {  case_statement_alternative}
            1end0 1case;

0         case_statement_alternative ::=
            1when0 choice {| choice } =>
               sequence_of_statements

     The expression must be of a discrete type which must be determinable independently of the context in
     which the expression occurs, but using the fact that the expression must be of a discrete type.
     Moreover, the type of this expression must not be a generic formal type.  Each choice in a case statement
     alternative must be of the same type as the expression; the list of choices specifies for which values of
     the expression the alternative is chosen.

     If the expression is the name of an object whose subtype is static, then each value of this subtype must
     be represented once and only once in the set of choices of the case statement, and no other value is
     allowed; this rule is likewise applied if the expression is a qualified expression or type conversion
     whose type mark denotes a static subtype.  Otherwise, for other forms of expression, each value of the
     (base) type of the expression must be represented once and only once in the set of choices, and no other
     value is allowed.

     The simple expressions and discrete ranges given as choices in a case statement must be static.  A choice
     defined by a discrete range stands for all values in the corresponding range (none if a null range).  The
     choice 1others0 is only allowed for the last alternative and as its only choice; it stands for all
     values (possibly none) not given in the choices of previous alternatives.  A component simple name is not
     allowed as a choice of a case statement alternative.

     The execution of a case statement consists of the evaluation of the expression followed by the execution
     of the chosen sequence of statements.

     6Examples:

0         1case0 SENSOR 1is
0            1when0 ELEVATION    => RECORD_ELEVATION (SENSOR_VALUE);
            1when0 AZIMUTH      => RECORD_AZIMUTH   (SENSOR_VALUE);
            1when0 DISTANCE     => RECORD_DISTANCE  (SENSOR_VALUE);
            1when0 OTHERS       => 1null0;
         1end0 1case0;

         1case0 TODAY 1is
0            1when0 MON           => COMPUTE_INITIAL_BALANCE;
            1when0 FRI             => COMPUTE_CLOSING_BALANCE;
            1when0 TUE .. THU   => GENERATE_REPORT(TODAY);
            1when0 SAT .. SUN   => 1null0;
         1end0 1case0;

         1case0 BIN_NUMBER(COUNT) 1is
0            1when0 1         => UPDATE_BIN(1);
            1when0 2         => UPDATE_BIN(2);
            1when0 3 | 4     =>
               EMPTY_BIN(1);
               EMPTY_BIN(2);
            1when0 OTHERS => raise ERROR;
         1end0 1case0;

     6Notes:

0     The execution of a case statement chooses one and only one alternative, since the choices are exhaustive
     and mutually exclusive.  Qualification of the expression of a case statement by a static subtype can
     often be used to limit the number of choices that need be given explicitly.

     An 1others0 choice is required in a case statement if the type of the expression is the type
     6universal0_6integer0 (for example, if the expression is an integer literal), since this is the only
     way to cover all values of the type 6universal0_6integer.

0     6References:0 4 base type 3.3, choice 3.7.3, context of overload resolution 8.7, discrete type 3.5,
     expression 4.4, function call 6.4, generic formal type 12.1, conversion 4.6, discrete type 3.5,
     enumeration literal 3.5.1, expression 4.4, name 4.1, object 3.2.1, overloading 6.6 8.7, qualified
     expression 4.7, sequence of statements 5.1, static discrete range 4.9, static subtype 4.9, subtype 3.3,
     type 3.3, type conversion 4.6, type mark 3.3.2 0

      section lrm-section5-5

     25.5. Loop Statements

0     A loop statement includes a sequence of statements that is to be executed repeatedly, zero or more times.

         loop_statement ::=
            [6loop0_simple_name:]
               [  iteration_scheme] 1loop
0                  sequence_of_statements
            1end0 1loop0 [6loop0_simple_name];

         iteration_scheme ::= 1while0 condition
            |   1for0 loop_parameter_specification

         loop_parameter_specification ::=
            identifier 1in0 [1reverse0] discrete_range

     If a loop statement has a loop simple name, this simple name must be given both at the beginning and at
     the end.

     A loop statement without an iteration scheme specifies repeated execution of the sequence of statements.
     Execution of the loop statement is complete when the loop is left as a consequence of the execution of an
     exit statement, or as a consequence of some other transfer of control (see 5.1).

     For a loop statement with a 1while0 iteration scheme, the condition is evaluated before each execution
     of the sequence of statements; if the value of the condition is TRUE, the sequence of statements is
     executed, if FALSE the execution of the loop statement is complete.

     For a loop statement with a 1for0 iteration scheme, the loop parameter specification is the declaration
     of the 6loop0 6parameter0 with the given identifier.  The loop parameter is an object whose type is
     the base type of the discrete range (see 3.6.1).  Within the sequence of statements, the loop parameter
     is a constant.  Hence a loop parameter is not allowed as the (left-hand side) variable of an assignment
     statement.  Similarly the loop parameter must not be given as an 1out0 or 1in0 1out0 parameter of a
     procedure or entry call statement, or as an 1in0 1out0 parameter of a generic instantiation.

     For the execution of a loop statement with a 1for0 iteration scheme, the loop parameter specification
     is first elaborated.  This elaboration creates the loop parameter and evaluates the discrete range.

     If the discrete range is a null range, the execution of the loop statement is complete.  Otherwise, the
     sequence of statements is executed once for each value of the discrete range (subject to the loop not
     being left as a consequence of the execution of an exit statement or as a consequence of some other
     transfer of control).  Prior to each such iteration, the corresponding value of the discrete range is
     assigned to the loop parameter.  These values are assigned in increasing order unless the reserved word
     1reverse0 is present, in which case the values are assigned in decreasing order.

     6Example0 6of0 6a0 6loop0 6statement0 6without0 6an0 6iteration0 6scheme:

0         1loop
0            GET(CURRENT_CHARACTER);
            1exit0 1when0 CURRENT_CHARACTER = '*';
         1end0 1loop;


0     6Example0 6of0 6a0 6loop0 6statement0 6with0 6a0 6while0 6iteration0 6scheme:

0         1while0 BID(N).PRICE < CUT_OFF.PRICE 1loop
0            RECORD_BID(BID(N).PRICE);
            N := N + 1;
         1end0 1loop0;


     6Example0 6of0 6a0 6loop0 6statement0 6with0 6a0 6for0 6iteration0 6scheme:

0         1for0 J 1in0 BUFFER'RANGE 1loop0     6--  legal even with a null range
0            1if0 BUFFER(J) /= SPACE 1then
0               PUT(BUFFER(J));
            1end0 1if0;
         1end0 1loop0;


     6Example0 6of0 6a0 6loop0 6statement0 6with0 6a0 6loop0 6simple0 6name:

0         SUMMATION:
            1while0 NEXT /= HEAD 1loop0       -- SEE 3.8
               SUM    := SUM + NEXT.VALUE;
               NEXT   := NEXT.SUCC;
            1end0 1loop0 SUMMATION;


     6Notes:

0     The scope of a loop parameter extends from the loop parameter specification to the end of the loop
     statement, and the visibility rules are such that a loop parameter is only visible within the sequence of
     statements of the loop.

     The discrete range of a for loop is evaluated just once.  Use of the reserved word 1reverse0 does not
     alter the discrete range, so that the following iteration schemes are not equivalent; the first has a
     null range.

         1for0 J 1in0 1reverse0 1 .. 0
         1for0 J 1in0 0 .. 1

     Loop names are also used in exit statements, and in expanded names (in a prefix of the loop parameter).

     6References:0 4 actual parameter 6.4.1, assignment statement 5.2, base type 3.3, bound of a range 3.5,
     condition 5.3, constant 3.2.1, context of overload resolution 8.7, conversion 4.6, declaration 3.1,
     discrete range 3.6.1, elaboration 3.1, entry call statement 9.5, evaluation 4.5, exit statement 5.7,
     expanded name 4.1.3, false boolean value 3.5.3, generic actual parameter 12.3, generic instantiation
     12.3, goto statement 5.9, identifier 2.3, integer type 3.5.4, null range 3.5, object 3.2.1, prefix 4.1,
     procedure call 6.4, raising of exceptions 11, reserved word 2.9, return statement 5.8, scope 8.2,
     sequence of statements 5.1, simple name 4.1, terminate alternative 9.7.1, true boolean value 3.5.3 3.5.4,
     visibility 8.3 0

      section lrm-section5-6

     25.6. Block Statements

0     A block statement encloses a sequence of statements optionally preceded by a declarative part and
     optionally followed by exception handlers.

         block_statement ::=
            [6block0_simple_name:]
               [  1declare
0                  declarative_part]
            1begin
0                  sequence_of_statements
               [  1exception
0                  exception_handler
               {  exception_handler}]
            1end0 [6block0_simple_name];

     If a block statement has a block simple name, this simple name must be given both at the beginning and at
     the end.

     The execution of a block statement consists of the elaboration of its declarative part (if any) followed
     by the execution of the sequence of statements.  If the block statement has exception handlers, these
     service corresponding exceptions that are raised during the execution of the sequence of statements (see
     11.2).

     6Example:

0         SWAP:
            1declare
0               TEMP : INTEGER;
            1begin
0               TEMP := V; V := U; U := TEMP;
            1end0 SWAP;

     6Notes:

0     If task objects are declared within a block statement whose execution is completed, the block statement
     is not left until all its dependent tasks are terminated (see 9.4).  This rule applies also to a
     completion caused by an exit, return, or goto statement; or by the raising of an exception.

     Within a block statement, the block name can be used in expanded names denoting local entities such as
     SWAP.TEMP in the above example (see 4.1.3 (f)).

     6References:0 4 declarative part 3.9, dependent task 9.4, exception handler 11.2, exit statement 5.7,
     expanded name 4.1.3, goto statement 5.9, raising of exceptions 11, return statement 5.8, sequence of
     statements 5.1, simple name 4.1, task object 9.2 0

      section lrm-section5-7

     25.7. Exit Statements

0     An exit statement is used to complete the execution of an enclosing loop statement (called the loop in
     what follows); the completion is conditional if the exit statement includes a condition.

         exit_statement ::=
            1exit0 [6loop0_name] [1when0 condition];

     An exit statement with a loop name is only allowed within the named loop, and applies to that loop; an
     exit statement without a loop name is only allowed within a loop, and applies to the innermost enclosing
     loop (whether named or not).  Furthermore, an exit statement that applies to a given loop must not appear
     within a subprogram body, package body, task body, generic body, or accept statement, if this construct
     is itself enclosed by the given loop.

     For the execution of an exit statement, the condition, if present, is first evaluated.  Exit from the
     loop then takes place if the value is TRUE or if there is no condition.

     6Examples:

0         1for0 N 1in0 1 .. MAX_NUM_ITEMS 1loop
0            GET_NEW_ITEM(NEW_ITEM);
            MERGE_ITEM(NEW_ITEM, STORAGE_FILE);
            1exit0 1when0 NEW_ITEM = TERMINAL_ITEM;
         1end0 1loop0;

         MAIN_CYCLE:
            1loop
0               6--  initial statements
0               1exit0 MAIN_CYCLE 1when0 FOUND;
               6--  final statements
0            1end0 1loop0 MAIN_CYCLE;

     6Note:

0     Several nested loops can be exited by an exit statement that names the outer loop.

     6References:0 4 accept statement 9.5, condition 5.3, evaluation 4.5, generic body 12.1, loop name 5.5,
     loop statement 5.5, package body 7.1, subprogram body 6.3, true boolean value 3.5.3 0

      section lrm-section5-8

     25.8. Return Statements

0     A return statement is used to complete the execution of the innermost enclosing function, procedure, or
     accept statement.
         return_statement ::= 1return0 [expression];

     A return statement is only allowed within the body of a subprogram or generic subprogram, or within an
     accept statement, and applies to the innermost (enclosing) such construct; a return statement is not
     allowed within the body of a task unit, package, or generic package enclosed by this construct (on the
     other hand, it is allowed within a compound statement enclosed by this construct and, in particular, in a
     block statement).

     A return statement for an accept statement or for the body of a procedure or generic procedure must not
     include an expression.  A return statement for the body of a function or generic function must include an
     expression.

     The value of the expression defines the result returned by the function.  The type of this expression
     must be the base type of the type mark given after the reserved word 1return0 in the specification of
     the function or generic function (this type mark defines the result subtype).

     For the execution of a return statement, the expression (if any) is first evaluated and a check is made
     that the value belongs to the result subtype.  The execution of the return statement is thereby completed
     if the check succeeds; so also is the execution of the subprogram or of the accept statement.  The
     exception CONSTRAINT_ERROR is raised at the place of the return statement if the check fails.

     6Examples:

0         1return0;    -- in a procedure
         1return0 KEY_VALUE(LAST_INDEX);      -- in a function

     6Note:

0     If the expression is either a numeric literal or named number, or an attribute that yields a result of
     type 6universal0_6integer0 or 6universal0_6real,0 then an implicit conversion of the result is
     performed as described in section 4.6.

     6References:0 4 accept statement 9.5, attribute A, block statement 5.6, constraint_error exception
     11.1, expression 4.4, function body 6.3, function call 6.4, generic body 12.1, implicit type conversion
     4.6, named number 3.2, numeric literal 2.4, package body 7.1, procedure body 6.3, reserved word 2.9,
     result subtype 6.1, subprogram body 6.3, subprogram specification 6.1, subtype 3.3, task body 9.1, type
     mark 3.3.2, universal_integer type 3.5.4, universal_real type 3.5.60

      section lrm-section5-9

     25.9. Goto Statements

0     A goto statement specifies an explicit transfer of control from this statement to a 6target0 statement
     named by a label.

         goto_statement ::= 1goto0 6label0_name;

     The innermost sequence of statements that encloses the target statement must also enclose the goto
     statement (note that the goto statement can be a statement of an inner sequence).  Furthermore, if a goto
     statement is enclosed by an accept statement or the body of a program unit, then the target statement
     must not be outside this enclosing construct; conversely, it follows from the previous rule that if the
     target statement is enclosed by such a construct, then the goto statement cannot be outside.

     The execution of a goto statement transfers control to the named target statement.

     6Note:

0     The above rules allow transfer of control to a statement of an enclosing sequence of statements but not
     the reverse.  Similarly, they prohibit transfers of control such as between alternatives of a case
     statement, if statement, or select statement; between exception handlers; or from an exception handler of
     a frame back to the sequence of statements of this frame.

     6Example:

0         <<COMPARE>>
            1if0 A(I) < ELEMENT 1then
0               1if0 LEFT(I) /= 0 1then
0                  I := LEFT(I);
                  1goto0 COMPARE;
               1end0 1if0;
               6--  some statements
0            1end0 1if0;

     6References:0 4 accept statement 9.5, block statement 5.6, case statement 5.4, compound statement 5.1,
     exception handler 11.2, frame 11.2, generic body 12.1, if statement 5.3, label 5.1, package body 7.1,
     program unit 6, select statement 9.7, sequence of statements 5.1, statement 5.1, subprogram body 6.3,
     task body 9.1, transfer of control 5.1 0

      chapter lrm-chapter-6



                                                  16. Subprograms

0     Subprograms are one of the four forms of 6program0 6unit,0 of which programs can be composed.  The
     other forms are packages, task units, and generic units.

     A subprogram is a program unit whose execution is invoked by a subprogram call.  There are two forms of
     subprogram: procedures and functions.  A procedure call is a statement; a function call is an expression
     and returns a value.  The definition of a subprogram can be given in two parts:  a subprogram declaration
     defining its calling conventions, and a subprogram body defining its execution.

     6References:0 4 function 6.5, function call 6.4, generic unit 12, package 7, procedure 6.1, procedure
     call 6.4, subprogram body 6.3, subprogram call 6.4, subprogram declaration 6.1, task unit 90

      section lrm-section6-1

     26.1. Subprogram Declarations

0     A subprogram declaration declares a procedure or a function, as indicated by the initial reserved word.

         subprogram_declaration ::= subprogram_specification;

         subprogram_specification ::=
             1procedure0 identifier   [formal_part]
            |   1function0 designator    [formal_part] 1return0 type_mark

         designator ::= identifier | operator_symbol

         operator_symbol ::= string_literal

         formal_part ::=
            (parameter_specification {; parameter_specification})

         parameter_specification ::=
            identifier_list : mode type_mark [:= expression]

         mode ::= [1in0] | 1in0 1out0 | 1out

0     The specification of a procedure specifies its identifier and its 6formal0 6parameters0 (if any).
     The specification of a function specifies its designator, its formal parameters (if any) and the subtype
     of the returned value (the 6result0 6subtype).0 A designator that is an operator symbol is used for
     the overloading of an operator.  The sequence of characters represented by an operator symbol must be an
     operator belonging to one of the six classes of overloadable operators defined in section 4.5 (extra
     spaces are not allowed and the case of letters is not significant).

     A parameter specification with several identifiers is equivalent to a sequence of single parameter
     specifications, as explained in section 3.2.  Each single parameter specification declares a formal
     parameter.  If no mode is explicitly given, the mode 1in0 is assumed.  If a parameter specification
     ends with an expression, the expression is the 6default0 6expression0 of the formal parameter.  A
     default expression is only allowed in a parameter specification if the mode is 1in0 (whether this mode
     is indicated explicitly or implicitly).  The type of a default expression must be that of the
     corresponding formal parameter.

     The use of a name that denotes a formal parameter is not allowed in default expressions of a formal part
     if the specification of the parameter is itself given in this formal part.

     The elaboration of a subprogram declaration elaborates the corresponding formal part.  The elaboration of
     a formal part has no other effect.

     6Examples0 6of0 6subprogram0 6declarations:

0         1procedure0 TRAVERSE_TREE;
         1procedure0 INCREMENT(X : 1in0 1out0 INTEGER);
         1procedure0 RIGHT_INDENT(MARGIN : 1out0 LINE_SIZE);                  6--  see 3.5.4
0         1procedure0 SWITCH(FROM, TO : 1in0 1out0 LINK);                           6--  see 3.8.1

0         1function0 RANDOM 1return0 PROBABILITY;                                6--  see 3.5.7

0         1function0 MIN_CELL(X : LINK) 1return0 CELL;                             6--  see 3.8.1
0         1function0 NEXT_FRAME(K : POSITIVE) 1return0 FRAME;                 6--  see 3.8
0         1function0 DOT_PRODUCT(LEFT,RIGHT: VECTOR) 1return0 REAL;      6--  see 3.6

0         1function0 "*"(LEFT,RIGHT : MATRIX) 1return0 MATRIX;                  6--  see 3.6


0     6Examples0 6of0 6in0 6parameters0 6with0 6default0 6expressions:

0         1procedure0 PRINT_HEADER(PAGES      : 1in0    NATURAL;
                                        HEADER     : 1in0    LINE  :=  (1 .. LINE'LAST => ' ');     6--  see 3.6
0                                        CENTER     : 1in0    BOOLEAN  := TRUE);


     6Notes:

0     The evaluation of default expressions is caused by certain subprogram calls, as described in section
     6.4.2 (default expressions are not evaluated during the elaboration of the subprogram declaration).

     All subprograms can be called recursively and are reentrant.

     6References:0 4 declaration 3.1, elaboration 3.9, evaluation 4.5, expression 4.4, formal parameter
     6.2, function 6.5, identifier 2.3, identifier list 3.2, mode 6.2, name 4.1, elaboration has no other
     effect 3.9, operator 4.5, overloading 6.6 8.7, procedure 6, string literal 2.6, subprogram call 6.4, type
     mark 3.3.2 0

      section lrm-section6-2

     26.2. Formal Parameter Modes

0     The value of an object is said to be 6read0 when this value is evaluated; it is also said to be read
     when one of its subcomponents is read.  The value of a variable is said to be 6updated0 when an
     assignment is performed to the variable, and also (indirectly) when the variable is used as actual
     parameter of a subprogram call or entry call statement that updates its value; it is also said to be
     updated when one of its subcomponents is updated.

     A formal parameter of a subprogram has one of the three following modes:

           1in0      The formal parameter  is a  constant  and  permits   only reading  of
                   the value  of the associated actual parameter.

           1in out0  The formal parameter is a variable  and permits both reading and
                    updating of the  value of the associated actual parameter.

           1out0     The formal parameter is a variable and permits updating of
                    the value of the associated actual parameter.

                    The value  of  a scalar parameter that is not updated by the call is
                    undefined  upon return the same  holds for the  value  of a  scalar subcomponent,
                    other  than a  discriminant.  Reading the  bounds and discriminants of the
                    formal parameter  and  of its subcomponents is allowed,  but no other reading.

     For a scalar parameter, the above effects are achieved by copy:  at the start of each call, if the mode
     is 1in0 or 1in0 1out,0 the value of the actual parameter is copied into the associated formal
     parameter; then after normal completion of the subprogram body, if the mode is 1in0 1out0 or 1out,
0     the value of the formal parameter is copied back into the associated actual parameter.  For a parameter
     whose type is an access type, copy-in is used for all three modes, and copy-back for the modes 1in
0     1out0 and 1out.

0     For a parameter whose type is an array, record, or task type, an implementation may likewise achieve the
     above effects by copy, as for scalar types.  In addition, if copy is used for a parameter of mode
     1out,0 then copy-in is required at least for the bounds and discriminants of the actual parameter and
     of its subcomponents, and also for each subcomponent whose type is an access type.  Alternatively, an
     implementation may achieve these effects by reference, that is, by arranging that every use of the formal
     parameter (to read or to update its value) be treated as a use of the associated actual parameter,
     throughout the execution of the subprogram call.  The language does not define which of these two
     mechanisms is to be adopted for parameter passing, nor whether different calls to the same subprogram are
     to use the same mechanism.  The execution of a program is erroneous if its effect depends on which
     mechanism is selected by the implementation.

     For a parameter whose type is a private type, the above effects are achieved according to the rule that
     applies to the corresponding full type declaration.

     Within the body of a subprogram, a formal parameter is subject to any constraint resulting from the type
     mark given in its parameter specification.  For a formal parameter of an unconstrained array type, the
     bounds are obtained from the actual parameter, and the formal parameter is constrained by these bounds
     (see 3.6.1).  For a formal parameter whose declaration specifies an unconstrained (private or record)
     type with discriminants, the discriminants of the formal parameter are initialized with the values of the
     corresponding discriminants of the actual parameter; the formal parameter is unconstrained if and only if
     the mode is 1in0 1out0 or 1out0 and the variable name given for the actual parameter denotes an
     unconstrained variable (see 3.7.1 and 6.4.1).

     If the actual parameter of a subprogram call is a subcomponent that depends on discriminants of an
     unconstrained record variable, then the execution of the call is erroneous if the value of any of the
     discriminants of the variable is changed by this execution; this rule does not apply if the mode is
     1in0 and the type of the subcomponent is a scalar type or an access type.

     6Notes:

0     For parameters of array and record types, the parameter passing rules have these consequences:

        - If the execution of a subprogram is abandoned as a result of an exception, the final value of
          an actual parameter of such a type can be either its value before the call or a value assigned
          to the formal parameter during the execution of the subprogram.

        - If no actual parameter of such a type is accessible by more than one path, then the effect of a
          subprogram call (unless abandoned) is the same whether or not the implementation uses copying
          for parameter passing.  If, however, there are multiple access paths to such a parameter (for
          example, if a global variable, or another formal parameter, refers to the same actual
          parameter), then the value of the formal is undefined after updating the actual other than by
          updating the formal.  A program using such an undefined value is erroneous.

     The same parameter modes are defined for formal parameters of entries (see 9.5) with the same meaning as
     for subprograms.  Different parameter modes are defined for generic formal parameters (see 12.1.1).

     For all modes, if an actual parameter designates a task, the associated formal parameter designates the
     same task; the same holds for a subcomponent of an actual parameter and the corresponding subcomponent of
     the associated formal parameter.

     6References:0 4 access type 3.8, actual parameter 6.4.1, array type 3.6, assignment 5.2, bound of an
     array 3.6.1, constraint 3.3, depend on a discriminant 3.7.1, discriminant 3.7.1, entry call statement
     9.5, erroneous 1.6, evaluation 4.5, exception 11, expression 4.4, formal parameter 6.1, generic formal
     parameter 12.1, global 8.1, mode 6.1, null access value 3.8, object 3.2, parameter specification 6.1,
     private type 7.4, record type 3.7, scalar type 3.5, subcomponent 3.3, subprogram body 6.3, subprogram
     call statement 6.4, task 9, task type 9.2, type mark 3.3.2, unconstrained array type 3.6, unconstrained
     type with discriminants 3.7.1, unconstrained variable 3.2.1, variable 3.2.1 0

      section lrm-section6-3

     26.3. Subprogram Bodies

0     A subprogram body specifies the execution of a subprogram.

         subprogram_body ::=
            subprogram_specification 1is
0               [  declarative_part]
            1begin
0                  sequence_of_statements
            [  1exception
0                  exception_handler
               {  exception_handler}]
            1end0 [designator];

     The declaration of a subprogram is optional.  In the absence of such a declaration, the subprogram
     specification of the subprogram body (or body stub) acts as the declaration.  For each subprogram
     declaration, there must be a corresponding body (except for a subprogram written in another language, as
     explained in section 13.9).  If both a declaration and a body are given, the subprogram specification of
     the body must conform to the subprogram specification of the declaration (see section 6.3.1 for
     conformance rules).

     If a designator appears at the end of a subprogram body, it must repeat the designator of the subprogram
     specification.

     The elaboration of a subprogram body has no other effect than to establish that the body can from then on
     be used for the execution of calls of the subprogram.

     The execution of a subprogram body is invoked by a subprogram call (see 6.4).  For this execution, after
     establishing the association between formal parameters and actual parameters, the declarative part of the
     body is elaborated, and the sequence of statements of the body is then executed.  Upon completion of the
     body, return is made to the caller (and any necessary copying back of formal to actual parameters occurs
     (see 6.2)).  The optional exception handlers at the end of a subprogram body handle exceptions raised
     during the execution of the sequence of statements of the subprogram body (see 11.4).

     6Note:

0     It follows from the visibility rules that if a subprogram declared in a package is to be visible outside
     the package, a subprogram specification must be given in the visible part of the package.  The same rules
     dictate that a subprogram declaration must be given if a call of the subprogram occurs textually before
     the subprogram body (the declaration must then occur earlier than the call in the program text).  The
     rules given in sections 3.9 and 7.1 imply that a subprogram declaration and the corresponding body must
     both occur immediately within the same declarative region.

     6Example0 6of0 6subprogram0 6body:

0         1procedure0 PUSH(E : 1in0 ELEMENT_TYPE; S : 1in0 1out0 STACK) 1is
0         1begin
0            1if0 S.INDEX = S.SIZE 1then
0               1raise0 STACK_OVERFLOW;
            1else
0               S.INDEX := S.INDEX + 1;
               S.SPACE(S.INDEX) := E;
            1end0 1if0;
         1end0 PUSH;

     6References:0 4 actual parameter 6.4.1, body stub 10.2, conform 6.3.1, declaration 3.1, declarative
     part 3.9, declarative region 8.1, designator 6.1, elaboration 3.9, elaboration has no other effect 3.1,
     exception 11, exception handler 11.2, formal parameter 6.1, occur immediately within 8.1, package 7,
     sequence of statements 5.1, subprogram 6, subprogram call 6.4, subprogram declaration 6.1, subprogram
     specification 6.1, visibility 8.3, visible part 7.2 0

      subsection lrm-section6-3-1



     76.3.1. Conformance Rules

0     Whenever the language rules require or allow the specification of a given subprogram to be provided in
     more than one place, the following variations are allowed at each place:

        - A numeric literal can be replaced by a different numeric literal if and only if both have the
          same value.

        - A simple name can be replaced by an expanded name in which this simple name is the selector, if
          and only if at both places the meaning of the simple name is given by the same declaration.

        - A string literal given as an operator symbol can be replaced by a different string literal if
          and only if both represent the same operator.

     Two subprogram specifications are said to 6conform0 if, apart from comments and the above allowed
     variations, both specifications are formed by the same sequence of lexical elements, and corresponding
     lexical elements are given the same meaning by the visibility and overloading rules.

     Conformance is likewise defined for formal parts, discriminant parts, and type marks (for deferred
     constants and for actual parameters that have the form of a type conversion (see 6.4.1)).

     6Notes:

0     A simple name can be replaced by an expanded name even if the simple name is itself the prefix of a
     selected component.  For example, Q.R can be replaced by P.Q.R if Q is declared immediately within P.

     The following specifications do not conform since they are not formed by the same sequence of lexical
     elements:

         1procedure0 P(X,Y : INTEGER)
         1procedure0 P(X : INTEGER; Y : INTEGER)
         1procedure0 P(X,Y : 1in0 INTEGER)

     6References:0 4 actual parameter 6.4 6.4.1, allow 1.6, comment 2.7, declaration 3.1, deferred constant
     7.4.3, direct visibility 8.3, discriminant part 3.7.1, expanded name 4.1.3, formal part 6.1, lexical
     element 2, name 4.1, numeric literal 2.4, operator symbol 6.1, overloading 6.6 8.7, prefix 4.1, selected
     component 4.1.3, selector 4.1.3, simple name 4.1, subprogram specification 6.1, type conversion 4.6,
     visibility 8.3 0

      subsection lrm-section6-3-2



     76.3.2. Inline Expansion of Subprograms

0     The pragma INLINE is used to indicate that inline expansion of the subprogram body is desired for every
     call of each of the named subprograms.  The form of this pragma is as follows:

         1pragma0 INLINE (name {, name});

     Each name is either the name of a subprogram or the name of a generic subprogram.  The pragma INLINE is
     only allowed at the place of a declarative item in a declarative part or package specification, or after
     a library unit in a compilation, but before any subsequent compilation unit.

     If the pragma appears at the place of a declarative item, each name must denote a subprogram or a generic
     subprogram declared by an earlier declarative item of the same declarative part or package specification.
     If several (overloaded) subprograms satisfy this requirement, the pragma applies to all of them.  If the
     pragma appears after a given library unit, the only name allowed is the name of this unit.  If the name
     of a generic subprogram is mentioned in the pragma, this indicates that inline expansion is desired for
     calls of all subprograms obtained by instantiation of the named generic unit.

     The meaning of a subprogram is not changed by the pragma INLINE.  For each call of the named subprograms,
     an implementation is free to follow or to ignore the recommendation expressed by the pragma.  (Note, in
     particular, that the recommendation cannot generally be followed for a recursive subprogram.)

     6References:0 4 allow 1.6, compilation 10.1, compilation unit 10.1, declarative item 3.9, declarative
     part 3.9, generic subprogram 12.1, generic unit 12 12.1, instantiation 12.3, library unit 10.1, name 4.1,
     overloading 6.6 8.7, package specification 7.1, pragma 2.8, subprogram 6, subprogram body 6.3, subprogram
     call 6.4 0

      section lrm-section6-4

     26.4. Subprogram Calls

0     A subprogram call is either a procedure call statement or a function call; it invokes the execution of
     the corresponding subprogram body.  The call specifies the association of the actual parameters, if any,
     with formal parameters of the subprogram.

         procedure_call_statement ::=
            6procedure0_name [actual_parameter_part];

         function_call ::=
            6function0_name [actual_parameter_part]

         actual_parameter_part ::=
            (parameter_association {, parameter_association})

         parameter_association ::=
            [  formal_parameter =>] actual_parameter

         formal_parameter ::= 6parameter0_simple_name

         actual_parameter ::=
            expression | 6variable0_name | type_mark(6variable0_name)

     Each parameter association associates an actual parameter with a corresponding formal parameter.  A
     parameter association is said to be 6named0 if the formal parameter is named explicitly; it is
     otherwise said to be 6positional.0 For a positional association, the actual parameter corresponds to
     the formal parameter with the same position in the formal part.

     Named associations can be given in any order, but if both positional and named associations are used in
     the same call, positional associations must occur first, at their normal position.  Hence once a named
     association is used, the rest of the call must use only named associations.

     For each formal parameter of a subprogram, a subprogram call must specify exactly one corresponding
     actual parameter.  This actual parameter is specified either explicitly, by a parameter association, or,
     in the absence of such an association, by a default expression (see 6.4.2).

     The parameter associations of a subprogram call are evaluated in some order that is not defined by the
     language.  Similarly, the language rules do not define in which order the values of 1in0 1out0 or
     1out0 parameters are copied back into the corresponding actual parameters (when this is done).

     6Examples0 6of0 6procedure0 6calls:

0         TRAVERSE_TREE;                                                                  6--  see 6.1
0         TABLE_MANAGER.INSERT(E);                                                     6--  see 7.5
0         PRINT_HEADER(128, TITLE, TRUE);                                              6--  see 6.1

0         SWITCH(FROM => X, TO => NEXT);                                              6--  see 6.1
0         PRINT_HEADER(128, HEADER => TITLE, CENTER => TRUE);                  6--  see 6.1
0         PRINT_HEADER(HEADER => TITLE, CENTER => TRUE, PAGES => 128);      6--  see 6.1

0     6Examples0 6of0 6function0 6calls:

0         DOT_PRODUCT(U, V)    6--  see 6.1 and 6.5
0         CLOCK                     6--  see 9.6


0     6References:0 4 default expression for a formal parameter 6.1, erroneous 1.6, expression 4.4, formal
     parameter 6.1, formal part 6.1, name 4.1, simple name 4.1, subprogram 6, type mark 3.3.2, variable 3.2.1
     0

      subsection lrm-section6-4-1



     76.4.1. Parameter Associations

0     Each actual parameter must have the same type as the corresponding formal parameter.

     An actual parameter associated with a formal parameter of mode 1in0 must be an expression; it is
     evaluated before the call.

     An actual parameter associated with a formal parameter of mode 1in0 1out0 or 1out0 must be either
     the name of a variable, or of the form of a type conversion whose argument is the name of a variable.  In
     either case, for the mode 1in0 1out,0 the variable must not be a formal parameter of mode 1out0 or
     a subcomponent thereof.  For an actual parameter that has the form of a type conversion, the type mark
     must conform (see 6.3.1) to the type mark of the formal parameter; the allowed operand and target types
     are the same as for type conversions (see 4.6).

     The variable name given for an actual parameter of mode 1in0 1out0 or 1out0 is evaluated before the
     call.  If the actual parameter has the form of a type conversion, then before the call, for a parameter
     of mode 1in0 1out,0 the variable is converted to the specified type; after (normal) completion of the
     subprogram body, for a parameter of mode 1in0 1out0 or 1out,0 the formal parameter is converted
     back to the type of the variable.  (The type specified in the conversion must be that of the formal
     parameter.)

     The following constraint checks are performed for parameters of scalar and access types:

        - Before the call:  for a parameter of mode 1in0 or 1in0 1out,0 it is checked that the
          value of the actual parameter belongs to the subtype of the formal parameter.

        - After (normal) completion of the subprogram body:  for a parameter of mode 1in0 1out0 or
          1out,0 it is checked that the value of the formal parameter belongs to the subtype of the
          actual variable.  In the case of a type conversion, the value of the formal parameter is
          converted back and the check applies to the result of the conversion.

     In each of the above cases, the execution of the program is erroneous if the checked value is undefined.

     For other types, for all modes, a check is made before the call as for scalar and access types; no check
     is made upon return.

     The exception CONSTRAINT_ERROR is raised at the place of the subprogram call if either of these checks
     fails.

     6Note:

0     For array types and for types with discriminants, the check before the call is sufficient (a check upon
     return would be redundant) if the type mark of the formal parameter denotes a constrained subtype, since
     neither array bounds nor discriminants can then vary.

     If this type mark denotes an unconstrained array type, the formal parameter is constrained with the
     bounds of the corresponding actual parameter and no check (neither before the call nor upon return) is
     needed (see 3.6.1).  Similarly, no check is needed if the type mark denotes an unconstrained type with
     discriminants, since the formal parameter is then constrained exactly as the corresponding actual
     parameter (see 3.7.1).

     6References:0 4 actual parameter 6.4, array bound 3.6, array type 3.6, call of a subprogram 6.4,
     conform 6.3.1, constrained subtype 3.3, constraint 3.3, constraint_error exception 11.1, discriminant
     3.7.1, erroneous 1.6, evaluation 4.5, evaluation of a name 4.1, expression 4.4, formal parameter 6.1,
     mode 6.1, name 4.1, parameter association 6.4, subtype 3.3, type 3.3, type conversion 4.6, type mark
     3.3.2, unconstrained array type 3.6, unconstrained type with discriminants 3.7.1, undefined value 3.2.1,
     variable 3.2.1 0

      subsection lrm-section6-4-2



     76.4.2. Default Parameters

0     If a parameter specification includes a default expression for a parameter of mode 1in,0 then
     corresponding subprogram calls need not include a parameter association for the parameter.  If a
     parameter association is thus omitted from a call, then the rest of the call, following any initial
     positional associations, must use only named associations.

     For any omitted parameter association, the default expression is evaluated before the call and the
     resulting value is used as an implicit actual parameter.

     6Examples0 6of0 6procedures0 6with0 6default0 6values:

0         1procedure0 ACTIVATE( PROCESS   : 1in0 PROCESS_NAME;
            AFTER  : 1in0 PROCESS_NAME := NO_PROCESS;
            WAIT   : 1in0 DURATION := 0.0;
            PRIOR  : 1in0 BOOLEAN := FALSE);

         1procedure0 PAIR(LEFT, RIGHT : PERSON_NAME := 1new0 PERSON);

     6Examples0 6of0 6their0 6calls:

0         ACTIVATE(X);
         ACTIVATE(X, AFTER => Y);
         ACTIVATE(X, WAIT => 60.0, PRIOR => TRUE);
         ACTIVATE(X, Y, 10.0, FALSE);

         PAIR;
         PAIR(LEFT => 1new0 PERSON, RIGHT => 1new0 PERSON);

     6Note:

0     If a default expression is used for two or more parameters in a multiple parameter specification, the
     default expression is evaluated once for each omitted parameter.  Hence in the above examples, the two
     calls of PAIR are equivalent.

     6References:0 4 actual parameter 6.4.1, default expression for a formal parameter 6.1, evaluation 4.5,
     formal parameter 6.1, mode 6.1, named parameter association 6.4, parameter association 6.4, parameter
     specification 6.1, positional parameter association 6.4, subprogram call 6.4 0

      section lrm-section6-5

     26.5. Function Subprograms

0     A function is a subprogram that returns a value (the result of the function call).  The specification of
     a function starts with the reserved word 1function,0 and the parameters, if any, must have the mode
     1in0 (whether this mode is specified explicitly or implicitly).  The statements of the function body
     (excluding statements of program units that are inner to the function body) must include one or more
     return statements specifying the returned value.

     The exception PROGRAM_ERROR is raised if a function body is left otherwise than by a return statement.
     This does not apply if the execution of the function is abandoned as a result of an exception.

     6Example:

0         1function0 DOT_PRODUCT(LEFT, RIGHT : VECTOR) 1return0 REAL 1is
0            SUM : REAL := 0.0;
         1begin
0            CHECK(LEFT'FIRST = RIGHT'FIRST 1and0 LEFT'LAST = RIGHT'LAST);
            1for0 J 1in0 LEFT'RANGE 1loop
0               SUM := SUM + LEFT(J)*RIGHT(J);
            1end0 1loop0;
            1return0 SUM;
         1end0 DOT_PRODUCT;

     6References:0 4 exception 11, formal parameter 6.1, function 6.1, function body 6.3, function call
     6.4, function specification 6.1, mode 6.1, program_error exception 11.1, raising of exceptions 11, return
     statement 5.8, statement 5 0

      section lrm-section6-6

     26.6. Parameter and Result Type Profile - Overloading of Subprograms

0     Two formal parts are said to have the same 6parameter0 6type0 6profile0 if and only if they have
     the same number of parameters, and at each parameter position corresponding parameters have the same base
     type.  A subprogram or entry has the same 6parameter0 6and0 6result0 6type0 6profile0 as
     another subprogram or entry if and only if both have the same parameter type profile, and either both are
     functions with the same result base type, or neither of the two is a function.

     The same subprogram identifier or operator symbol can be used in several subprogram specifications.  The
     identifier or operator symbol is then said to be 6overloaded;0 the subprograms that have this
     identifier or operator symbol are also said to be overloaded and to overload each other.  As explained in
     section 8.3, if two subprograms overload each other, one of them can hide the other only if both
     subprograms have the same parameter and result type profile (see section 8.3 for the other requirements
     that must be met for hiding).

     A call to an overloaded subprogram is ambiguous (and therefore illegal) if the name of the subprogram,
     the number of parameter associations, the types and the order of the actual parameters, the names of the
     formal parameters (if named associations are used), and the result type (for functions) are not
     sufficient to determine exactly one (overloaded) subprogram specification.

     6Examples0 6of0 6overloaded0 6subprograms:

0         1procedure0 PUT(X   : INTEGER);
         1procedure0 PUT(X   : STRING);

         1procedure0 SET(TINT   : COLOR);
         1procedure0 SET(SIGNAL    : LIGHT);

     6Examples0 6of0 6calls:

0         PUT(28);
         PUT("NO POSSIBLE AMBIGUITY HERE");

         SET(TINT  => RED);
         SET(SIGNAL   => RED);
         SET(COLOR'(RED));

         6--  SET(RED) would be ambiguous since RED may
0         6--  denote a value either of type COLOR or of type LIGHT

0     6Notes:

0     The notion of parameter and result type profile does not include parameter names, parameter modes,
     parameter subtypes, default expressions and their presence or absence.

     Ambiguities may (but need not) arise when actual parameters of the call of an overloaded subprogram are
     themselves overloaded function calls, literals, or aggregates.  Ambiguities may also (but need not) arise
     when several overloaded subprograms belonging to different packages are visible.  These ambiguities can
     usually be resolved in several ways:  qualified expressions can be used for some or all actual
     parameters, and for the result, if any; the name of the subprogram can be expressed more explicitly as an
     expanded name; finally, the subprogram can be renamed.

     6References:0 4 actual parameter 6.4.1, aggregate 4.3, base type 3.3, default expression for a formal
     parameter 6.1, entry 9.5, formal parameter 6.1, function 6.5, function call 6.4, hiding 8.3, identifier
     2.3, illegal 1.6, literal 4.2, mode 6.1, named parameter association 6.4, operator symbol 6.1,
     overloading 8.7, package 7, parameter of a subprogram 6.2, qualified expression 4.7, renaming declaration
     8.5, result subtype 6.1, subprogram 6, subprogram specification 6.1, subtype 3.3, type 3.3 0

      section lrm-section6-7

     26.7. Overloading of Operators

0     The declaration of a function whose designator is an operator symbol is used to overload an operator.
     The sequence of characters of the operator symbol must be either a logical, a relational, a binary
     adding, a unary adding, a multiplying, or a highest precedence operator (see 4.5).  Neither membership
     tests nor the short-circuit control forms are allowed as function designators.

     The subprogram specification of a unary operator must have a single parameter.  The subprogram
     specification of a binary operator must have two parameters; for each use of this operator, the first
     parameter takes the left operand as actual parameter, the second parameter takes the right operand.
     Similarly, a generic function instantiation whose designator is an operator symbol is only allowed if the
     specification of the generic function has the corresponding number of parameters.  Default expressions
     are not allowed for the parameters of an operator (whether the operator is declared with an explicit
     subprogram specification or by a generic instantiation).

     For each of the operators "+" and "-", overloading is allowed both as a unary and as a binary operator.

     The explicit declaration of a function that overloads the equality operator "=", other than by a renaming
     declaration, is only allowed if both parameters are of the same limited type.  An overloading of equality
     must deliver a result of the predefined type BOOLEAN; it also implicitly overloads the inequality
     operator "/=" so that this still gives the complementary result to the equality operator.  Explicit
     overloading of the inequality operator is not allowed.

     A renaming declaration whose designator is the equality operator is only allowed to rename another
     equality operator.  (For example, such a renaming declaration can be used when equality is visible by
     selection but not directly visible.)

     6Note:

0     Overloading of relational operators does not affect basic comparisons such as testing for membership in a
     range or the choices in a case statement.

     6Examples:

0         1function0 "+" (LEFT, RIGHT : MATRIX)    1return0 MATRIX;
         1function0 "+" (LEFT, RIGHT : VECTOR)    1return0 VECTOR;

         6--  assuming that A, B, and C are of the type VECTOR
0         6--  the three following assignments are equivalent

0         A := B + C;

         A := "+"(B, C);
         A := "+"(LEFT => B, RIGHT => C);

     6References:0 4 allow 1.6, actual parameter 6.4.1, binary adding operator 4.5 4.5.3, boolean
     predefined type 3.5.3, character 2.1, complementary result 4.5.2, declaration 3.1, default expression for
     a formal parameter 6.1, designator 6.1, directly visible 8.3, equality operator 4.5, formal parameter
     6.1, function declaration 6.1, highest precedence operator 4.5 4.5.6, implicit declaration 3.1,
     inequality operator 4.5.2, limited type 7.4.4, logical operator 4.5 4.5.1, membership test 4.5 4.5.2,
     multiplying operator 4.5 4.5.5, operator 4.5, operator symbol 6.1, overloading 6.6 8.7, relational
     operator 4.5 4.5.2, short-circuit control form 4.5 4.5.1, type definition 3.3.1, unary adding operator
     4.5 4.5.4, visible by selection 8.3 0

      chapter lrm-chapter-7



                                                    17. Packages

0     Packages are one of the four forms of program unit, of which programs can be composed.  The other forms
     are subprograms, task units, and generic units.

     Packages allow the specification of groups of logically related entities.  In their simplest form
     packages specify pools of common object and type declarations.  More generally, packages can be used to
     specify groups of related entities including also subprograms that can be called from outside the
     package, while their inner workings remain concealed and protected from outside users.

     6References:0 4 generic unit 12, program unit 6, subprogram 6, task unit 9, type declaration 3.3.1 0

      section lrm-section7-1

     27.1. Package Structure

0     A package is generally provided in two parts:  a package specification and a package body.  Every package
     has a package specification, but not all packages have a package body.

         package_declaration ::= package_specification;

         package_specification ::=

           1package0 identifier 1is
0              {basic_declarative_item}
           [  1private
0              {basic_declarative_item}]
           1end0 [6package0_simple_name]

         package_body ::=

           1package0 1body0 6package0_simple_name 1is
0              [  declarative_part]
           [  1begin
0                 sequence_of_statements
           [  1exception
0                 exception_handler
              {  exception_handler}]]
           1end0 [6package0_simple_name];

     The simple name at the start of a package body must repeat the package identifier.  Similarly if a simple
     name appears at the end of the package specification or body, it must repeat the package identifier.

     If a subprogram declaration, a package declaration, a task declaration, or a generic declaration is a
     declarative item of a given package specification, then the body (if there is one) of the program unit
     declared by the declarative item must itself be a declarative item of the declarative part of the body of
     the given package.

     6Notes:

0     A simple form of package, specifying a pool of objects and types, does not require a package body.  One
     of the possible uses of the sequence of statements of a package body is to initialize such objects.  For
     each subprogram declaration there must be a corresponding body (except for a subprogram written in
     another language, as explained in section 13.9).  If the body of a program unit is a body stub, then a
     separately compiled subunit containing the corresponding proper body is required for the program unit
     (see 10.2).  A body is not a basic declarative item and so cannot appear in a package specification.

     A package declaration is either a library package (see 10.2) or a declarative item declared within
     another program unit.

     6References:0 4 basic declarative item 3.9, body stub 10.2, declarative item 3.9, declarative part
     3.9, exception handler 11.2, generic body 12.2, generic declaration 12.1, identifier 2.3, library unit
     10.1, object 3.2, package body 7.3, program unit 6, proper body 3.9, sequence of statements 5.1, simple
     name 4.1, subprogram body 6.3, subprogram declaration 6.1, subunit 10.2, task body 9.1, task declaration
     9.1, type 3.3 0

      section lrm-section7-2

     27.2. Package Specifications and Declarations

0     The first list of declarative items of a package specification is called the 6visible0 6part0 of the
     package.  The optional list of declarative items after the reserved word 1private0 is called the
     6private0 6part0 of the package.

     An entity declared in the private part of a package is not visible outside the package itself (a name
     denoting such an entity is only possible within the package).  In contrast, expanded names denoting
     entities declared in the visible part can be used even outside the package; furthermore, direct
     visibility of such entities can be achieved by means of use clauses (see 4.1.3 and 8.4).

     The elaboration of a package declaration consists of the elaboration of its basic declarative items in
     the given order.

     6Notes:

0     The visible part of a package contains all the information that another program unit is able to know
     about the package.  A package consisting of only a package specification (that is, without a package
     body) can be used to represent a group of common constants or variables, or a common pool of objects and
     types, as in the examples below.

     6Example0 6of0 6a0 6package0 6describing0 6a0 6group0 6of0 6common0 6variables:

0         1package0 PLOTTING_DATA 1is
0           PEN_UP : BOOLEAN;

           CONVERSION_FACTOR,

           X_OFFSET,    Y_OFFSET,
           X_MIN,    Y_MIN,
           X_MAX,    Y_MAX:   REAL;     6--  see 3.5.7


0           X_VALUE   : 1array0 (1 .. 500)  1of0 REAL;
           Y_VALUE   : 1array0 (1 .. 500)  1of0 REAL;
         1end0 PLOTTING_DATA;


     6Example0 6of0 6a0 6package0 6describing0 6a0 6common0 6pool0 6of0 6objects0 6and
0     6types:

0         1package0 WORK_DATA 1is
0           1type0 DAY 1is0 (MON, TUE, WED, THU, FRI, SAT, SUN);

           1type0 HOURS_SPENT  1is0 1delta0 0.25 1range0 0.0 .. 24.0;
           1type0 TIME_TABLE   1is0 1array0 (DAY) 1of0 HOURS_SPENT;


           WORK_HOURS   : TIME_TABLE;
           NORMAL_HOURS    : 1constant0 TIME_TABLE :=
                 (MON .. THU => 8.25, FRI => 7.0, SAT | SUN => 0.0);
         1end0 WORK_DATA;

     6References:0 4 basic declarative item 3.9, constant 3.2.1, declarative item 3.9, direct visibility
     8.3, elaboration 3.9, expanded name 4.1.3, name 4.1, number declaration 3.2.2, object declaration 3.2.1,
     package 7, package declaration 7.1, package identifier 7.1, package specification 7.1, scope 8.2, simple
     name 4.1, type declaration 3.3.1, use clause 8.4, variable 3.2.1 0

      section lrm-section7-3

     27.3. Package Bodies

0     In contrast to the entities declared in the visible part of a package specification, the entities
     declared in the package body are only visible within the package body itself.  As a consequence, a
     package with a package body can be used for the construction of a group of related subprograms (a
     6package0 in the usual sense), in which the logical operations available to the users are clearly
     isolated from the internal entities.

     For the elaboration of a package body, its declarative part is first elaborated, and its sequence of
     statements (if any) is then executed.  The optional exception handlers at the end of a package body
     service exceptions raised during the execution of the sequence of statements of the package body.

     6Notes:

0     A variable declared in the body of a package is only visible within this body and, consequently, its
     value can only be changed within the package body.  In the absence of local tasks, the value of such a
     variable remains unchanged between calls issued from outside the package to subprograms declared in the
     visible part.  The properties of such a variable are similar to those of an "own" variable of Algol 60.

     The elaboration of the body of a subprogram declared in the visible part of a package is caused by the
     elaboration of the body of the package.  Hence a call of such a subprogram by an outside program unit
     raises the exception PROGRAM_ERROR if the call takes place before the elaboration of the package body
     (see 3.9).

     6Example0 6of0 6a0 6package:

0         1package0 RATIONAL_NUMBERS 1is

0           1type0 RATIONAL 1is
0              1record
0                 NUMERATOR    : INTEGER;
                 DENOMINATOR  : POSITIVE;
              1end0 1record0;

           1function0 EQUAL   (X,Y : RATIONAL)   1return0 BOOLEAN;

           1function0 "/"  (X,Y : INTEGER)           1return0 RATIONAL; 6-- to construct a rational number

0           1function0 "+"  (X,Y : RATIONAL)         1return0 RATIONAL;
           1function0 "-"  (X,Y : RATIONAL)         1return0 RATIONAL;
           1function0 "*"  (X,Y : RATIONAL)         1return0 RATIONAL;
           1function0 "/"  (X,Y : RATIONAL)         1return0 RATIONAL;
         1end0;

         1package0 1body0 RATIONAL_NUMBERS 1is

0           1procedure0 SAME_DENOMINATOR (X,Y : 1in0 1out0 RATIONAL) 1is
0           1begin
0              6--  reduces X and Y to the same denominator:
0              ...
           1end0;

           1function0 EQUAL(X,Y : RATIONAL) 1return0 BOOLEAN 1is
0              U,V : RATIONAL;
           1begin
0              U := X;
              V := Y;
              SAME_DENOMINATOR (U,V);
              1return0 U.NUMERATOR = V.NUMERATOR;
           1end0 EQUAL;


           1function0 "/"   (X,Y : INTEGER)   1return0 RATIONAL IS
           1begin
0              1if0 Y > 0 1then

0                 1return0 (NUMERATOR => X,    DENOMINATOR => Y);
              1else
0                 1return0 (NUMERATOR => -X,   DENOMINATOR => -Y);
              1end0 1if0;
           1end0 "/";


           1function0 "+"   (X,Y : RATIONAL)  1return0 RATIONAL 1is0    ...  1end0 "+";
           1function0 "-"   (X,Y : RATIONAL)  1return0 RATIONAL 1is0    ...  1end0 "-";
           1function0 "*"   (X,Y : RATIONAL)  1return0 RATIONAL 1is0    ...  1end0 "*";
           1function0 "/"   (X,Y : RATIONAL)  1return0 RATIONAL 1is0    ...  1end0 "/";

         1end0 RATIONAL_NUMBERS;

     6References:0 4 declaration 3.1, declarative part 3.9, elaboration 3.1 3.9, exception 11, exception
     handler 11.2, name 4.1, package specification 7.1, program unit 6, program_error exception 11.1, sequence
     of statements 5.1, subprogram 6, variable 3.2.1, visible part 7.2 0

      section lrm-section7-4

     27.4. Private Type and Deferred Constant Declarations

0     The declaration of a type as a private type in the visible part of a package serves to separate the
     characteristics that can be used directly by outside program units (that is, the logical properties) from
     other characteristics whose direct use is confined to the package (the details of the definition of the
     type itself).  Deferred constant declarations declare constants of private types.

         private_type_declaration ::=
           1type0 identifier [discriminant_part] 1is0 [1limited0] 1private;

0         deferred_constant_declaration ::=
           identifier_list : 1constant0 type_mark;

     A private type declaration is only allowed as a declarative item of the visible part of a package, or as
     the generic parameter declaration for a generic formal type in a generic formal part.

     The type mark of a deferred constant declaration must denote a private type or a subtype of a private
     type; a deferred constant declaration and the declaration of the corresponding private type must both be
     declarative items of the visible part of the same package.  A deferred constant declaration with several
     identifiers is equivalent to a sequence of single deferred constant declarations as explained in section
     3.2.

     6Examples0 6of0 6private0 6type0 6declarations:

0         1type0 KEY 1is0 1private0;
         1type0 FILE_NAME 1is0 1limited0 1private0;

     6Example0 6of0 6deferred0 6constant0 6declaration:

0         NULL_KEY : 1constant0 KEY;

     6References:0 4 constant 3.2.1, declaration 3.1, declarative item 3.9, deferred constant 7.4.3,
     discriminant part 3.7.1, generic formal part 12.1, generic formal type 12.1, generic parameter
     declaration 12.1, identifier 2.3, identifier list 3.2, limited type 7.4.4, package 7, private type 7.4.1,
     program unit 6, subtype 3.3, type 3.3, type mark 3.3.2, visible part 7.2 0

      subsection lrm-section7-4-1



     77.4.1. Private Types

0     If a private type declaration is given in the visible part of a package, then a corresponding declaration
     of a type with the same identifier must appear as a declarative item of the private part of the package.
     The corresponding declaration must be either a full type declaration or the declaration of a task type.
     In the rest of this section explanations are given in terms of full type declarations; the same rules
     apply also to declarations of task types.

     A private type declaration and the corresponding full type declaration define a single type.  The private
     type declaration, together with the visible part, define the operations that are available to outside
     program units (see section 7.4.2 on the operations that are available for private types).  On the other
     hand, the full type declaration defines other operations whose direct use is only possible within the
     package itself.

     If the private type declaration includes a discriminant part, the full declaration must include a
     discriminant part that conforms (see 6.3.1 for the conformance rules) and its type definition must be a
     record type definition.  Conversely, if the private type declaration does not include a discriminant
     part, the type declared by the full type declaration (the 6full0 6type)0 must not be an unconstrained
     type with discriminants.  The full type must not be an unconstrained array type.  A limited type (in
     particular a task type) is allowed for the full type only if the reserved word 1limited0 appears in the
     private type declaration (see 7.4.4).

     Within the specification of the package that declares a private type and before the end of the
     corresponding full type declaration, a restriction applies to the use of a name that denotes the private
     type or a subtype of the private type and, likewise, to the use of a name that denotes any type or
     subtype that has a subcomponent of the private type.  The only allowed occurrences of such a name are in
     a deferred constant declaration, a type or subtype declaration, a subprogram specification, or an entry
     declaration; moreover, occurrences within derived type definitions or within simple expressions are not
     allowed.

     The elaboration of a private type declaration creates a private type.  If the private type declaration
     has a discriminant part, this elaboration includes that of the discriminant part.  The elaboration of the
     full type declaration consists of the elaboration of the type definition; the discriminant part, if any,
     is not elaborated (since the conforming discriminant part of the private type declaration has already
     been elaborated).

     6Notes:

0     It follows from the given rules that neither the declaration of a variable of a private type, nor the
     creation by an allocator of an object of the private type are allowed before the full declaration of the
     type.  Similarly before the full declaration, the name of the private type cannot be used in a generic
     instantiation or in a representation clause.

     6References:0 4 allocator 4.8, array type 3.6, conform 6.3.1, declarative item 3.9, deferred constant
     declaration 7.4.3, derived type 3.4, discriminant part 3.7.1, elaboration 3.9, entry declaration 9.5,
     expression 4.4, full type declaration 3.3.1, generic instantiation 12.3, identifier 2.3, incomplete type
     declaration 3.8.1, limited type 7.4.4, name 4.1, operation 3.3, package 7, package specification 7.1,
     private part 7.2, private type 7.4, private type declaration 7.4, record type definition 3.7,
     representation clause 13.1, reserved word 2.9, subcomponent 3.3, subprogram specification 6.1, subtype
     3.3, subtype declaration 3.3.2, type 3.3, type declaration 3.3.1, type definition 3.3.1, unconstrained
     array type 3.6, variable 3.2.1, visible part 7.2 0

      subsection lrm-section7-4-2



     77.4.2. Operations of a Private Type

0     The operations that are implicitly declared by a private type declaration include basic operations.
     These are the operations involved in assignment (unless the reserved word 1limited0 appears in the
     declaration), membership tests, selected components for the selection of any discriminant, qualification,
     and explicit conversions.

     For a private type T, the basic operations also include the attributes T'BASE (see 3.3.3) and T'SIZE (see
     13.7.2).  For an object A of a private type, the basic operations include the attribute A'CONSTRAINED if
     the private type has discriminants (see 3.7.4), and in any case, the attributes A'SIZE and A'ADDRESS (see
     13.7.2).

     Finally, the operations implicitly declared by a private type declaration include the predefined
     comparison for equality and inequality unless the reserved word 1limited0 appears in the private type
     declaration.

     The above operations, together with subprograms that have a parameter or result of the private type and
     that are declared in the visible part of the package, are the only operations from the package that are
     available outside the package for the private type.

     Within the package that declares the private type, the additional operations implicitly declared by the
     full type declaration are also available.  However, the redefinition of these implicitly declared
     operations is allowed within the same declarative region, including between the private type declaration
     and the corresponding full declaration.  An explicitly declared subprogram hides an implicitly declared
     operation that has the same parameter and result type profile (this is only possible if the implicitly
     declared operation is a derived subprogram or a predefined operator).

     If a composite type has subcomponents of a private type and is declared outside the package that declares
     the private type, then the operations that are implicitly declared by the declaration of the composite
     type include all operations that only depend on the characteristics that result from the private type
     declaration alone.  (For example the operator < is not included for a one-dimensional array type.)

     If the composite type is itself declared within the package that declares the private type (including
     within an inner package or generic package), then additional operations that depend on the
     characteristics of the full type are implicitly declared, as required by the rules applicable to the
     composite type (for example the operator < is declared for a one-dimensional array type if the full type
     is discrete).  These additional operations are implicitly declared at the earliest place within the
     immediate scope of the composite type and after the full type declaration.

     The same rules apply to the operations that are implicitly declared for an access type whose designated
     type is a private type or a type declared by an incomplete type declaration.

     For every private type or subtype T the following attribute is defined:

     T'CONSTRAINED       Yields the value FALSE if T denotes an unconstrained nonformal private type with
                         discriminants; also yields the value FALSE if T denotes a generic formal private
                         type, and the associated actual subtype is either an unconstrained type with
                         discriminants or an unconstrained array type; yields the value TRUE otherwise.  The
                         value of this attribute is of the predefined type BOOLEAN.

     6Note:

0     A private type declaration and the corresponding full type declaration define two different views of one
     and the same type.  Outside of the defining package the characteristics of the type are those defined by
     the visible part.  Within these outside program units the type is just a private type and any language
     rule that applies only to another class of types does not apply.  The fact that the full declaration
     might 6implement0 the private type with a type of a particular class (for example, as an array type) is
     only relevant within the package itself.

     The consequences of this actual implementation are, however, valid everywhere.  For example:  any default
     initialization of components takes place; the attribute SIZE provides the size of the full type; task
     dependence rules still apply to components that are task objects.

     6Example:

0         1package0 KEY_MANAGER 1is
0           1type0 KEY 1is0 1private0;
           NULL_KEY : 1constant0 KEY;
           1procedure0 GET_KEY(K : 1out0 KEY);
           1function0 "<" (X, Y : KEY) 1return0 BOOLEAN;
         1private
0           1type0 KEY 1is0 1new0 NATURAL;
           NULL_KEY : 1constant0 KEY := 0;
         1end0;

         1package0 1body0 KEY_MANAGER 1is
0           LAST_KEY : KEY := 0;
           1procedure0 GET_KEY(K : 1out0 KEY) 1is
0           1begin
0              LAST_KEY := LAST_KEY + 1;
              K := LAST_KEY;
           1end0 GET_KEY;

           1function0 "<" (X, Y : KEY) 1return0 BOOLEAN 1is
0           1begin
0              1return0 INTEGER(X) < INTEGER(Y);
           1end0 "<";
         1end0 KEY_MANAGER;

     6Notes0 6on0 6the0 6example:

0     Outside of the package KEY_MANAGER, the operations available for objects of type KEY include assignment,
     the comparison for equality or inequality, the procedure GET_KEY and the operator "<"; they do not
     include other relational operators such as ">=", or arithmetic operators.

     The explicitly declared operator "<" hides the predefined operator "<" implicitly declared by the full
     type declaration.  Within the body of the function, an explicit conversion of X and Y to the type INTEGER
     is necessary to invoke the "<" operator of this type.  Alternatively, the result of the function could be
     written as 1not0 (X >= Y), since the operator ">=" is not redefined.

     The value of the variable LAST_KEY, declared in the package body, remains unchanged between calls of the
     procedure GET_KEY.  (See also the Notes of section 7.3.)

     6References:0 4 assignment 5.2, attribute 4.1.4, basic operation 3.3.3, component 3.3, composite type
     3.3, conversion 4.6, declaration 3.1, declarative region 8.1, derived subprogram 3.4, derived type 3.4,
     dimension 3.6, discriminant 3.3, equality 4.5.2, full type 7.4.1, full type declaration 3.3.1, hiding
     8.3, immediate scope 8.2, implicit declaration 3.1, incomplete type declaration 3.8.1, membership test
     4.5, operation 3.3, package 7, parameter of a subprogram 6.2, predefined function 8.6, predefined
     operator 4.5, private type 7.4, private type declaration 7.4, program unit 6, qualification 4.7,
     relational operator 4.5, selected component 4.1.3, subprogram 6, task dependence 9.4, visible part 7.2 0

      subsection lrm-section7-4-3



     77.4.3. Deferred Constants

0     If a deferred constant declaration is given in the visible part of a package then a constant declaration
     (that is, an object declaration declaring a constant object, with an explicit initialization) with the
     same identifier must appear as a declarative item of the private part of the package.  This object
     declaration is called the 6full0 declaration of the deferred constant.  The type mark given in the full
     declaration must conform to that given in the deferred constant declaration (see 6.3.1).  Multiple or
     single declarations are allowed for the deferred and the full declarations, provided that the equivalent
     single declarations conform.

     Within the specification of the package that declares a deferred constant and before the end of the
     corresponding full declaration, the use of a name that denotes the deferred constant is only allowed in
     the default expression for a record component or for a formal parameter (not for a generic formal
     parameter).

     The elaboration of a deferred constant declaration has no other effect.

     The execution of a program is erroneous if it attempts to use the value of a deferred constant before the
     elaboration of the corresponding full declaration.

     6Note:

0     The full declaration for a deferred constant that has a given private type must not appear before the
     corresponding full type declaration.  This is a consequence of the rules defining the allowed uses of a
     name that denotes a private type (see 7.4.1).

     6References:0 4 conform 6.3.1, constant declaration 3.2.1, declarative item 3.9, default expression
     for a discriminant 3.7.1, deferred constant 7.4, deferred constant declaration 7.4, elaboration has no
     other effect 3.1, formal parameter 6.1, generic formal parameter 12.1 12.3, identifier 2.3, object
     declaration 3.2.1, package 7, package specification 7.1, private part 7.2, record component 3.7, type
     mark 3.3.2, visible part 7.2 0

      subsection lrm-section7-4-4



     77.4.4. Limited Types

0     A limited type is a type for which neither assignment nor the predefined comparison for equality and
     inequality is 6implicitly0 declared.

     A private type declaration that includes the reserved word 1limited0 declares a limited type.  A task
     type is a limited type.  A type derived from a limited type is itself a limited type.  Finally, a
     composite type is limited if the type of any of its subcomponents is limited.

     The operations available for a private type that is limited are as given in section 7.4.2 for private
     types except for the absence of assignment and of a predefined comparison for equality and inequality.

     For a formal parameter whose type is limited and whose declaration occurs in an explicit subprogram
     declaration, the mode 1out0 is only allowed if this type is private and the subprogram declaration
     occurs within the visible part of the package that declares the private type.  The same holds for formal
     parameters of entry declarations and of generic procedure declarations.  The corresponding full type must
     not be limited if the mode 1out0 is used for any such formal parameter.  Otherwise, the corresponding
     full type is allowed (but not required) to be a limited type (in particular, it is allowed to be a task
     type).  If the full type corresponding to a limited private type is not itself limited, then assignment
     for the type is available within the package, but not outside.

     The following are consequences of the rules for limited types:

        - An explicit initialization is not allowed in an object declaration if the type of the object is
          limited.

        - A default expression is not allowed in a component declaration if the type of the record
          component is limited.

        - An explicit initial value is not allowed in an allocator if the designated type is limited.

        - A generic formal parameter of mode 1in0 must not be of a limited type.

     6Notes:

0     The above rules do not exclude a default expression for a formal parameter of a limited type; they do not
     exclude a deferred constant of a limited type if the full type is not limited.  An explicit declaration
     of an equality operator is allowed for a limited type (see 6.7).

     Aggregates are not available for a limited composite type (see 3.6.2 and 3.7.4).  Catenation is not
     available for a limited array type (see 3.6.2).

     6Example:

0         1package0 I_O_PACKAGE 1is
0           1type0 FILE_NAME 1is0 1limited0 1private0;


           1procedure0 OPEN   (F  : 1in0 1out0 FILE_NAME);
           1procedure0 CLOSE  (F  : 1in0 1out0 FILE_NAME);
           1procedure0 READ   (F  : 1in0 FILE_NAME; ITEM : 1out0  INTEGER);
           1procedure0 WRITE  (F  : 1in0 FILE_NAME; ITEM : 1in0   INTEGER);
         1private
0           1type0 FILE_NAME 1is
0              1record
0                 INTERNAL_NAME : INTEGER := 0;
              1end0 1record0;
         1end0 I_O_PACKAGE;

         1package0 1body0 I_O_PACKAGE 1is
0           LIMIT : 1constant0 := 200;
           1type0 FILE_DESCRIPTOR 1is0 1record0  ...  1end0 1record0;
           DIRECTORY : 1array0 (1 .. LIMIT) 1of0 FILE_DESCRIPTOR;
           ...


           1procedure0 OPEN   (F : 1IN0 1out0 FILE_NAME) 1is0  ...  1end0;
           1procedure0 CLOSE  (F : 1in0 1out0 FILE_NAME) 1is0  ...  1end0;
           1procedure0 READ   (F : 1in0 FILE_NAME; ITEM : 1out0   INTEGER) 1is0 ... 1end0;
           1procedure0 WRITE  (F : 1in0 FILE_NAME; ITEM : 1in0    INTEGER) 1is0 ... 1end0;
         1begin
0           ...
         1end0 I_O_PACKAGE;

     6Notes0 6on0 6the0 6example:

0     In the example above, an outside subprogram making use of I_O_PACKAGE may obtain a file name by calling
     OPEN and later use it in calls to READ and WRITE.  Thus, outside the package, a file name obtained from
     OPEN acts as a kind of password; its internal properties (such as containing a numeric value) are not
     known and no other operations (such as addition or comparison of internal names) can be performed on a
     file name.

     This example is characteristic of any case where complete control over the operations of a type is
     desired.  Such packages serve a dual purpose.  They prevent a user from making use of the internal
     structure of the type.  They also implement the notion of an 6encapsulated0 data type where the only
     operations on the type are those given in the package specification.

     6References:0 4 aggregate 4.3, allocator 4.8, assignment 5.2, catenation operator 4.5, component
     declaration 3.7, component type 3.3, composite type 3.3, default expression for a discriminant 3.7,
     deferred constant 7.4.3, derived type 3.4, designate 3.8, discriminant specification 3.7.1, equality
     4.5.2, formal parameter 6.1, full type 7.4.1, full type declaration 3.3.1, generic formal parameter 12.1
     12.3, implicit declaration 3.1, initial value 3.2.1, mode 12.1.1, object 3.2, operation 3.3, package 7,
     predefined operator 4.5, private type 7.4, private type declaration 7.4, record component 3.7, record
     type 3.7, relational operator 4.5, subcomponent 3.3, subprogram 6, task type 9.1 9.2, type 3.3 0

      section lrm-section7-5

     27.5. Example of a Table Management Package

0     The following example illustrates the use of packages in providing high level procedures with a simple
     interface to the user.

     The problem is to define a table management package for inserting and retrieving items.  The items are
     inserted into the table as they are supplied.  Each inserted item has an order number.  The items are
     retrieved according to their order number, where the item with the lowest order number is retrieved
     first.

     From the user's point of view, the package is quite simple.  There is a type called ITEM designating
     table items, a procedure INSERT for inserting items, and a procedure RETRIEVE for obtaining the item with
     the lowest order number.  There is a special item NULL_ITEM that is returned when the table is empty, and
     an exception TABLE_FULL which is raised by INSERT if the table is already full.

     A sketch of such a package is given below.  Only the specification of the package is exposed to the user.

         1package0 TABLE_MANAGER 1is

0           1type0 ITEM 1is
0              1record
0                 ORDER_NUM    : INTEGER;
                 ITEM_CODE    : INTEGER;
                 QUANTITY  : INTEGER;
                 ITEM_TYPE    : CHARACTER;
              1end0 1record0;

           NULL_ITEM : 1constant0 ITEM :=
              (ORDER_NUM | ITEM_CODE | QUANTITY => 0, ITEM_TYPE => ' ');
           1procedure0 INSERT (NEW_ITEM    : IN  ITEM);
           1procedure0 RETRIEVE  (FIRST_ITEM  : OUT    ITEM);

           TABLE_FULL : 1exception0;  6--  raised by INSERT when table full
0         1end0;

     The details of implementing such packages can be quite complex; in this case they involve a two-way
     linked table of internal items.  A local housekeeping procedure EXCHANGE is used to move an internal item
     between the busy and the free lists.  The initial table linkages are established by the initialization
     part.  The package body need not be shown to the users of the package.

         1package0 1body0 TABLE_MANAGER 1is
0           SIZE : 1constant0 := 2000;
           1subtype0 INDEX 1is0 INTEGER 1range0 0 .. SIZE;

           1type0 INTERNAL_ITEM 1is
0              1record
0                 CONTENT   : ITEM;
                 SUCC   : INDEX;
                 PRED   : INDEX;
              1end0 1record0;

           TABLE : 1array0 (INDEX) 1of0 INTERNAL_ITEM;

           FIRST_BUSY_ITEM    : INDEX := 0;
           FIRST_FREE_ITEM    : INDEX := 1;


           1function0 FREE_LIST_EMPTY   1return0 BOOLEAN 1is0 ... END;
           1function0 BUSY_LIST_EMPTY   1return0 BOOLEAN 1is0 ... END;
           1procedure0 EXCHANGE (FROM : 1in0 INDEX; TO : 1in0 INDEX) 1is0 ... 1end0;

           1procedure0 INSERT (NEW_ITEM : 1in0 ITEM) 1is
0           1begin
0              1if0 FREE_LIST_EMPTY 1then
0                 1raise0 TABLE_FULL;
              1end0 1if0;
              6--  remaining code for INSERT
0           1end0 INSERT;

           1procedure0 RETRIEVE (FIRST_ITEM : 1out0 ITEM) 1is0 ... 1end0;

         1begin
0           6--  initialization of the table linkages
0         1end0 TABLE_MANAGER;

      section lrm-section7-6

     27.6. Example of a Text Handling Package

0     This example illustrates a simple text handling package.  The users only have access to the visible part;
     the implementation is hidden from them in the private part and the package body (not shown).

     From a user's point of view, a TEXT is a variable-length string.  Each text object has a maximum length,
     which must be given when the object is declared, and a current value, which is a string of some length
     between zero and the maximum.  The maximum possible length of a text object is an implementation-defined
     constant.

     The package defines first the necessary types, then functions that return some characteristics of objects
     of the type, then the conversion functions between texts and the predefined CHARACTER and STRING types,
     and finally some of the standard operations on varying strings.  Most operations are overloaded on
     strings and characters as well as on the type TEXT, in order to minimize the number of explicit
     conversions the user has to write.

         1package0 TEXT_HANDLER 1is
0           MAXIMUM : 1constant0 := SOME_VALUE;  6--  implementation-defined
0           1subtype0 INDEX 1is0 INTEGER 1range0 0 .. MAXIMUM;

           1type0 TEXT(MAXIMUM_LENGTH : INDEX) 1is0 1limited0 1private0;


           1function0 LENGTH   (T : TEXT)  1return0 INDEX;
           1function0 VALUE    (T : TEXT)  1return0 STRING;
           1function0 EMPTY    (T : TEXT)  1return0 BOOLEAN;


           1function0 TO_TEXT  (S : STRING;   MAX : INDEX) 1return0 TEXT;   6--  maximum length MAX
0              1function0 TO_TEXT  (C : CHARACTER;   MAX : INDEX) 1return0 TEXT;

           1function0 TO_TEXT  (S : STRING)   1return0 TEXT; 6--  maximum length S'LENGTH
0           1function0 TO_TEXT  (C : CHARACTER)   1return0 TEXT;


           1function0 "&" (LEFT : TEXT;    RIGHT : TEXT)  1return0 TEXT;
           1function0 "&" (LEFT : TEXT;    RIGHT : STRING)   1return0 TEXT;
           1function0 "&" (LEFT : STRING;  RIGHT : TEXT)  1return0 TEXT;
           1function0 "&" (LEFT : TEXT;    RIGHT : CHARACTER)   1return0 TEXT;
           1function0 "&" (LEFT : CHARACTER;  RIGHT : TEXT)  1return0 TEXT;


           1function0 "="   (LEFT : TEXT;  RIGHT : TEXT)  1return0 BOOLEAN;
           1function0 "<"   (LEFT : TEXT;  RIGHT : TEXT)  1return0 BOOLEAN;
           1function0 "<="  (LEFT : TEXT;  RIGHT : TEXT)  1return0 BOOLEAN;
           1function0 ">"   (LEFT : TEXT;  RIGHT : TEXT)  1return0 BOOLEAN;
           1function0 ">="  (LEFT : TEXT;  RIGHT : TEXT)  1return0 BOOLEAN;


           1procedure0 SET (OBJECT : 1in0 1out0 TEXT;    VALUE : 1in0 TEXT);
           1procedure0 SET (OBJECT : 1in0 1out0 TEXT;    VALUE : 1in0 STRING);
           1procedure0 SET (OBJECT : 1in0 1out0 TEXT;    VALUE : 1in0 CHARACTER);


           1procedure0 APPEND (TAIL : 1in0 TEXT;  TO : 1in0 1out0 TEXT);
           1procedure0 APPEND (TAIL : 1in0 STRING;   TO : 1in0 1out0 TEXT);
           1procedure0 APPEND (TAIL : 1in0 CHARACTER;   TO : 1in0 1out0 TEXT);

           1procedure0 AMEND(OBJECT: 1in out0 TEXT; BY: 1in0 TEXT;POSITION: 1in0 INDEX);
           1procedure0 AMEND(OBJECT: 1in out0 TEXT; BY: 1in0 STRING;POSITION: 1in0 INDEX);
           1procedure0 AMEND(OBJECT: 1in0 1out0 TEXT; BY: 1in0 CHARACTER;POSITION: 1in0 INDEX);

           6--  amend replaces part of the object by the given text, string, or character
0           6--  starting at the given position in the object


0           1function0 LOCATE (FRAGMENT : TEXT;   WITHIN : TEXT)    1return0 INDEX;
           1function0 LOCATE (FRAGMENT : STRING;    WITHIN : TEXT)    1return0 INDEX;
           1function0 LOCATE (FRAGMENT : CHARACTER;    WITHIN : TEXT)    1return0 INDEX;

           6--  all return 0 if the fragment is not located

0         1private
0           1type0 TEXT(MAXIMUM_LENGTH : INDEX) 1is
0              1record
0                 POS    : INDEX := 0;
                 VALUE  : STRING(1 .. MAXIMUM_LENGTH);
              1end0 1record0;
         1end0 TEXT_HANDLER;


     6Example0 6of0 6use0 6of0 6the0 6text0 6handling0 6package:

0     A program opens an output file, whose name is supplied by the string NAME.  This string has the form
         [device :] [filename [.extension]]

     There are standard defaults for device, filename, and extension.  The user-supplied name is passed to
     EXPAND_FILE_NAME as a parameter, and the result is the expanded version, with any necessary defaults
     added.

         1function0 EXPAND_FILE_NAME (NAME : STRING) 1return0 STRING 1is
0           1use0 TEXT_HANDLER;


           DEFAULT_DEVICE  : 1constant0 STRING := "SY:";
           DEFAULT_FILE_NAME  : 1constant0 STRING := "RESULTS";
           DEFAULT_EXTENSION  : 1constant0 STRING := ".DAT";

           MAXIMUM_FILE_NAME_LENGTH : 1constant0 INDEX := SOME_APPROPRIATE_VALUE;
           FILE_NAME : TEXT(MAXIMUM_FILE_NAME_LENGTH);

         1begin

0           SET(FILE_NAME, NAME);

           1if0 EMPTY(FILE_NAME) 1then
0              SET(FILE_NAME, DEFAULT_FILE_NAME);
           1end0 1if0;

           1if0 LOCATE(':', FILE_NAME) = 0 1then
0              SET(FILE_NAME, DEFAULT_DEVICE & FILE_NAME);
           1end0 1if0;

           1if0 LOCATE('.', FILE_NAME) = 0 1then
0              APPEND(DEFAULT_EXTENSION, TO => FILE_NAME);
           1end0 1if0;

           1return0 VALUE(FILE_NAME);

         1end0 EXPAND_FILE_NAME;

      chapter lrm-chapter-8



                                                18. Visibility Rules

0     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.

     6References:0 4 declaration 3.1, declarative region 8.1, identifier 2.3, scope 8.2, visibility 8.30

      section lrm-section8-1

     28.1. Declarative Region

0     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 6associated0 with the corresponding
     declaration or statement.  A declaration is said to 6occur0 6immediately0 6within0 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 6local0 to the region.
     Declarations in outer (enclosing) regions are said to be 6global0 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.

     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 6extends0 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).

     6Notes:

0     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.

     6References:0 4 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 0

      section lrm-section8-2

     28.2. Scope of Declarations

0     For each form of declaration, the language rules define a certain portion of the program text called the
     6scope0 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 6immediate0 6scope.0 Furthermore, for any of the declarations listed below, the scope of
     the declaration extends beyond the immediate scope:

        - A declaration that occurs immediately within the visible part of a package declaration.

        - An entry declaration.

        - A component declaration.

        - A discriminant specification.

        - A parameter specification.

        - A generic parameter declaration.

     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.

     6Note:

0     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.

     6References:0 4 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 0

      section lrm-section8-3

     28.3. Visibility

0     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 6visible0 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.

        - The visibility rules determine 6at0 6most0 6one0 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 6more0 6than0 6one0 possible meaning.  In such a case the
          occurrence of the identifier is legal at this point if and only if 6exactly0 6one0 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).

     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 1is0 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 6by0 6selection0 at places
     that are defined as follows.

        - 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.

        - 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.

        - 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.

        - 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.

        - 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.

        - 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 6directly0 6visible.0 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 6hidden0 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 homograph.  Each of two declarations is said to be a 6homograph0 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.

     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.

     6Example:

0         1procedure0 P 1is
0            A, B : BOOLEAN;

            1procedure0 Q 1is
0               C   : BOOLEAN;
               B   : BOOLEAN;  6--  an inner homograph of B
0            1begin
0               ...
               B   := A;     6--  means Q.B  := P.A;
0               C   := P.B;   6--  means Q.C  := P.B;
0            1end0;
         1begin
0            ...
            A := B;  6--  means P.A := P.B;
0         1end0;

     6Note0 6on0 6the0 6visibility0 6of0 6library0 6units:

0     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).

     6Note0 6on0 6homographs:

0     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.

     6Note0 6on0 6immediate0 6scope,0 6hiding,0 6and0 6visibility:

0     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:

         K : INTEGER := K * K;           6--  illegal
0         T : T;                             6--  illegal
0         1procedure0 P(X : P);              6--  illegal
0         1procedure0 Q(X : REAL := Q);   6--  illegal, even if there is a function named Q
0         1procedure0 R(R : REAL);          6--  an inner declaration is legal (although confusing)

0     6References:0 4 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 0

      section lrm-section8-4

     28.4. Use Clauses

0     A use clause achieves direct visibility of declarations that appear in the visible parts of named
     packages.

         use_clause ::= 1use0 6package0_name {, 6package0_name};

     For each use clause, there is a certain region of text called the 6scope0 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 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.

     6Note:

0     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.

     Consequently, the following lines of text all have the same effect (assuming only one package P).

         1use0 P;
         1use0 P; 1use0 P, P;
     6Example0 6of0 6conflicting0 6names0 6in0 6two0 6packages:

0         1procedure0 R 1is
0            1package0 TRAFFIC 1is
0               1type0 COLOR 1is0 (RED, AMBER, GREEN);
               ...
            end TRAFFIC;

            1package0 WATER_COLORS 1is
0               1type0 COLOR 1is0 (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
               ...
            end WATER_COLORS;

            1use0 TRAFFIC;                6--  COLOR, RED, AMBER, and GREEN are directly visible
0            1use0 WATER_COLORS;     6--  two homographs of GREEN are directly visible
0                                           6--  but COLOR is no longer directly visible

0            1subtype0 LIGHT   1is0 TRAFFIC.COLOR;              -- 6Subtypes are used to resolve
0            1subtype0 SHADE  1is0 WATER_COLORS.COLOR;    -- 6the conflicting type name color

0            SIGNAL    : LIGHT;
            PAINT     : SHADE;
         1begin
0            SIGNAL    := GREEN;    6--  that of TRAFFIC
0            PAINT     := GREEN;    6--  that of WATER0_6COLORS
0         1end0 R;

     6Example0 6of0 6name0 6identification0 6with0 6a0 6use0 6clause:

0            1package0 D 1is
0               T, U, V : BOOLEAN;
            1end0 D;

            1procedure0 P 1is
0               1package0 E 1is
0                  B, W, V : INTEGER;
               1end0 E;

               1procedure0 Q 1is
0                  T, X : REAL;
                  1use0 D, E;
               1begin
0                  6--  the name T   means Q.T, not D.T
0                  6--  the name U   means D.U
0                  6--  the name B   means E.B
0                  6--  the name W   means E.W
0                  6--  the name X   means Q.X
0                  6--  the name V   is illegal : either D.V or E.V must be used
0                  ...
               1end0 Q;
            1begin
0               ...
            end P;


     6References:0 4 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 0

      section lrm-section8-5

     28.5. Renaming Declarations

0     A renaming declaration declares another name for an entity.

         renaming_declaration ::=
             identifier : type_mark  1renames0 6object0_name;
            |   identifier : 1exception  0 1renames0 6exception0_name;
            |   1package0 identifier  1renames0 6package0_name;
            |   subprogram_specification   1renames0 6subprogram0_6or0_6entry0_name;

     The elaboration of a renaming declaration evaluates the name that follows the reserved word 1renames
0     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 1in0 1out0.)  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 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.

     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.

     6Examples:

0         1declare
0            L   : PERSON 1renames0 LEFTMOST_PERSON;  -- see 3.8.1
         1begin
0            L.AGE := L.AGE + 1;
         1end0;

         FULL : 1exception0 1renames0 TABLE_MANAGER.TABLE_FULL;   -- see 7.5

         1package0 TM 1renames0 TABLE_MANAGER;

         1function0 REAL_PLUS  (LEFT, RIGHT : REAL      ) 1return0 REAL  1renames0 "+";
         1function0 INT_PLUS    (LEFT, RIGHT : INTEGER  ) 1return0 INTEGER  1renames0 "+";

         1function0 ROUGE    1return0 COLOR 1renames0 RED;  --  see 3.5.1
         1function0 ROT       1return0 COLOR 1renames0 RED;
         1function0 ROSSO    1return0 COLOR 1renames0 ROUGE;

         1function0 NEXT(X : COLOR) 1return0 COLOR 1renames0 COLOR'SUCC; -- see 3.5.5

     6Example0 6of0 6a0 6renaming0 6declaration0 6with0 6new0 6parameter0 6names:

0         1function0 "*" (X,Y : VECTOR) 1return0 REAL 1renames0 DOT_PRODUCT; -- see 6.1

     6Example0 6of0 6a0 6renaming0 6declaration0 6with0 6a0 6new0 6default0 6expression:

0         1function0 MINIMUM(L : LINK := HEAD) 1return0 CELL 1renames0 MIN_CELL; -- see 6.1

     6Notes:

0     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
     6universal_fixed0 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.

     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

         1subtype0 MODE 1is0 TEXT_IO.FILE_MODE;


     6References:0 4 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 0

      section lrm-section8-6

     28.6. The Package Standard

0     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.

     6Notes:

0     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.

     6References:0 4 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.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 0

      section lrm-section8-7

     28.7. The Context of Overload Resolution

0     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 1null,0 aggregates, and string literals.

     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 6complete
0     6context0 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.

        - Any rule that requires a name or expression to have a certain type, or to have the same type as
          another name or expression.

        - 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.

        - Any rule that requires a prefix to be appropriate for a certain type.

        - 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.

        - 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).

        - 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.

     Similarly, the simple names given in context clauses (see 10.1.1) and in address clauses (see 13.5)
     follow different rules.

     :text 6Notes:

0     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.

     6References:0 4 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 

0     6Rules0 6of0 6the0 6form0 (6a):0 4 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 

0     6Rules0 6of0 6the0 6form0 (6b):0 4 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 

0     6Rules0 6of0 6the0 6form0 (6c):0 4 indexed component 4.1.1, selected component 4.1.3, slice
     4.1.2 

0     6Rules0 6of0 6the0 6form0 (6d):0 4 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 0

      chapter lrm-chapter-9



                                                     19. Tasks

0     The execution of a program that does not contain a task is defined in terms of a sequential execution of
     its actions, according to the rules described in other chapters of this manual.  These actions can be
     considered to be executed by a single 6logical0 6processor.

0     Tasks are entities whose executions proceed 6in0 6parallel0 in the following sense.  Each task can be
     considered to be executed by a logical processor of its own.  Different tasks (different logical
     processors) proceed independently, except at points where they synchronize.

     Some tasks have 6entries.0 An entry of a task can be 6called0 by other tasks.  A task 6accepts0 a
     call of one of its entries by executing an accept statement for the entry.  Synchronization is achieved
     by 6rendezvous0 between a task issuing an entry call and a task accepting the call.  Some entries have
     parameters; entry calls and accept statements for such entries are the principal means of communicating
     values between tasks.

     The properties of each task are defined by a corresponding 6task0 6unit0 which consists of a 6task
0     6specification0 and a 6task0 6body.0 Task units are one of the four forms of program unit of which
     programs can be composed.  The other forms are subprograms, packages and generic units.  The properties
     of task units, tasks, and entries, and the statements that affect the interaction between tasks (that is,
     entry call statements, accept statements, delay statements, select statements, and abort statements) are
     described in this chapter.

     6Note:

0     Parallel tasks (parallel logical processors) may be implemented on multicomputers, multiprocessors, or
     with interleaved execution on a single 6physical0 6processor.0 On the other hand, whenever an
     implementation can detect that the same effect can be guaranteed if parts of the actions of a given task
     are executed by different physical processors acting in parallel, it may choose to execute them in this
     way; in such a case, several physical processors implement a single logical processor.

     6References:0 4 abort statement 9.10, accept statement 9.5, delay statement 9.6, entry 9.5, entry call
     statement 9.5, generic unit 12, package 7, parameter in an entry call 9.5, program unit 6, rendezvous
     9.5, select statement 9.7, subprogram 6, task body 9.1, task specification 9.1 0

      section lrm-section9-1

     29.1. Task Specifications and Task Bodies

0     A task unit consists of a task specification and a task body.  A task specification that starts with the
     reserved words 1task0 1type0 declares a task type.  The value of an object of a task type designates
     a task having the entries, if any, that are declared in the task specification; these entries are also
     called entries of this object.  The execution of the task is defined by the corresponding task body.

     A task specification without the reserved word 1type0 defines a 6single0 6task.0 A task declaration
     with this form of specification is equivalent to the declaration of an anonymous task type immediately
     followed by the declaration of an object of the task type, and the task unit identifier names the object.
     In the remainder of this chapter, explanations are given in terms of task type declarations; the
     corresponding explanations for single task declarations follow from the stated equivalence.

         task_declaration ::= task_specification;

         task_specification ::=
            1task0 [1type0] identifier [1is
0               {entry_declaration}
               {representation_clause}
            1end0 [6task0_simple_name]]

         task_body ::=
            1task0 1body0 6task0_simple_name 1is
0               [  declarative_part]
            1begin
0                  sequence_of_statements
            [  1exception
0                  exception_handler
               {  exception_handler}]
            1end0 [6task0_simple_name];

     The simple name at the start of a task body must repeat the task unit identifier.  Similarly if a simple
     name appears at the end of the task specification or body, it must repeat the task unit identifier.
     Within a task body, the name of the corresponding task unit can also be used to refer to the task object
     that designates the task currently executing the body; furthermore, the use of this name as a type mark
     is not allowed within the task unit itself.

     For the elaboration of a task specification, entry declarations and representation clauses, if any, are
     elaborated in the order given.  Such representation clauses only apply to the entries declared in the
     task specification (see 13.5).

     The elaboration of a task body has no other effect than to establish that the body can from then on be
     used for the execution of tasks designated by objects of the corresponding task type.

     The execution of a task body is invoked by the activation of a task object of the corresponding type (see
     9.3).  The optional exception handlers at the end of a task body handle exceptions raised during the
     execution of the sequence of statements of the task body (see 11.4).

     6Examples0 6of0 6specifications0 6of0 6task0 6types:

0         1task0 1type0 RESOURCE 1is
0            1entry0 SEIZE;
            1entry0 RELEASE;
         1end0 RESOURCE;

         1task0 1type0 KEYBOARD_DRIVER 1is
0            1entry0 READ (C : OUT  CHARACTER);
            1entry0 WRITE   (C : IN   CHARACTER);
         1end0 KEYBOARD_DRIVER;


     6Examples0 6of0 6specifications0 6of0 6single0 6tasks:

0         1task0 PRODUCER_CONSUMER 1is
0            1entry0 READ (V  : OUT    ITEM);
            1entry0 WRITE   (E  : IN  ITEM);
         1end0;

         1task0 CONTROLLER 1is
0            1entry0 REQUEST(LEVEL)(D : ITEM);   6--  a family of entries
0         1end0 CONTROLLER;

         1task0 USER;  6--  has no entries

0     6Example0 6of0 6task0 6specification0 6and0 6corresponding0 6body:

0         1task0 PROTECTED_ARRAY 1is
0            6--  INDEX and ITEM are global types
0            1entry0 READ (N : 1in0 INDEX; V  : OUT    ITEM);
            1entry0 WRITE   (N : 1in0 INDEX; E  : IN  ITEM);
         1end0;

         1task0 1body0 PROTECTED_ARRAY 1is
0            TABLE : 1array0(INDEX) 1of0 ITEM := (INDEX => NULL_ITEM);
         1begin
0            1loop
0               1select
0                  1accept0 READ   (N : 1in0 INDEX; V : OUT  ITEM) 1do
0                     V := TABLE(N);
                  1end0 READ;
               1or
0                  1accept0 WRITE  (N : 1in0 INDEX; E : IN   ITEM) 1do
0                     TABLE(N) := E;
                  1end0 WRITE;
               1end0 1select0;
            1end0 1loop0;
         1end0 PROTECTED_ARRAY;

     6Note:

0     A task specification specifies the interface of tasks of the task type with other tasks of the same or of
     different types, and also with the main program.

     6References:0 4 declaration 3.1, declarative part 3.9, elaboration 3.9, entry 9.5, entry declaration
     9.5, exception handler 11.2, identifier 2.3, main program 10.1, object 3.2, object declaration 3.2.1,
     representation clause 13.1, reserved word 2.9, sequence of statements 5.1, simple name 4.1, type 3.3,
     type declaration 3.3.1 0

      section lrm-section9-2

     29.2. Task Types and Task Objects

0     A task type is a limited type (see 7.4.4).  Hence neither assignment nor the predefined comparison for
     equality and inequality are defined for objects of task types; moreover, the mode 1out0 is not allowed
     for a formal parameter whose type is a task type.

     A task object is an object whose type is a task type.  The value of a task object designates a task that
     has the entries of the corresponding task type, and whose execution is specified by the corresponding
     task body.  If a task object is the object, or a subcomponent of the object, declared by an object
     declaration, then the value of the task object is defined by the elaboration of the object declaration.
     If a task object is the object, or a subcomponent of the object, created by the evaluation of an
     allocator, then the value of the task object is defined by the evaluation of the allocator.  For all
     parameter modes, if an actual parameter designates a task, the associated formal parameter designates the
     same task; the same holds for a subcomponent of an actual parameter and the corresponding subcomponent of
     the associated formal parameter; finally, the same holds for generic parameters.

     6Examples:

0         CONTROL   : RESOURCE;
         TELETYPE  : KEYBOARD_DRIVER;
         POOL   : 1array0(1 .. 10) 1of0 KEYBOARD_DRIVER;
         6--  see also examples of declarations of single tasks in 9.1

0     6Example0 6of0 6access0 6type0 6designating0 6task0 6objects:

0         1type0 KEYBOARD 1is0 1access0 KEYBOARD_DRIVER;

         TERMINAL : KEYBOARD := 1new0 KEYBOARD_DRIVER;

     6Notes:

0     Since a task type is a limited type, it can appear as the definition of a limited private type in a
     private part, and as a generic actual parameter associated with a formal parameter whose type is a
     limited type.  On the other hand, the type of a generic formal parameter of mode 1in0 must not be a
     limited type and hence cannot be a task type.

     Task objects behave as constants (a task object always designates the same task) since their values are
     implicitly defined either at declaration or allocation, or by a parameter association, and since no
     assignment is available.  However the reserved word 1constant0 is not allowed in the declaration of a
     task object since this would require an explicit initialization.  A task object that is a formal
     parameter of mode 1in0 is a constant (as is any formal parameter of this mode).

     If an application needs to store and exchange task identities, it can do so by defining an access type
     designating the corresponding task objects and by using access values for identification purposes (see
     above example).  Assignment is available for such an access type as for any access type.

     Subtype declarations are allowed for task types as for other types, but there are no constraints
     applicable to task types.

     6References:0 4 access type 3.8, actual parameter 6.4.1, allocator 4.8, assignment 5.2, component
     declaration 3.7, composite type 3.3, constant 3.2.1, constant declaration 3.2.1, constraint 3.3,
     designate 3.8 9.1, elaboration 3.9, entry 9.5, equality operator 4.5.2, formal parameter 6.2, formal
     parameter mode 6.2, generic actual parameter 12.3, generic association 12.3, generic formal parameter
     12.1, generic formal parameter mode 12.1.1, generic unit 12, inequality operator 4.5.2, initialization
     3.2.1, limited type 7.4.4, object 3.2, object declaration 3.2.1, parameter association 6.4, private part
     7.2, private type 7.4, reserved word 2.9, subcomponent 3.3, subprogram 6, subtype declaration 3.3.2, task
     body 9.1, type 3.3 0

      section lrm-section9-3

     29.3. Task Execution - Task Activation

0     A task body defines the execution of any task that is designated by a task object of the corresponding
     task type.  The initial part of this execution is called the 6activation0 of the task object, and also
     that of the designated task; it consists of the elaboration of the declarative part, if any, of the task
     body.  The execution of different tasks, in particular their activation, proceeds in parallel.

     If an object declaration that declares a task object occurs immediately within a declarative part, then
     the activation of the task object starts after the elaboration of the declarative part (that is, after
     passing the reserved word 1begin0 following the declarative part); similarly if such a declaration
     occurs immediately within a package specification, the activation starts after the elaboration of the
     declarative part of the package body.  The same holds for the activation of a task object that is a
     subcomponent of an object declared immediately within a declarative part or package specification.  The
     first statement following the declarative part is executed only after conclusion of the activation of
     these task objects.

     Should an exception be raised by the activation of one of these tasks, that task becomes a completed task
     (see 9.4); other tasks are not directly affected.  Should one of these tasks thus become completed during
     its activation, the exception TASKING_ERROR is raised upon conclusion of the activation of all of these
     tasks (whether successfully or not); the exception is raised at a place that is immediately before the
     first statement following the declarative part (immediately after the reserved word 1begin0).  Should
     several of these tasks thus become completed during their activation, the exception TASKING_ERROR is
     raised only once.

     Should an exception be raised by the elaboration of a declarative part or package specification, then any
     task that is created (directly or indirectly) by this elaboration and that is not yet activated becomes
     terminated and is therefore never activated (see section 9.4 for the definition of a terminated task).

     For the above rules, in any package body without statements, a null statement is assumed.  For any
     package without a package body, an implicit package body containing a single null statement is assumed.
     If a package without a package body is declared immediately within some program unit or block statement,
     the implicit package body occurs at the end of the declarative part of the program unit or block
     statement; if there are several such packages, the order of the implicit package bodies is undefined.

     A task object that is the object, or a subcomponent of the object, created by the evaluation of an
     allocator is activated by this evaluation.  The activation starts after any initialization for the object
     created by the allocator; if several subcomponents are task objects, they are activated in parallel.  The
     access value designating such an object is returned by the allocator only after the conclusion of these
     activations.

     Should an exception be raised by the activation of one of these tasks, that task becomes a completed
     task; other tasks are not directly affected.  Should one of these tasks thus become completed during its
     activation, the exception TASKING_ERROR is raised upon conclusion of the activation of all of these tasks
     (whether successfully or not); the exception is raised at the place where the allocator is evaluated.
     Should several of these tasks thus become completed during their activation, the exception TASKING_ERROR
     is raised only once.

     Should an exception be raised by the initialization of the object created by an allocator (hence before
     the start of any activation), any task designated by a subcomponent of this object becomes terminated and
     is therefore never activated.

     6Example:

0         1procedure0 P 1is
0            A, B   : RESOURCE;     6--  elaborate the task objects A, B
0            C      : RESOURCE;     6--  elaborate the task object C
0         1begin
0            6--  the tasks A, B, C are activated in parallel before the first statement
0            ...
         1end0;

     6Notes:

0     An entry of a task can be called before the task has been activated.  If several tasks are activated in
     parallel, the execution of any of these tasks need not await the end of the activation of the other
     tasks.  A task may become completed during its activation either because of an exception or because it is
     aborted (see 9.10).

     6References:0 4 allocator 4.8, completed task 9.4, declarative part 3.9, elaboration 3.9, entry 9.5,
     exception 11, handling an exception 11.4, package body 7.1, parallel execution 9, statement 5,
     subcomponent 3.3, task body 9.1, task object 9.2, task termination 9.4, task type 9.1, tasking_error
     exception 11.1 0

      section lrm-section9-4

     29.4. Task Dependence - Termination of Tasks

0     Each task 6depends0 on at least one master.  A 6master0 is a construct that is either a task, a
     currently executing block statement or subprogram, or a library package (a package declared within
     another program unit is not a master).  The dependence on a master is a direct dependence in the
     following two cases:

        - The task designated by a task object that is the object, or a subcomponent of the object,
          created by the evaluation of an allocator depends on the master that elaborates the
          corresponding access type definition.

        - The task designated by any other task object depends on the master whose execution creates the
          task object.

     Furthermore, if a task depends on a given master that is a block statement executed by another master,
     then the task depends also on this other master, in an indirect manner; the same holds if the given
     master is a subprogram called by another master, and if the given master is a task that depends (directly
     or indirectly) on another master.  Dependences exist for objects of a private type whose full declaration
     is in terms of a task type.

     A task is said to have 6completed0 its execution when it has finished the execution of the sequence of
     statements that appears after the reserved word 1begin0 in the corresponding body.  Similarly a block
     or a subprogram is said to have completed its execution when it has finished the execution of the
     corresponding sequence of statements.  For a block statement, the execution is also said to be completed
     when it reaches an exit, return, or goto statement transferring control out of the block.  For a
     procedure, the execution is also said to be completed when a corresponding return statement is reached.
     For a function, the execution is also said to be completed after the evaluation of the result expression
     of a return statement.  Finally the execution of a task, block statement, or subprogram is completed if
     an exception is raised by the execution of its sequence of statements and there is no corresponding
     handler, or, if there is one, when it has finished the execution of the corresponding handler.

     If a task has no dependent task, its 6termination0 takes place when it has completed its execution.
     After its termination, a task is said to be 6terminated.0 If a task has dependent tasks, its
     termination takes place when the execution of the task is completed and all dependent tasks are
     terminated.  A block statement or subprogram body whose execution is completed is not left until all of
     its dependent tasks are terminated.

     Termination of a task otherwise takes place if and only if its execution has reached an open terminate
     alternative in a select statement (see 9.7.1), and the following conditions are satisfied:

        - The task depends on some master whose execution is completed (hence not a library package).

        - Each task that depends on the master considered is either already terminated or similarly
          waiting on an open terminate alternative of a select statement.

     When both conditions are satisfied, the task considered becomes terminated, together with all tasks that
     depend on the master considered.

     6Example:

0         1declare
0            1type0 GLOBAL 1is0 1access0 RESOURCE;          6--  see 9.1
0            A, B   : RESOURCE;
            G   : GLOBAL;
         1begin
0            6--  activation of A and B
0            1declare
0               1type0 LOCAL 1is0 1access0 RESOURCE;
               X   : GLOBAL    := 1new0 RESOURCE;     6--  activation of X._all
0               L   : LOCAL  := 1new0 RESOURCE;         6--  activation of L._all
0               C   : RESOURCE;
            1begin
0               6--  activation of C
0               G := X;  6--  both G and X designate the same task object
0               ...
            1end0;   6--  await termination of C and L._all (but not X._all)
0            ...
         1end0;  6--  await termination of A, B, and G.1all

0     6Notes:

0     The rules given for termination imply that all tasks that depend (directly or indirectly) on a given
     master and that are not already terminated, can be terminated (collectively) if and only if each of them
     is waiting on an open terminate alternative of a select statement and the execution of the given master
     is completed.

     The usual rules apply to the main program.  Consequently, termination of the main program awaits
     termination of any dependent task even if the corresponding task type is declared in a library package.
     On the other hand, termination of the main program does not await termination of tasks that depend on
     library packages; the language does not define whether such tasks are required to terminate.

     For an access type derived from another access type, the corresponding access type definition is that of
     the parent type; the dependence is on the master that elaborates the ultimate parent access type
     definition.

     A renaming declaration defines a new name for an existing entity and hence creates no further dependence.

     6References:0 4 access type 3.8, allocator 4.8, block statement 5.6, declaration 3.1, designate 3.8
     9.1, exception 11, exception handler 11.2, exit statement 5.7, function 6.5, goto statement 5.9, library
     unit 10.1, main program 10.1, object 3.2, open alternative 9.7.1, package 7, program unit 6, renaming
     declaration 8.5, return statement 5.8, selective wait 9.7.1, sequence of statements 5.1, statement 5,
     subcomponent 3.3, subprogram body 6.3, subprogram call 6.4, task body 9.1, task object 9.2, terminate
     alternative 9.7.1 0

      section lrm-section9-5

     29.5. Entries, Entry Calls, and Accept Statements

0     Entry calls and accept statements are the primary means of synchronization of tasks, and of communicating
     values between tasks.  An entry declaration is similar to a subprogram declaration and is only allowed in
     a task specification.  The actions to be performed when an entry is called are specified by corresponding
     accept statements.

         entry_declaration ::=
            1entry0 identifier [(discrete_range)] [formal_part];

         entry_call_statement ::= 6entry0_name [actual_parameter_part];

         accept_statement ::=
            1accept0 6entry0_simple_name [(entry_index)] [formal_part] [1do
0               sequence_of_statements
            1end0 [6entry0_simple_name]];

         entry_index ::= expression

     An entry declaration that includes a discrete range (see 3.6.1) declares a 6family0 of distinct entries
     having the same formal part (if any); that is, one such entry for each value of the discrete range.  The
     term 6single0 6entry0 is used in the definition of any rule that applies to any entry other than one
     of a family.  The task designated by an object of a task type has (or owns) the entries declared in the
     specification of the task type.

     Within the body of a task, each of its single entries or entry families can be named by the corresponding
     simple name.  The name of an entry of a family takes the form of an indexed component, the family simple
     name being followed by the index in parentheses; the type of this index must be the same as that of the
     discrete range in the corresponding entry family declaration.  Outside the body of a task an entry name
     has the form of a selected component, whose prefix denotes the task object, and whose selector is the
     simple name of one of its single entries or entry families.

     A single entry overloads a subprogram, an enumeration literal, or another single entry if they have the
     same identifier.  Overloading is not defined for entry families.  A single entry or an entry of an entry
     family can be renamed as a procedure as explained in section 8.5.

     The parameter modes defined for parameters of the formal part of an entry declaration are the same as for
     a subprogram declaration and have the same meaning (see 6.2).  The syntax of an entry call statement is
     similar to that of a procedure call statement, and the rules for parameter associations are the same as
     for subprogram calls (see 6.4.1 and 6.4.2).

     An accept statement specifies the actions to be performed at a call of a named entry (it can be an entry
     of a family).  The formal part of an accept statement must conform to the formal part given in the
     declaration of the single entry or entry family named by the accept statement (see section 6.3.1 for the
     conformance rules).  If a simple name appears at the end of an accept statement, it must repeat that
     given at the start.

     An accept statement for an entry of a given task is only allowed within the corresponding task body;
     excluding within the body of any program unit that is, itself, inner to the task body; and excluding
     within another accept statement for either the same single entry or an entry of the same family.  (One
     consequence of this rule is that a task can execute accept statements only for its own entries.)  A task
     body can contain more than one accept statement for the same entry.

     For the elaboration of an entry declaration, the discrete range, if any, is evaluated and the formal
     part, if any, is then elaborated as for a subprogram declaration.

     Execution of an accept statement starts with the evaluation of the entry index (in the case of an entry
     of a family).  Execution of an entry call statement starts with the evaluation of the entry name; this is
     followed by any evaluations required for actual parameters in the same manner as for a subprogram call
     (see 6.4).  Further execution of an accept statement and of a corresponding entry call statement are
     synchronized.

     If a given entry is called by only one task, there are two possibilities:

        - If the calling task issues an entry call statement before a corresponding accept statement is
          reached by the task owning the entry, the execution of the calling task is 6suspended.

0        - If a task reaches an accept statement prior to any call of that entry, the execution of the
          task is suspended until such a call is received.

     When an entry has been called and a corresponding accept statement has been reached, the sequence of
     statements, if any, of the accept statement is executed by the called task (while the calling task
     remains suspended).  This interaction is called a 6rendezvous.0 Thereafter, the calling task and the
     task owning the entry continue their execution in parallel.

     If several tasks call the same entry before a corresponding accept statement is reached, the calls are
     queued; there is one queue associated with each entry.  Each execution of an accept statement removes one
     call from the queue.  The calls are processed in the order of arrival.

     An attempt to call an entry of a task that has completed its execution raises the exception TASKING_ERROR
     at the point of the call, in the calling task; similarly, this exception is raised at the point of the
     call if the called task completes its execution before accepting the call (see also 9.10 for the case
     when the called task becomes abnormal).  The exception CONSTRAINT_ERROR is raised if the index of an
     entry of a family is not within the specified discrete range.

     6Examples0 6of0 6entry0 6declarations:

0         1entry0 READ(V : 1out0 ITEM);
         1entry0 SEIZE;
         1entry0 REQUEST(LEVEL)(D : ITEM);  6--  a family of entries

0     6Examples0 6of0 6entry0 6calls:

0         CONTROL.RELEASE;                                 6--  see 9.2 and 9.1
0         PRODUCER_CONSUMER.WRITE(E);                 6--  see 9.1
0         POOL(5).READ(NEXT_CHAR);                       6--  see 9.2 and 9.1
0         CONTROLLER.REQUEST(LOW)(SOME_ITEM);    6--  see 9.1


0     6Examples0 6of0 6accept0 6statements:

0         1accept0 SEIZE;

         1accept0 READ(V : 1out0 ITEM) 1do
0            V := LOCAL_ITEM;
         1end0 READ;

         1accept0 REQUEST(LOW)(D : ITEM) 1do
0            ...
         1end0 REQUEST;

     6Notes:

0     The formal part given in an accept statement is not elaborated; it is only used to identify the
     corresponding entry.

     An accept statement can call subprograms that issue entry calls.  An accept statement need not have a
     sequence of statements even if the corresponding entry has parameters.  Equally, it can have a sequence
     of statements even if the corresponding entry has no parameters.  The sequence of statements of an accept
     statement can include return statements.  A task can call its own entries but it will, of course,
     deadlock.  The language permits conditional and timed entry calls (see 9.7.2 and 9.7.3).  The language
     rules ensure that a task can only be in one entry queue at a given time.

     If the bounds of the discrete range of an entry family are integer literals, the index (in an entry name
     or accept statement) must be of the predefined type INTEGER (see 3.6.1).

     6References:0 4 abnormal task 9.10, actual parameter part 6.4, completed task 9.4, conditional entry
     call 9.7.2, conformance rules 6.3.1, constraint_error exception 11.1, designate 9.1, discrete range
     3.6.1, elaboration 3.1 3.9, enumeration literal 3.5.1, evaluation 4.5, expression 4.4, formal part 6.1,
     identifier 2.3, indexed component 4.1.1, integer type 3.5.4, name 4.1, object 3.2, overloading 6.6 8.7,
     parallel execution 9, prefix 4.1, procedure 6, procedure call 6.4, renaming declaration 8.5, return
     statement 5.8, scope 8.2, selected component 4.1.3, selector 4.1.3, sequence of statements 5.1, simple
     expression 4.4, simple name 4.1, subprogram 6, subprogram body 6.3, subprogram declaration 6.1, task 9,
     task body 9.1, task specification 9.1, tasking_error exception 11.1, timed entry call 9.7.30

      section lrm-section9-6

     29.6. Delay Statements, Duration, and Time

0     The execution of a delay statement evaluates the simple expression, and suspends further execution of the
     task that executes the delay statement, for at least the duration specified by the resulting value.

         delay_statement ::= 1delay0 simple_expression;

     The simple expression must be of the predefined fixed point type DURATION; its value is expressed in
     seconds; a delay statement with a negative value is equivalent to a delay statement with a zero value.

     Any implementation of the type DURATION must allow representation of durations (both positive and
     negative) up to at least 86400 seconds (one day); the smallest representable duration, DURATION'SMALL
     must not be greater than twenty milliseconds (whenever possible, a value not greater than fifty
     microseconds should be chosen).  Note that DURATION'SMALL need not correspond to the basic clock cycle,
     the named number SYSTEM.TICK (see 13.7).

     The definition of the type TIME is provided in the predefined library package CALENDAR.  The function
     CLOCK returns the current value of TIME at the time it is called.  The functions YEAR, MONTH, DAY and
     SECONDS return the corresponding values for a given value of the type TIME; the procedure SPLIT returns
     all four corresponding values.  Conversely, the function TIME_OF combines a year number, a month number,
     a day number, and a duration, into a value of type TIME.  The operators "+" and "-" for addition and
     subtraction of times and durations, and the relational operators for times, have the conventional
     meaning.

     The exception TIME_ERROR is raised by the function TIME_OF if the actual parameters do not form a proper
     date.  This exception is also raised by the operators "+" and "-" if, for the given operands, these
     operators cannot return a date whose year number is in the range of the corresponding subtype, or if the
     operator "-" cannot return a result that is in the range of the type DURATION.

         1package0 CALENDAR 1is
0            1type0 TIME 1is0 1private0;

            1subtype0 YEAR_NUMBER       1is0 INTEGER    1range0 1901 .. 2099;
            1subtype0 MONTH_NUMBER    1is0 INTEGER    1range0 1 .. 12;
            1subtype0 DAY_NUMBER        1is0 INTEGER    1range0 1 .. 31;
            1subtype0 DAY_DURATION     1is0 DURATION  1range0 0.0 .. 86_400.0;

            1function0 CLOCK 1return0 TIME;

            1function0 YEAR       (DATE  : TIME) 1return0 YEAR_NUMBER;
            1function0 MONTH    (DATE  : TIME) 1return0 MONTH_NUMBER;
            1function0 DAY        (DATE  : TIME) 1return0 DAY_NUMBER;
            1function0 SECONDS (DATE  : TIME) 1return0 DAY_DURATION;

            1procedure0 SPLIT   ( DATE       : 1in0      TIME;
               			    YEAR       : 1out0    YEAR_NUMBER;
	       	                    MONTH    : 1out0    MONTH_NUMBER;
                                    DAY        : 1out0    DAY_NUMBER;
                                    SECONDS : 1out0    DAY_DURATION);

            1function0 TIME_OF ( YEAR       : YEAR_NUMBER;
                                    MONTH    : MONTH_NUMBER;
                                    DAY        : DAY_NUMBER;
                                    SECONDS : DAY_DURATION := 0.0)    1return0 TIME;


            1function0 "+"   (LEFT : TIME;           RIGHT : DURATION)    1return0 TIME;
            1function0 "+"   (LEFT : DURATION;    RIGHT : TIME)           1return0 TIME;
            1function0 "-"   (LEFT : TIME;           RIGHT : DURATION)    1return0 TIME;
            1function0 "-"   (LEFT : TIME;            RIGHT : TIME)          1return0 DURATION;

            1FUNCTION0 "<"   (LEFT, RIGHT : TIME) 1return0 BOOLEAN;
            1FUNCTION0 "<="  (LEFT, RIGHT : TIME) 1return0 BOOLEAN;
            1FUNCTION0 ">"   (LEFT, RIGHT : TIME) 1return0 BOOLEAN;
            1FUNCTION0 ">="  (LEFT, RIGHT : TIME) 1return0 BOOLEAN;

            TIME_ERROR : 1exception0;  6--  can be raised by TIME0_6OF, "+", and "-"

0         1private
0            -- IMPLEMENTATION-DEPENDENT
         1end0;


     6Examples:
0         1delay0 3.0;  6--  delay 3.0 seconds

0         1declare
0            1use0 CALENDAR;
            6--  INTERVAL is a global constant of type DURATION
0            NEXT_TIME    : TIME := CLOCK + INTERVAL;
         1begin
0            1loop
0               1delay0 NEXT_TIME - CLOCK;
               6--  some actions
0               NEXT_TIME := NEXT_TIME + INTERVAL;
            1end0 1loop0;
         1end0;

     6Notes:

0     The second example causes the loop to be repeated every INTERVAL seconds on average.  This interval
     between two successive iterations is only approximate.  However, there will be no cumulative drift as
     long as the duration of each iteration is (sufficiently) less than INTERVAL.

     6References:0 4 adding operator 4.5, duration C, fixed point type 3.5.9, function call 6.4, library
     unit 10.1, operator 4.5, package 7, private type 7.4, relational operator 4.5, simple expression 4.4,
     statement 5, task 9, type 3.3 0

      section lrm-section9-7

     29.7. Select Statements

0     There are three forms of select statements.  One form provides a selective wait for one or more
     alternatives.  The other two provide conditional and timed entry calls.

         select_statement ::= selective_wait
            | conditional_entry_call | timed_entry_call

     6References:0 4 selective wait 9.7.1, conditional entry call 9.7.2, timed entry call 9.7.3 0

      subsection lrm-section9-7-1



     79.7.1. Selective Waits

0     This form of the select statement allows a combination of waiting for, and selecting from, one or more
     alternatives.  The selection can depend on conditions associated with each alternative of the selective
     wait.

         selective_wait ::=
            1select
0               select_alternative
            {  1or
0               select_alternative}
            [  1else
0               sequence_of_statements]
            1end0 1select;

0         select_alternative ::=
            [  1when0 condition =>]
               selective_wait_alternative

         selective_wait_alternative ::= accept_alternative
            | delay_alternative | terminate_alternative

         accept_alternative    ::= accept_statement    [sequence_of_statements]

         delay_alternative  ::= delay_statement  [sequence_of_statements]
         terminate_alternative ::= 1terminate;

0     A selective wait must contain at least one accept alternative.  In addition a selective wait can contain
     either a terminate alternative (only one), or one or more delay alternatives, or an else part; these
     three possibilities are mutually exclusive.

     A select alternative is said to be 6open0 if it does not start with 1when0 and a condition, or if the
     condition is TRUE.  It is said to be 6closed0 otherwise.

     For the execution of a selective wait, any conditions specified after 1when0 are evaluated in some
     order that is not defined by the language; open alternatives are thus determined.  For an open delay
     alternative, the delay expression is also evaluated.  Similarly, for an open accept alternative for an
     entry of a family, the entry index is also evaluated.  Selection and execution of one open alternative,
     or of the else part, then completes the execution of the selective wait; the rules for this selection are
     described below.

     Open accept alternatives are first considered.  Selection of one such alternative takes place immediately
     if a corresponding rendezvous is possible, that is, if there is a corresponding entry call issued by
     another task and waiting to be accepted.  If several alternatives can thus be selected, one of them is
     selected arbitrarily (that is, the language does not define which one).  When such an alternative is
     selected, the corresponding accept statement and possible subsequent statements are executed.  If no
     rendezvous is immediately possible and there is no else part, the task waits until an open selective wait
     alternative can be selected.

     Selection of the other forms of alternative or of an else part is performed as follows:

        - An open delay alternative will be selected if no accept alternative can be selected before the
          specified delay has elapsed (immediately, for a negative or zero delay in the absence of queued
          entry calls); any subsequent statements of the alternative are then executed.  If several delay
          alternatives can thus be selected (that is, if they have the same delay), one of them is
          selected arbitrarily.

        - The else part is selected and its statements are executed if no accept alternative can be
          immediately selected, in particular, if all alternatives are closed.

        - An open terminate alternative is selected if the conditions stated in section 9.4 are
          satisfied.  It is a consequence of other rules that a terminate alternative cannot be selected
          while there is a queued entry call for any entry of the task.

     The exception PROGRAM_ERROR is raised if all alternatives are closed and there is no else part.

     6Examples0 6of0 6a0 6select0 6statement:

0         1select
0            1accept0 DRIVER_AWAKE_SIGNAL;
         1or
0            1delay0 30.0*SECONDS;
            STOP_THE_TRAIN;
         1end0 1select0;

     6Example0 6of0 6a0 6task0 6body0 6with0 6a0 6select0 6statement:

0         1task0 1body0 RESOURCE 1is
0            BUSY : BOOLEAN := FALSE;
         1begin
0            1loop
0               1select
0                  1when0 1not0 BUSY =>
                     1accept0 SEIZE 1do
0                        BUSY := TRUE;
                     1end0;
               1or
0                  1accept0 RELEASE 1do
0                     BUSY := FALSE;
                  1end0;
               1or
0                  1terminate0;
               1end0 1select0;
            1end0 1loop0;
         1end0 RESOURCE;

     6Notes:

0     A selective wait is allowed to have several open delay alternatives.  A selective wait is allowed to have
     several open accept alternatives for the same entry.

     6References:0 4 accept statement 9.5, condition 5.3, declaration 3.1, delay expression 9.6, delay
     statement 9.6, duration 9.6, entry 9.5, entry call 9.5, entry index 9.5, program_error exception 11.1,
     queued entry call 9.5, rendezvous 9.5, select statement 9.7, sequence of statements 5.1, task 9 0

      subsection lrm-section9-7-2



     79.7.2. Conditional Entry Calls

0     A conditional entry call issues an entry call that is then canceled if a rendezvous is not immediately
     possible.

         conditional_entry_call ::=
            1select
0                  entry_call_statement
               [  sequence_of_statements]
            1else
0                  sequence_of_statements
            1end0 1select;


0     For the execution of a conditional entry call, the entry name is first evaluated.  This is followed by
     any evaluations required for actual parameters as in the case of a subprogram call (see 6.4).

     The entry call is canceled if the execution of the called task has not reached a point where it is ready
     to accept the call (that is, either an accept statement for the corresponding entry, or a select
     statement with an open accept alternative for the entry), or if there are prior queued entry calls for
     this entry.  If the called task has reached a select statement, the entry call is canceled if an accept
     alternative for this entry is not selected.

     If the entry call is canceled, the statements of the else part are executed.  Otherwise, the rendezvous
     takes place; and the optional sequence of statements after the entry call is then executed.

     The execution of a conditional entry call raises the exception TASKING_ERROR if the called task has
     already completed its execution (see also 9.10 for the case when the called task becomes abnormal).

     6Example:

0         1procedure0 SPIN(R : RESOURCE) 1is
0         1begin
0            1loop
0               1select
0                  R.SEIZE;
                  1return0;
               1else
0                  1null0;  6--  busy waiting
0               1end0 1select0;
            1end0 1loop0;
         1end0;

     6References:0 4 abnormal task 9.10, accept statement 9.5, actual parameter part 6.4, completed task
     9.4, entry call statement 9.5, entry family 9.5, entry index 9.5, evaluation 4.5, expression 4.4, open
     alternative 9.7.1, queued entry call 9.5, rendezvous 9.5, select statement 9.7, sequence of statements
     5.1, task 9, tasking_error exception 11.1 0

      subsection lrm-section9-7-3



     79.7.3. Timed Entry Calls

0     A timed entry call issues an entry call that is canceled if a rendezvous is not started within a given
     delay.

         timed_entry_call ::=
            1select
0                  entry_call_statement
               [  sequence_of_statements]
            1or
0                  delay_alternative
            1end0 1select;


0     For the execution of a timed entry call, the entry name is first evaluated.  This is followed by any
     evaluations required for actual parameters as in the case of a subprogram call (see 6.4).  The expression
     stating the delay is then evaluated, and the entry call is finally issued.

     If a rendezvous can be started within the specified duration (or immediately, as for a conditional entry
     call, for a negative or zero delay), it is performed and the optional sequence of statements after the
     entry call is then executed.  Otherwise, the entry call is canceled when the specified duration has
     expired, and the optional sequence of statements of the delay alternative is executed.

     The execution of a timed entry call raises the exception TASKING_ERROR if the called task completes its
     execution before accepting the call (see also 9.10 for the case when the called task becomes abnormal).

     6Example:

0         1select
0            CONTROLLER.REQUEST(MEDIUM)(SOME_ITEM);
         1or
0            1delay0 45.0;
            6--  controller too busy, try something else
0         1end0 1select0;

     6References:0 4 abnormal task 9.10, accept statement 9.5, actual parameter part 6.4, completed task
     9.4, conditional entry call 9.7.2, delay expression 9.6, delay statement 9.6, duration 9.6, entry call
     statement 9.5, entry family 9.5, entry index 9.5, evaluation 4.5, expression 4.4, rendezvous 9.5,
     sequence of statements 5.1, task 9, tasking_error exception 11.1 0

      section lrm-section9-8

     29.8. Priorities

0     Each task may (but need not) have a priority, which is a value of the subtype PRIORITY (of the type
     INTEGER) declared in the predefined library package SYSTEM (see 13.7).  A lower value indicates a lower
     degree of urgency; the range of priorities is implementation-defined.  A priority is associated with a
     task if a pragma

         1pragma0 PRIORITY (6static0_expression);

     appears in the corresponding task specification; the priority is given by the value of the expression.  A
     priority is associated with the main program if such a pragma appears in its outermost declarative part.
     At most one such pragma can appear within a given task specification or for a subprogram that is a
     library unit, and these are the only allowed places for this pragma.  A pragma PRIORITY has no effect if
     it occurs in a subprogram other than the main program.

     The specification of a priority is an indication given to assist the implementation in the allocation of
     processing resources to parallel tasks when there are more tasks eligible for execution than can be
     supported simultaneously by the available processing resources.  The effect of priorities on scheduling
     is defined by the following rule:
        - If two tasks with different priorities are both eligible for execution and could sensibly be
          executed using the same physical processors and the same other processing resources, then it
          cannot be the case that the task with the lower priority is executing while the task with the
          higher priority is not.

     For tasks of the same priority, the scheduling order is not defined by the language.  For tasks without
     explicit priority, the scheduling rules are not defined, except when such tasks are engaged in a
     rendezvous.  If the priorities of both tasks engaged in a rendezvous are defined, the rendezvous is
     executed with the higher of the two priorities.  If only one of the two priorities is defined, the
     rendezvous is executed with at least that priority.  If neither is defined, the priority of the
     rendezvous is undefined.

     6Notes:

0     The priority of a task is static and therefore fixed.  However, the priority during a rendezvous is not
     necessarily static since it also depends on the priority of the task calling the entry.  Priorities
     should be used only to indicate relative degrees of urgency; they should not be used for task
     synchronization.

     6References:0 4 declarative part 3.9, entry call statement 9.5, integer type 3.5.4, main program 10.1,
     package system 13.7, pragma 2.8, rendezvous 9.5, static expression 4.9, subtype 3.3, task 9, task
     specification 9.1 0

      section lrm-section9-9

     29.9. Task and Entry Attributes

0     For a task object or value T the following attributes are defined:

     T'CALLABLE          Yields the value FALSE when the execution of the task designated by T is either
                         completed or terminated, or when the task is abnormal.  Yields the value TRUE
                         otherwise.  The value of this attribute is of the predefined type BOOLEAN.

     T'TERMINATED        Yields the value TRUE if the task designated by T is terminated.  Yields the value
                         FALSE otherwise.  The value of this attribute is of the predefined type BOOLEAN.

     In addition, the representation attributes STORAGE_SIZE, SIZE, and ADDRESS are defined for a task object
     T or a task type T (see 13.7.2).

     The attribute COUNT is defined for an entry E of a task unit T. The entry can be either a single entry or
     an entry of a family (in either case the name of the single entry or entry family can be either a simple
     or an expanded name).  This attribute is only allowed within the body of T, but excluding within any
     program unit that is, itself, inner to the body of T.

     E'COUNT             Yields the number of entry calls presently queued on the entry E (if the attribute is
                         evaluated by the execution of an accept statement for the entry E, the count does not
                         include the calling task).  The value of this attribute is of the type
                         6universal0_6integer.

0     6Note:

0     Algorithms interrogating the attribute E'COUNT should take precautions to allow for the increase of the
     value of this attribute for incoming entry calls, and its decrease, for example with timed entry calls.

     6References:0 4 abnormal task 9.10, accept statement 9.5, attribute 4.1.4, boolean type 3.5.3,
     completed task 9.4, designate 9.1, entry 9.5, false boolean value 3.5.3, queue of entry calls 9.5,
     storage unit 13.7, task 9, task object 9.2, task type 9.1, terminated task 9.4, timed entry call 9.7.3,
     true boolean value 3.5.3, universal_integer type 3.5.4 0

      section lrm-section9-10

     29.10. Abort Statements

0     An abort statement causes one or more tasks to become 6abnormal,0 thus preventing any further
     rendezvous with such tasks.
         abort_statement ::= 1abort0 6task0_name {, 6task0_name};

     The determination of the type of each task name uses the fact that the type of the name is a task type.

     For the execution of an abort statement, the given task names are evaluated in some order that is not
     defined by the language.  Each named task then becomes abnormal unless it is already terminated;
     similarly, any task that depends on a named task becomes abnormal unless it is already terminated.

     Any abnormal task whose execution is suspended at an accept statement, a select statement, or a delay
     statement becomes completed; any abnormal task whose execution is suspended at an entry call, and that is
     not yet in a corresponding rendezvous, becomes completed and is removed from the entry queue; any
     abnormal task that has not yet started its activation becomes completed (and hence also terminated).
     This completes the execution of the abort statement.

     The completion of any other abnormal task need not happen before completion of the abort statement.  It
     must happen no later than when the abnormal task reaches a synchronization point that is one of the
     following: the end of its activation; a point where it causes the activation of another task; an entry
     call; the start or the end of an accept statement; a select statement; a delay statement; an exception
     handler; or an abort statement.  If a task that calls an entry becomes abnormal while in a rendezvous,
     its termination does not take place before the completion of the rendezvous (see 11.5).

     The call of an entry of an abnormal task raises the exception TASKING_ERROR at the place of the call.
     Similarly, the exception TASKING_ERROR is raised for any task that has called an entry of an abnormal
     task, if the entry call is still queued or if the rendezvous is not yet finished (whether the entry call
     is an entry call statement, or a conditional or timed entry call); the exception is raised no later than
     the completion of the abnormal task.  The value of the attribute CALLABLE is FALSE for any task that is
     abnormal (or completed).

     If the abnormal completion of a task takes place while the task updates a variable, then the value of
     this variable is undefined.  6Example:

0         1abort0 USER, TERMINAL.1all0, POOL(3);

     6Notes:

0     An abort statement should be used only in extremely severe situations requiring unconditional
     termination.  A task is allowed to abort any task, including itself.

     6References:0 4 abnormal in rendezvous 11.5, accept statement 9.5, activation 9.3, attribute 4.1.4,
     callable (predefined attribute) 9.9, conditional entry call 9.7.2, delay statement 9.6, dependent task
     9.4, entry call statement 9.5, evaluation of a name 4.1, exception handler 11.2, false boolean value
     3.5.3, name 4.1, queue of entry calls 9.5, rendezvous 9.5, select statement 9.7, statement 5, task 9,
     tasking_error exception 11.1, terminated task 9.4, timed entry call 9.7.3 0

      section lrm-section9-11

     29.11. Shared Variables

0     The normal means of communicating values between tasks is by entry calls and accept statements.

     If two tasks read or update a 6shared0 variable (that is, a variable accessible by both), then neither
     of them may assume anything about the order in which the other performs its operations, except at the
     points where they synchronize.  Two tasks are synchronized at the start and at the end of their
     rendezvous.  At the start and at the end of its activation, a task is synchronized with the task that
     causes this activation.  A task that has completed its execution is synchronized with any other task.

     For the actions performed by a program that uses shared variables, the following assumptions can always
     be made:

        - If between two synchronization points of a task, this task reads a shared variable whose type
          is a scalar or access type, then the variable is not updated by any other task at any time
          between these two points.

        - If between two synchronization points of a task, this task updates a shared variable whose type
          is a scalar or access type, then the variable is neither read nor updated by any other task at
          any time between these two points.

     The execution of the program is erroneous if any of these assumptions is violated.

     If a given task reads the value of a shared variable, the above assumptions allow an implementation to
     maintain local copies of the value (for example, in registers or in some other form of temporary
     storage); and for as long as the given task neither reaches a synchronization point nor updates the value
     of the shared variable, the above assumptions imply that, for the given task, reading a local copy is
     equivalent to reading the shared variable itself.

     Similarly, if a given task updates the value of a shared variable, the above assumptions allow an
     implementation to maintain a local copy of the value, and to defer the effective store of the local copy
     into the shared variable until a synchronization point, provided that every further read or update of the
     variable by the given task is treated as a read or update of the local copy.  On the other hand, an
     implementation is not allowed to introduce a store, unless this store would also be executed in the
     canonical order (see 11.6).

     The pragma SHARED can be used to specify that every read or update of a variable is a synchronization
     point for that variable; that is, the above assumptions always hold for the given variable (but not
     necessarily for other variables).  The form of this pragma is as follows:

         1pragma0 SHARED(6variable0_simple_name);

     This pragma is allowed only for a variable declared by an object declaration and whose type is a scalar
     or access type; the variable declaration and the pragma must both occur (in this order) immediately
     within the same declarative part or package specification; the pragma must appear before any occurrence
     of the name of the variable, other than in an address clause.

     An implementation must restrict the objects for which the pragma SHARED is allowed to objects for which
     each of direct reading and direct updating is implemented as an indivisible operation.

     6References:0 4 accept statement 9.5, activation 9.3, assignment 5.2, canonical order 11.6,
     declarative part 3.9, entry call statement 9.5, erroneous 1.6, global 8.1, package specification 7.1,
     pragma 2.8, read a value 6.2, rendezvous 9.5, simple name 3.1 4.1, task 9, type 3.3, update a value 6.2,
     variable 3.2.1 0

      section lrm-section9-12

     29.12. Example of Tasking

0     The following example defines a buffering task to smooth variations between the speed of output of a
     producing task and the speed of input of some consuming task.  For instance, the producing task may
     contain the statements

         1loop
0            6--  produce the next character CHAR
0            BUFFER.WRITE(CHAR);
            1exit0 1when0 CHAR = ASCII.EOT;
         1end0 1loop0;

     and the consuming task may contain the statements

         1loop
0            BUFFER.READ(CHAR);
            6--  consume the character CHAR
0            1exit0 1when0 CHAR = ASCII.EOT;
         1end0 1loop0;

     The buffering task contains an internal pool of characters processed in a round-robin fashion.  The pool
     has two indices, an IN_INDEX denoting the space for the next input character and an OUT_INDEX denoting
     the space for the next output character.

         1task0 BUFFER 1is
0            1entry0 READ (C : OUT  CHARACTER);
            1entry0 WRITE   (C : IN   CHARACTER);
         1end0;
         1task0 1body0 BUFFER 1is
0            POOL_SIZE    : 1constant0 INTEGER := 100;
            POOL   : 1array0(1 .. POOL_SIZE) 1of0 CHARACTER;
            COUNT  : INTEGER 1range0 0 .. POOL_SIZE := 0;
            IN_INDEX, OUT_INDEX : INTEGER 1range0 1 .. POOL_SIZE := 1;
         1begin
0            1loop
0               1select
0                  1when0 COUNT < POOL_SIZE =>
                     1accept0 WRITE(C : 1in0 CHARACTER) 1do
0                     .POOL(IN_INDEX) := C;
                     1end0;
                     IN_INDEX  := IN_INDEX 1mod0 POOL_SIZE + 1;
                     COUNT  := COUNT + 1;
               1or0 1when0 COUNT > 0 =>
                     1accept0 READ(C : 1out0 CHARACTER) 1do
0                     .C := POOL(OUT_INDEX);
                     1end0;
                     OUT_INDEX    := OUT_INDEX 1mod0 POOL_SIZE + 1;
                     COUNT  := COUNT - 1;
               1or
0                  1terminate0;
               1end0 1select0;
            1end0 1loop0;
         1end0 BUFFER;

      chapter lrm-chapter-10



                                   110. Program Structure and Compilation Issues

0     The overall structure of programs and the facilities for separate compilation are described in this
     chapter.  A program is a collection of one or more compilation units submitted to a compiler in one or
     more compilations.  Each compilation unit specifies the separate compilation of a construct which can be
     a subprogram declaration or body, a package declaration or body, a generic declaration or body, or a
     generic instantiation.  Alternatively this construct can be a subunit, in which case it includes the body
     of a subprogram, package, task unit, or generic unit declared within another compilation unit.

     6References:0 4 compilation 10.1, compilation unit 10.1, generic body 12.2, generic declaration 12.1,
     generic instantiation 12.3, package body 7.1, package declaration 7.1, subprogram body 6.3, subprogram
     declaration 6.1, subunit 10.2, task body 9.1, task unit 90

      section lrm-section10-1

     210.1. Compilation Units - Library Units

0     The text of a program can be submitted to the compiler in one or more compilations.  Each compilation is
     a succession of compilation units.

         compilation ::= {compilation_unit}

         compilation_unit ::=
             context_clause library_unit | context_clause secondary_unit

         library_unit ::=
             subprogram_declaration  | package_declaration
            |   generic_declaration  | generic_instantiation
            |   subprogram_body

         secondary_unit ::= library_unit_body | subunit

         library_unit_body ::= subprogram_body | package_body

     The compilation units of a program are said to belong to a 6program0 6library.0 A compilation unit
     defines either a library unit or a secondary unit.  A secondary unit is either the separately compiled
     proper body of a library unit, or a subunit of another compilation unit.  The designator of a separately
     compiled subprogram (whether a library unit or a subunit) must be an identifier.  Within a program
     library the simple names of all library units must be distinct identifiers.

     The effect of compiling a library unit is to define (or redefine) this unit as one that belongs to the
     program library.  For the visibility rules, each library unit acts as a declaration that occurs
     immediately within the package STANDARD.

     The effect of compiling a secondary unit is to define the body of a library unit, or in the case of a
     subunit, to define the proper body of a program unit that is declared within another compilation unit.

     A subprogram body given in a compilation unit is interpreted as a secondary unit if the program library
     already contains a library unit that is a subprogram with the same name; it is otherwise interpreted both
     as a library unit and as the corresponding library unit body (that is, as a secondary unit).

     The compilation units of a compilation are compiled in the given order.  A pragma that applies to the
     whole of a compilation must appear before the first compilation unit of that compilation.

     A subprogram that is a library unit can be used as a 6main0 6program0 in the usual sense.  Each main
     program acts as if called by some environment task; the means by which this execution is initiated are
     not prescribed by the language definition.  An implementation may impose certain requirements on the
     parameters and on the result, if any, of a main program (these requirements must be stated in Appendix
     F).  In any case, every implementation is required to allow, at least, main programs that are
     parameterless procedures, and every main program must be a subprogram that is a library unit.

     6Notes:

0     A simple program may consist of a single compilation unit.  A compilation need not have any compilation
     units; for example, its text can consist of pragmas.

     The designator of a library function cannot be an operator symbol, but a renaming declaration is allowed
     to rename a library function as an operator.  Two library subprograms must have distinct simple names and
     hence cannot overload each other.  However, renaming declarations are allowed to define overloaded names
     for such subprograms, and a locally declared subprogram is allowed to overload a library subprogram.  The
     expanded name STANDARD.L can be used for a library unit L (unless the name STANDARD is hidden) since
     library units act as declarations that occur immediately within the package STANDARD.

     6References:0 4 allow 1.6, context clause 10.1.1, declaration 3.1, designator 6.1, environment 10.4,
     generic declaration 12.1, generic instantiation 12.3, hiding 8.3, identifier 2.3, library unit 10.5,
     local declaration 8.1, must 1.6, name 4.1, occur immediately within 8.1, operator 4.5, operator symbol
     6.1, overloading 6.6 8.7, package body 7.1, package declaration 7.1, parameter of a subprogram 6.2,
     pragma 2.8, procedure 6.1, program unit 6, proper body 3.9, renaming declaration 8.5, simple name 4.1,
     standard package 8.6, subprogram 6, subprogram body 6.3, subprogram declaration 6.1, subunit 10.2, task
     9, visibility 8.3 0

      subsection lrm-section10-1-1



     710.1.1. Context Clauses - With Clauses

0     A context clause is used to specify the library units whose names are needed within a compilation unit.

         context_clause ::= {with_clause {use_clause}}

         with_clause ::= 1with0 6unit0_simple_name {, 6unit0_simple_name};

     The names that appear in a context clause must be the simple names of library units.  The simple name of
     any library unit is allowed within a with clause.  The only names allowed in a use clause of a context
     clause are the simple names of library packages mentioned by previous with clauses of the context clause.
     A simple name declared by a renaming declaration is not allowed in a context clause.

     The with clauses and use clauses of the context clause of a library unit 6apply0 to this library unit
     and also to the secondary unit that defines the corresponding body (whether such a clause is repeated or
     not for this unit).  Similarly, the with clauses and use clauses of the context clause of a compilation
     unit 6apply0 to this unit and also to its subunits, if any.

     If a library unit is named by a with clause that applies to a compilation unit, then this library unit is
     directly visible within the compilation unit, except where hidden; the library unit is visible as if
     declared immediately within the package STANDARD (see 8.6).

     Dependences among compilation units are defined by with clauses; that is, a compilation unit that
     mentions other library units in its with clauses 6depends0 on those library units.  These dependences
     between units are taken into account for the determination of the allowed order of compilation (and
     recompilation) of compilation units, as explained in section 10.3, and for the determination of the
     allowed order of elaboration of compilation units, as explained in section 10.5.

     6Notes:

0     A library unit named by a with clause of a compilation unit is visible (except where hidden) within the
     compilation unit and hence can be used as a corresponding program unit.  Thus within the compilation
     unit, the name of a library package can be given in use clauses and can be used to form expanded names; a
     library subprogram can be called; and instances of a library generic unit can be declared.

     The rules given for with clauses are such that the same effect is obtained whether the name of a library
     unit is mentioned once or more than once by the applicable with clauses, or even within a given with
     clause.

     6Example0 1 : 6A0 6main0 6program:

0     The following is an example of a main program consisting of a single compilation unit:  a procedure for
     printing the real roots of a quadratic equation.  The predefined package TEXT_IO and a user-defined
     package REAL_OPERATIONS (containing the definition of the type REAL and of the packages REAL_IO and
     REAL_FUNCTIONS) are assumed to be already present in the program library.  Such packages may be used by
     other main programs.

         1with0 TEXT_IO, REAL_OPERATIONS; 1use0 REAL_OPERATIONS;
         1procedure0 QUADRATIC_EQUATION 1is
0            A, B, C, D : REAL;
            USE    REAL_IO,       6--  achieves direct visibility of GET and PUT for REAL
0             TEXT_IO,              6--  achieves direct visibility of PUT for strings and of NEW0_6LINE
0             REAL_FUNCTIONS;    6--  achieves direct visibility of SQRT
0         1begin
0            GET(A); GET(B); GET(C);
            D := B**2 - 4.0*A*C;
            1if0 D < 0.0 1then
0               PUT("IMAGINARY ROOTS.");
            1else
0               PUT("REAL ROOTS : X1 = ");
               PUT((-B -    SQRT(D))/(2.0*A)); PUT(" X2 = ");
               PUT((-B +    SQRT(D))/(2.0*A));
            1end0 1if0;
            NEW_LINE;
         1end0 QUADRATIC_EQUATION;

     6Notes0 6on0 6the0 6example:

0     The with clauses of a compilation unit need only mention the names of those library subprograms and
     packages whose visibility is actually necessary within the unit.  They need not (and should not) mention
     other library units that are used in turn by some of the units named in the with clauses, unless these
     other library units are also used directly by the current compilation unit.  For example, the body of the
     package REAL_OPERATIONS may need elementary operations provided by other packages.  The latter packages
     should not be named by the with clause of QUADRATIC_EQUATION since these elementary operations are not
     directly called within its body.

     6References:0 4 allow 1.6, compilation unit 10.1, direct visibility 8.3, elaboration 3.9, generic body
     12.2, generic unit 12.1, hiding 8.3, instance 12.3, library unit 10.1, main program 10.1, must 1.6, name
     4.1, package 7, package body 7.1, package declaration 7.1, procedure 6.1, program unit 6, secondary unit
     10.1, simple name 4.1, standard predefined package 8.6, subprogram body 6.3, subprogram declaration 6.1,
     subunit 10.2, type 3.3, use clause 8.4, visibility 8.30

      subsection lrm-section10-1-2



     710.1.2. Examples of Compilation Units

0     A compilation unit can be split into a number of compilation units.  For example, consider the following
     program.

         1procedure0 PROCESSOR 1is

0            SMALL  : CONSTANT  := 20;
            TOTAL  : INTEGER   := 0;

            1package0 STOCK 1is
0               LIMIT  : 1constant0 := 1000;
               TABLE  : 1array0 (1 .. LIMIT) 1of0 INTEGER;
               1procedure0 RESTART;
            1end0 STOCK;

            1package0 1body0 STOCK 1is
0               1procedure0 RESTART 1is
0               1begin
0                  1for0 N 1in0 1 .. LIMIT 1loop
0                     TABLE(N) := N;
                  1end0 1loop0;
               1end0;
            1begin
0               RESTART;
            1end0 STOCK;

            1procedure0 UPDATE(X : INTEGER) 1is
0               1use0 STOCK;
            1begin
0                  ...
               TABLE(X) := TABLE(X) + SMALL;
                  ...
            end UPDATE;

         1begin
0            ...
            STOCK.RESTART;  -- REINITIALIZES TABLE
            ...
         1end0 PROCESSOR;

     The following three compilation units define a program with an effect equivalent to the above example
     (the broken lines between compilation units serve to remind the reader that these units need not be
     contiguous texts).

     6Example0 2 : 6Several0 6compilation0 6units:

0         1package0 STOCK 1is
0            LIMIT  : 1constant0 := 1000;
            TABLE  : 1array0 (1 .. LIMIT) 1of0 INTEGER;
            1procedure0 RESTART;
         1end0 STOCK;

         -----------------------------------------------6--

0         1package0 1body0 STOCK 1is
0            1procedure0 RESTART 1is
0            1begin
0               1for0 N 1in0 1 .. LIMIT 1loop
0                  TABLE(N) := N;
               1end0 1loop0;
            1end0;
         1begin
0            RESTART;
         1end0 STOCK;

         -----------------------------------------------6--

0         1with0 STOCK;
         1procedure0 PROCESSOR 1is

0            SMALL  : CONSTANT  := 20;
            TOTAL  : INTEGER   := 0;

            1procedure0 UPDATE(X : INTEGER) 1is
0               1use0 STOCK;
            1begin
0               ...
               TABLE(X) := TABLE(X) + SMALL;
               ...
            end UPDATE;
         1begin
0            ...
            STOCK.RESTART;  6--  reinitializes TABLE
0            ...
         1end0 PROCESSOR;

     Note that in the latter version, the package STOCK has no visibility of outer identifiers other than the
     predefined identifiers (of the package STANDARD).  In particular, STOCK does not use any identifier
     declared in PROCESSOR such as SMALL or TOTAL; otherwise STOCK could not have been extracted from
     PROCESSOR in the above manner.  The procedure PROCESSOR, on the other hand, depends on STOCK and mentions
     this package in a with clause.  This permits the inner occurrences of STOCK in the expanded name
     STOCK.RESTART and in the use clause.

     These three compilation units can be submitted in one or more compilations.  For example, it is possible
     to submit the package specification and the package body together and in this order in a single
     compilation.

     6References:0 4 compilation unit 10.1, declaration 3.1, identifier 2.3, package 7, package body 7.1,
     package specification 7.1, program 10, standard package 8.6, use clause 8.4, visibility 8.3, with clause
     10.1.10

      section lrm-section10-2

     210.2. Subunits of Compilation Units

0     A subunit is used for the separate compilation of the proper body of a program unit declared within
     another compilation unit.  This method of splitting a program permits hierarchical program development.

         body_stub ::=
             subprogram_specification 1is0 1separate;
0            |   1package0 1body0 6package0_simple_name 1is0 1separate;
0            |   1task0 1body0 6task0_simple_name 1is0 1separate;
0         }

         subunit ::=
             1separate0 (6parent_unit0_name) proper_body

     A body stub is only allowed as the body of a program unit (a subprogram, a package, a task unit, or a
     generic unit) if the body stub occurs immediately within either the specification of a library package or
     the declarative part of another compilation unit.

     If the body of a program unit is a body stub, a separately compiled subunit containing the corresponding
     proper body is required.  In the case of a subprogram, the subprogram specifications given in the proper
     body and in the body stub must conform (see 6.3.1).

     Each subunit mentions the name of its 6parent0 6unit,0 that is, the compilation unit where the
     corresponding body stub is given.  If the parent unit is a library unit, it is called the 6ancestor
0     library unit.  If the parent unit is itself a subunit, the parent unit name must be given in full as an
     expanded name, starting with the simple name of the ancestor library unit.  The simple names of all
     subunits that have the same ancestor library unit must be distinct identifiers.

     Visibility within the proper body of a subunit is the visibility that would be obtained at the place of
     the corresponding body stub (within the parent unit) if the with clauses and use clauses of the subunit
     were appended to the context clause of the parent unit.  If the parent unit is itself a subunit, then the
     same rule is used to define the visibility within the proper body of the parent unit.

     The effect of the elaboration of a body stub is to elaborate the proper body of the subunit.

     6Notes:

0     Two subunits of different library units in the same program library need not have distinct identifiers.
     In any case, their full expanded names are distinct, since the simple names of library units are distinct
     and since the simple names of all subunits that have a given library unit as ancestor unit are also
     distinct.  By means of renaming declarations, overloaded subprogram names that rename (distinct) subunits
     can be introduced.

     A library unit that is named by the with clause of a subunit can be hidden by a declaration (with the
     same identifier) given in the proper body of the subunit.  Moreover, such a library unit can even be
     hidden by a declaration given within a parent unit since a library unit acts as if declared in STANDARD;
     this however does not affect the interpretation of the with clauses themselves, since only names of
     library units can appear in with clauses.

     6References:0 4 compilation unit 10.1, conform 6.3.1, context clause 10.1.1, declaration 3.1,
     declarative part 3.9, direct visibility 8.3, elaboration 3.9, expanded name 4.1.3, generic body 12.2,
     generic unit 12, hidden declaration 8.3, identifier 2.3, library unit 10.1, local declaration 8.1, name
     4.1, occur immediately within 8.1, overloading 8.3, package 7, package body 7.1, package specification
     7.1, program 10, program unit 6, proper body 3.9, renaming declaration 8.5, separate compilation 10.1,
     simple name 4.1, subprogram 6, subprogram body 6.3, subprogram specification 6.1, task 9, task body 9.1,
     task unit 9.1, use clause 8.4, visibility 8.3, with clause 10.1.10

      subsection lrm-section10-2-1



     710.2.1. Examples of Subunits

0     The procedure TOP is first written as a compilation unit without subunits.

         1with0 TEXT_IO;
         1procedure0 TOP 1is

0            1type0 REAL 1is0 1digits0 10;
            R, S : REAL := 1.0;

            1package0 FACILITY 1is
0               PI : 1constant0 := 3.14159_26536;
               FUNCTION  F (X : REAL) 1return0 REAL;
               PROCEDURE    G (Y, Z : REAL);
            1end0 FACILITY;

            1package0 1body0 FACILITY 1is
0               6--  some local declarations followed by

0               1function0 F(X : REAL) 1return0 REAL 1is
0               1begin
0                  6--  sequence of statements of F
0                     ..
               1end0 F;

               1procedure0 G(Y, Z : REAL) 1is
0                  6--  local procedures using TEXT_IO
0                     ..
               1begin
0                  6--  sequence of statements of G
0                     ..
               1end0 G;
            1end0 FACILITY;

            1procedure0 TRANSFORM(U : 1in0 1out0 REAL) 1is
0               1use0 FACILITY;
            1begin
0               U := F(U);
                     .
            end TRANSFORM;
         1begin0 -- TOP
            TRANSFORM(R);

            FACILITY.G(R, S);
         1end0 TOP;


     The body of the package FACILITY and that of the procedure TRANSFORM can be made into separate subunits
     of TOP.  Similarly, the body of the procedure G can be made into a subunit of FACILITY as follows.

     6Example0 3:

         1procedure0 TOP 1is

0            1type0 REAL 1is0 1digits0 10;
            R, S : REAL := 1.0;

            1package0 FACILITY 1is
0               PI : 1constant0 := 3.14159_26536;
               FUNCTION  F (X : REAL) 1return0 REAL;
               PROCEDURE    G (Y, Z : REAL);
            1end0 FACILITY;

            1package0 1body0 FACILITY 1is0 1separate0;                   6--  stub of FACILITY
0            1procedure0 TRANSFORM(U: 1in0 1out0 REAL) 1is0 1separate0; 6--  stub of TRANSFORM

0         1begin0  6--  TOP
0            TRANSFORM(R);
            ...
            FACILITY.G(R, S);
         1end0 TOP;

         -----------------------------------------------6--

0         1separate0 (TOP)
         1procedure0 TRANSFORM(U : 1in0 1out0 REAL) 1is
0            1use0 FACILITY;
         1begin
0            U := F(U);
            ...
         1end0 TRANSFORM;

         -----------------------------------------------6--

0         1separate0 (TOP)
         1package0 1body0 FACILITY 1is
0            6--  some local declarations followed by

0            1function0 F(X : REAL) 1return0 REAL 1is
0            1begin
0               6--  sequence of statements of F
0               ...
            end F;

            1procedure0 G(Y, Z : REAL) 1is0 1separate0;                 -- 6stub of G
0         1end0 FACILITY;


         -----------------------------------------------6--

0         1with0 TEXT_IO;
         1separate0 (TOP.FACILITY)                                 6--  full name of FACILITY
0         1procedure0 G(Y, Z : REAL) 1is
0            6--  local procedures using TEXT_IO
0            ...
         1begin
0            6--  sequence of statements of G
0            ...
         1end0 G;

     In the above example TRANSFORM and FACILITY are subunits of TOP, and G is a subunit of FACILITY.  The
     visibility in the split version is the same as in the initial version except for one change:  since
     TEXT_IO is only used within G, the corresponding with clause is written for G instead of for TOP.  Apart
     from this change, the same identifiers are visible at corresponding program points in the two versions.
     For example, all of the following are (directly) visible within the proper body of the subunit G:  the
     procedure TOP, the type REAL, the variables R and S, the package FACILITY and the contained named number
     PI and subprograms F and G.

     6References:0 4 body stub 10.2, compilation unit 10.1, identifier 2.3, local declaration 8.1, named
     number 3.2, package 7, package body 7.1, procedure 6, procedure body 6.3, proper body 3.9, subprogram 6,
     type 3.3, variable 3.2.1, visibility 8.3, with clause 10.1.10

      section lrm-section10-3

     210.3. Order of Compilation

0     The rules defining the order in which units can be compiled are direct consequences of the visibility
     rules and, in particular, of the fact that any library unit that is mentioned by the context clause of a
     compilation unit is visible in the compilation unit.  }

     A compilation unit must be compiled after all library units named by its context clause.  A secondary
     unit that is a subprogram or package body must be compiled after the corresponding library unit.  Any
     subunit of a parent compilation unit must be compiled after the parent compilation unit.

     If any error is detected while attempting to compile a compilation unit, then the attempted compilation
     is rejected and it has no effect whatsoever on the program library; the same holds for recompilations (no
     compilation unit can become obsolete because of such a recompilation).

     The order in which the compilation units of a program are compiled must be consistent with the partial
     ordering defined by the above rules.

     Similar rules apply for recompilations.  A compilation unit is potentially affected by a change in any
     library unit named by its context clause.  A secondary unit is potentially affected by a change in the
     corresponding library unit.  The subunits of a parent compilation unit are potentially affected by a
     change of the parent compilation unit.  If a compilation unit is successfully recompiled, the compilation
     units potentially affected by this change are obsolete and must be recompiled unless they are no longer
     needed.  An implementation may be able to reduce the compilation costs if it can deduce that some of the
     potentially affected units are not actually affected by the change.

     The subunits of a unit can be recompiled without affecting the unit itself.  Similarly, changes in a
     subprogram or package body do not affect other compilation units (apart from the subunits of the body)
     since these compilation units only have access to the subprogram or package specification.  An
     implementation is only allowed to deviate from this rule for inline inclusions, for certain compiler
     optimizations, and for certain implementations of generic program units, as described below.

        - If a pragma INLINE is applied to a subprogram declaration given in a package specification,
          inline inclusion will only be achieved if the package body is compiled before units calling the
          subprogram.  In such a case, inline inclusion creates a 6dependence0 of the calling unit on
          the package body, and the compiler must recognize this dependence when deciding on the need for
          recompilation.  If a calling unit is compiled before the package body, the pragma may be
          ignored by the compiler for such calls (a warning that inline inclusion was not achieved may be
          issued).  Similar considerations apply to a separately compiled subprogram for which an INLINE
          pragma is specified.

        - For optimization purposes, an implementation may compile several units of a given compilation
          in a way that creates further dependences among these compilation units.  The compiler must
          then take these dependences into account when deciding on the need for recompilations.

        - An implementation may require that a generic declaration and the corresponding proper body be
          part of the same compilation, whether the generic unit is itself separately compiled or is
          local to another compilation unit.  An implementation may also require that subunits of a
          generic unit be part of the same compilation.

     6Examples0 6of0 6Compilation0 6Order:

0        - In example 1 (see 10.1.1):  The procedure QUADRATIC_EQUATION must be compiled after the library
          packages TEXT_IO and REAL_OPERATIONS since they appear in its with clause.

        - In example 2 (see 10.1.2):  The package body STOCK must be compiled after the corresponding
          package specification.

        - In example 2 (see 10.1.2):  The specification of the package STOCK must be compiled before the
          procedure PROCESSOR.  On the other hand, the procedure PROCESSOR can be compiled either before
          or after the package body STOCK.

        - In example 3 (see 10.2.1):  The procedure G must be compiled after the package TEXT_IO since
          this package is named by the with clause of G. On the other hand, TEXT_IO can be compiled
          either before or after TOP.

        - In example 3 (see 10.2.1):  The subunits TRANSFORM and FACILITY must be compiled after the main
          program TOP.  Similarly, the subunit G must be compiled after its parent unit FACILITY.

     6Notes:

0     For library packages, it follows from the recompilation rules that a package body is made obsolete by the
     recompilation of the corresponding specification.  If the new package specification is such that a
     package body is not required (that is, if the package specification does not contain the declaration of a
     program unit), then the recompilation of a body for this package is not required.  In any case, the
     obsolete package body must not be used and can therefore be deleted from the program library.

     6References:0 4 compilation 10.1, compilation unit 10.1, context clause 10.1.1, elaboration 3.9,
     generic body 12.2, generic declaration 12.1, generic unit 12, library unit 10.1, local declaration 8.1,
     name 4.1, package 7, package body 7.1, package specification 7.1, parent unit 10.2, pragma inline 6.3.2,
     procedure 6.1, procedure body 6.3, proper body 3.9, secondary unit 10.1, subprogram body 6.3, subprogram
     declaration 6.1, subprogram specification 6.1, subunit 10.2, type 3.3, variable 3.2.1, visibility 8.3,
     with clause 10.1.10

      section lrm-section10-4

     210.4. The Program Library

0     Compilers are required to enforce the language rules in the same manner for a program consisting of
     several compilation units (and subunits) as for a program submitted as a single compilation.
     Consequently, a library file containing information on the compilation units of the program library must
     be maintained by the compiler or compiling environment.  This information may include symbol tables and
     other information pertaining to the order of previous compilations.

     A normal submission to the compiler consists of the compilation unit(s) and the library file.  The latter
     is used for checks and is updated for each compilation unit successfully compiled.

     6Notes:

0     A single program library is implied for the compilation units of a compilation.  The possible existence
     of different program libraries and the means by which they are named are not concerns of the language
     definition; they are concerns of the programming environment.

     There should be commands for creating the program library of a given program or of a given family of
     programs.  These commands may permit the reuse of units of other program libraries.  Finally, there
     should be commands for interrogating the status of the units of a program library.  The form of these
     commands is not specified by the language definition.

     6References:0 4 compilation unit 10.1, context clause 10.1.1, order of compilation 10.3, program 10.1,
     program library 10.1, subunit 10.2, use clause 8.4, with clause 10.1.10

      section lrm-section10-5

     210.5. Elaboration of Library Units

0     Before the execution of a main program, all library units needed by the main program are elaborated, as
     well as the corresponding library unit bodies, if any.  The library units needed by the main program are:
     those named by with clauses applicable to the main program, to its body, and to its subunits; those named
     by with clauses applicable to these library units themselves, to the corresponding library unit bodies,
     and to their subunits; and so on, in a transitive manner.

     The elaboration of these library units and of the corresponding library unit bodies is performed in an
     order consistent with the partial ordering defined by the with clauses (see 10.3).  In addition, a
     library unit mentioned by the context clause of a subunit must be elaborated before the body of the
     ancestor library unit of the subunit.

     An order of elaboration that is consistent with this partial ordering does not always ensure that each
     library unit body is elaborated before any other compilation unit whose elaboration necessitates that the
     library unit body be already elaborated.  If the prior elaboration of library unit bodies is needed, this
     can be requested by a pragma ELABORATE.  The form of this pragma is as follows:
         1pragma0 ELABORATE (6library0_6unit0_simple_name {, 6library0_6unit0_simple_name});

     These pragmas are only allowed immediately after the context clause of a compilation unit (before the
     subsequent library unit or secondary unit).  Each argument of such a pragma must be the simple name of a
     library unit mentioned by the context clause, and this library unit must have a library unit body.  Such
     a pragma specifies that the library unit body must be elaborated before the given compilation unit.  If
     the given compilation unit is a subunit, the library unit body must be elaborated before the body of the
     ancestor library unit of the subunit.

     The program is illegal if no consistent order can be found (that is, if a circularity exists).  The
     elaboration of the compilation units of the program is performed in some order that is otherwise not
     defined by the language.

     6References:0 4 allow 1.6, argument of a pragma 2.8, compilation unit 10.1, context clause 10.1.1,
     dependence between compilation units 10.3, elaboration 3.9, illegal 1.6, in some order 1.6, library unit
     10.1, name 4.1, main program 10.1, pragma 2.8, secondary unit 10.1, separate compilation 10.1, simple
     name 4.1, subunit 10.2, with clause 10.1.1 0

      section lrm-section10-6

     210.6. Program Optimization

0     Optimization of the elaboration of declarations and the execution of statements may be performed by
     compilers.  In particular, a compiler may be able to optimize a program by evaluating certain
     expressions, in addition to those that are static expressions.  Should one of these expressions, whether
     static or not, be such that an exception would be raised by its evaluation, then the code in that path of
     the program can be replaced by code to raise the exception; the same holds for exceptions raised by the
     evaluation of names and simple expressions.  (See also section 11.6.)

     A compiler may find that some statements or subprograms will never be executed, for example, if their
     execution depends on a condition known to be FALSE.  The corresponding object machine code can then be
     omitted.  This rule permits the effect of 6conditional0 6compilation0 within the language.

     6Note:

0     An expression whose evaluation is known to raise an exception need not represent an error if it occurs in
     a statement or subprogram that is never executed.  The compiler may warn the programmer of a potential
     error.

     6References:0 4 condition 5.3, declaration 3.1, elaboration 3.9, evaluation 4.5, exception 11,
     expression 4.4, false boolean value 3.5.3, program 10, raising of exceptions 11.3, statement 5, static
     expression 4.9, subprogram 6 0

      chapter lrm-chapter-11



                                                  111. Exceptions

0     This chapter defines the facilities for dealing with errors or other exceptional situations that arise
     during program execution.  Such a situation is called an 6exception.0 To 6raise0 an exception is to
     abandon normal program execution so as to draw attention to the fact that the corresponding situation has
     arisen.  Executing some actions, in response to the arising of an exception, is called 6handling0 the
     exception.

     An exception declaration declares a name for an exception.  An exception can be raised by a raise
     statement, or it can be raised by another statement or operation that 6propagates0 the exception.  When
     an exception arises, control can be transferred to a user-provided exception handler at the end of a
     block statement or at the end of the body of a subprogram, package, or task unit.

     6References:0 4 block statement 5.6, error situation 1.6, exception handler 11.2, name 4.1, package
     body 7.1, propagation of an exception 11.4.1 11.4.2, raise statement 11.3, subprogram body 6.3, task body
     9.1 0

      section lrm-section11-1

     211.1. Exception Declarations

0     An exception declaration declares a name for an exception.  The name of an exception can only be used in
     raise statements, exception handlers, and renaming declarations.

         exception_declaration ::= identifier_list : 1exception0;

     An exception declaration with several identifiers is equivalent to a sequence of single exception
     declarations, as explained in section 3.2.  Each single exception declaration declares a name for a
     different exception.  In particular, if a generic unit includes an exception declaration, the exception
     declarations implicitly generated by different instantiations of the generic unit refer to distinct
     exceptions (but all have the same identifier).  The particular exception denoted by an exception name is
     determined at compilation time and is the same regardless of how many times the exception declaration is
     elaborated.  Hence, if an exception declaration occurs in a recursive subprogram, the exception name
     denotes the same exception for all invocations of the recursive subprogram.

     The following exceptions are predefined in the language; they are raised when the situations described
     are detected.

     CONSTRAINT_ERROR    This exception is raised in any of the following situations:  upon an attempt to
                         violate a range constraint, an index constraint, or a discriminant constraint; upon
                         an attempt to use a record component that does not exist for the current discriminant
                         values; and upon an attempt to use a selected component, an indexed component, a
                         slice, or an attribute, of an object designated by an access value, if the object
                         does not exist because the access value is null.

     NUMERIC_ERROR       This exception is raised by the execution of a predefined numeric operation that
                         cannot deliver a correct result (within the declared accuracy for real types); this
                         includes the case where an implementation uses a predefined numeric operation for the
                         execution, evaluation, or elaboration of some construct.  The rules given in section
                         4.5.7 define the cases in which an implementation is not required to raise this
                         exception when such an error situation arises; see also section 11.6.

     PROGRAM_ERROR       This exception is raised upon an attempt to call a subprogram, to activate a task, or
                         to elaborate a generic instantiation, if the body of the corresponding unit has not
                         yet been elaborated.  This exception is also raised if the end of a function is
                         reached (see 6.5); or during the execution of a selective wait that has no else part,
                         if this execution determines that all alternatives are closed (see 9.7.1).  Finally,
                         depending on the implementation, this exception may be raised upon an attempt to
                         execute an action that is erroneous, and for incorrect order dependences (see 1.6).

     STORAGE_ERROR       This exception is raised in any of the following situations:  when the dynamic
                         storage allocated to a task is exceeded; during the evaluation of an allocator, if
                         the space available for the collection of allocated objects is exhausted; or during
                         the elaboration of a declarative item, or during the execution of a subprogram call,
                         if storage is not sufficient.

     TASKING_ERROR       This exception is raised when exceptions arise during intertask communication (see 9
                         and 11.5).

     6Note:

0     The situations described above can arise without raising the corresponding exceptions, if the pragma
     SUPPRESS has been used to give permission to omit the corresponding checks (see 11.7).

     6Examples0 6of0 6user-defined0 6exception0 6declarations:

0         SINGULAR  : 1exception0;
         ERROR  : 1exception0;
         OVERFLOW, UNDERFLOW : 1exception0;

     6References:0 4 access value 3.8, collection 3.8, declaration 3.1, exception 11, exception handler
     11.2, generic body 12.2, generic instantiation 12.3, generic unit 12, identifier 2.3, implicit
     declaration 12.3, instantiation 12.3, name 4.1, object 3.2, raise statement 11.3, real type 3.5.6, record
     component 3.7, return statement 5.8, subprogram 6, subprogram body 6.3, task 9, task body 9.1 

0     6Constraint_error0 6exception0 6contexts:0 4 aggregate 4.3.1 4.3.2, allocator 4.8, assignment
     statement 5.2 5.2.1, constraint 3.3.2, discrete type attribute 3.5.5, discriminant constraint 3.7.2,
     elaboration of a generic formal parameter 12.3.1 12.3.2 12.3.4 12.3.5, entry index 9.5, exponentiating
     operator 4.5.6, index constraint 3.6.1, indexed component 4.1.1, logical operator 4.5.1, null access
     value 3.8, object declaration 3.2.1, parameter association 6.4.1, qualified expression 4.7, range
     constraint 3.5, selected component 4.1.3, slice 4.1.2, subtype indication 3.3.2, type conversion 4.6 

0     6Numeric_error0 6exception0 6contexts:0 4 discrete type attribute 3.5.5, implicit conversion 3.5.4
     3.5.6 4.6, numeric operation 3.5.5 3.5.8 3.5.10, operator of a numeric type 4.5 4.5.70,4 collection 3.8,
0    4elaboration 3.9, elaboration check 3.9 7.3 9.3 12.2, erroneous 1.6, incorrect order dependence 1.6,
0    4leaving a function 6.5, selective wait 9.7.10,4 comment allocator 4.8, abort statement 9.10,
0 4    entry call 9.5 9.7.2 9.7.3, exceptions during task communication 11.5, task activation 9.30

      section lrm-section11-2

     211.2. Exception Handlers

0     The response to one or more exceptions is specified by an exception handler.

         exception_handler ::=
            1when0 exception_choice {| exception_choice} =>
               sequence_of_statements

         exception_choice ::= 6exception0_name | 1others

0     An exception handler occurs in a construct that is either a block statement or the body of a subprogram,
     package, task unit, or generic unit.  Such a construct will be called a 6frame0 in this chapter.  In
     each case the syntax of a frame that has exception handlers includes the following part:

         1begin
0            sequence_of_statements
         1exception
0            exception_handler
            {  exception_handler}
         1end

0     The exceptions denoted by the exception names given as exception choices of a frame must all be distinct.
     The exception choice 1others0 is only allowed for the last exception handler of a frame and as its only
     exception choice; it stands for all exceptions not listed in previous handlers of the frame, including
     exceptions whose names are not visible at the place of the exception handler.

     The exception handlers of a frame handle exceptions that are raised by the execution of the sequence of
     statements of the frame.  The exceptions handled by a given exception handler are those named by the
     corresponding exception choices.

     6Example:

0         1begin
0            6--  sequence of statements
0         1exception
0            1when0 SINGULAR | NUMERIC_ERROR =>
               PUT(" MATRIX IS SINGULAR ");
            1when0 1OTHERS0 =>
               PUT(" FATAL ERROR ");
               1raise0 ERROR;
         1end0;

     6Note:

0     The same kinds of statement are allowed in the sequence of statements of each exception handler as are
     allowed in the sequence of statements of the frame.  For example, a return statement is allowed in a
     handler within a function body.

     6References:0 4 block statement 5.6, declarative part 3.9, exception 11, exception handling 11.4,
     function body 6.3, generic body 12.2, generic unit 12.1, name 4.1, package body 7.1, raise statement
     11.3, return statement 5.8, sequence of statements 5.1, statement 5, subprogram body 6.3, task body 9.1,
     task unit 9 9.1, visibility 8.3 0

      section lrm-section11-3

     211.3. Raise Statements

0     A raise statement raises an exception.

         raise_statement ::= 1raise0 [6exception0_name];

     For the execution of a raise statement with an exception name, the named exception is raised.  A raise
     statement without an exception name is only allowed within an exception handler (but not within the
     sequence of statements of a subprogram, package, task unit, or generic unit, enclosed by the handler); it
     raises again the exception that caused transfer to the innermost enclosing handler.

     6Examples:

0         1raise0 SINGULAR;
         1raise0 NUMERIC_ERROR;     6--  explicitly raising a predefined exception

0         1raise0;    6--  only within an exception handler

0     6References:0 4 exception 11, generic unit 12, name 4.1, package 7, sequence of statements 5.1,
     subprogram 6, task unit 9 0

      section lrm-section11-4

     211.4. Exception Handling

0     When an exception is raised, normal program execution is abandoned and control is transferred to an
     exception handler.  The selection of this handler depends on whether the exception is raised during the
     execution of statements or during the elaboration of declarations.

     6References:0 4 declaration 3.1, elaboration 3.1 3.9, exception 11, exception handler 11.2, raising of
     exceptions 11.3, statement 5 0

      subsection lrm-section11-4-1



     711.4.1. Exceptions Raised During the Execution of Statements

0     The handling of an exception raised by the execution of a sequence of statements depends on whether the
     innermost frame or accept statement that encloses the sequence of statements is a frame or an accept
     statement.  The case where an accept statement is innermost is described in section 11.5.  The case where
     a frame is innermost is presented here.

     Different actions take place, depending on whether or not this frame has a handler for the exception, and
     on whether the exception is raised in the sequence of statements of the frame or in that of an exception
     handler.

     If an exception is raised in the sequence of statements of a frame that has a handler for the exception,
     execution of the sequence of statements of the frame is abandoned and control is transferred to the
     exception handler.  The execution of the sequence of statements of the handler completes the execution of
     the frame (or its elaboration if the frame is a package body).

     If an exception is raised in the sequence of statements of a frame that does not have a handler for the
     exception, execution of this sequence of statements is abandoned.  The next action depends on the nature
     of the frame:

        - For a subprogram body, the same exception is raised again at the point of call of the
          subprogram, unless the subprogram is the main program itself, in which case execution of the
          main program is abandoned.

        - For a block statement, the same exception is raised again immediately after the block statement
          (that is, within the innermost enclosing frame or accept statement).

        - For a package body that is a declarative item, the same exception is raised again immediately
          after this declarative item (within the enclosing declarative part). If the package body is
          that of a subunit, the exception is raised again at the place of the corresponding body stub.
          If the package is a library unit, execution of the main program is abandoned.

        - For a task body, the task becomes completed.

     An exception that is raised again (as in the above cases (a), (b), and (c)) is said to be 6propagated,
0     either by the execution of the subprogram, the execution of the block statement, or the elaboration of
     the package body.  No propagation takes place in the case of a task body.  If the frame is a subprogram
     or a block statement and if it has dependent tasks, the propagation of an exception takes place only
     after termination of the dependent tasks.

     Finally, if an exception is raised in the sequence of statements of an exception handler, execution of
     this sequence of statements is abandoned.  Subsequent actions (including propagation, if any) are as in
     the cases (a) to (d) above, depending on the nature of the frame.

     6Example:

0         1function0 FACTORIAL (N : POSITIVE) 1return0 FLOAT 1is
0         1begin
0            1if0 N = 1 1then
0               1return0 1.0;
            1else
0               1return0 FLOAT(N) * FACTORIAL(N-1);
            1end0 1if0;
         1exception
0            1when0 NUMERIC_ERROR => return FLOAT'SAFE_LARGE;
         1end0 FACTORIAL;

     If the multiplication raises NUMERIC_ERROR, then FLOAT'SAFE_LARGE is returned by the handler.  This value
     will cause further NUMERIC_ERROR exceptions to be raised by the evaluation of the expression in each of
     the remaining invocations of the function, so that for large values of N the function will ultimately
     return the value FLOAT'SAFE_LARGE.

     6Example:
0         1procedure0 P 1is
0            ERROR : 1exception0;
            1procedure0 R;

            1procedure0 Q 1is
0            1begin
0               R;
               ...                    6--  error situation (2)
0            1exception
0               ...
               1when0 ERROR =>   6--  handler E2
0               ...
            end Q;

            1procedure0 R 1is
0            1begin
0               ...                    6--  error situation (3)
0            1end0 R;

         1begin
0            ...                       6--  error situation (1)
0            Q;
            ...
         1exception
0            ...
            1when0 ERROR =>      6--  handler E1
0            ...
         1end0 P;

     The following situations can arise:

        - If the exception ERROR is raised in the sequence of statements of the outer procedure P, the
          handler E1 provided within P is used to complete the execution of P.

        - If the exception ERROR is raised in the sequence of statements of Q, the handler E2 provided
          within Q is used to complete the execution of Q. Control will be returned to the point of call
          of Q upon completion of the handler.

        - If the exception ERROR is raised in the body of R, called by Q, the execution of R is abandoned
          and the same exception is raised in the body of Q. The handler E2 is then used to complete the
          execution of Q, as in situation (2).

     Note that in the third situation, the exception raised in R results in (indirectly) transferring control
     to a handler that is part of Q and hence not enclosed by R. Note also that if a handler were provided
     within R for the exception choice 1others,0 situation (3) would cause execution of this handler, rather
     than direct termination of R.

     Lastly, if ERROR had been declared in R, rather than in P, the handlers E1 and E2 could not provide an
     explicit handler for ERROR since this identifier would not be visible within the bodies of P and Q. In
     situation (3), the exception could however be handled in Q by providing a handler for the exception
     choice 1others.

0     6Notes:

0     The language does not define what happens when the execution of the main program is abandoned after an
     unhandled exception.

     The predefined exceptions are those that can be propagated by the basic operations and the predefined
     operators.

     The case of a frame that is a generic unit is already covered by the rules for subprogram and package
     bodies, since the sequence of statements of such a frame is not executed but is the template for the
     corresponding sequences of statements of the subprograms or packages obtained by generic instantiation.

     6References:0 4 accept statement 9.5, basic operation 3.3.3, block statement 5.6, body stub 10.2,
     completion 9.4, declarative item 3.9, declarative part 3.9, dependent task 9.4, elaboration 3.1 3.9,
     exception 11, exception handler 11.2, frame 11.2, generic instantiation 12.3, generic unit 12, library
     unit 10.1, main program 10.1, numeric_error exception 11.1, package 7, package body 7.1, predefined
     operator 4.5, procedure 6.1, sequence of statements 5.1, statement 5, subprogram 6, subprogram body 6.3,
     subprogram call 6.4, subunit 10.2, task 9, task body 9.1 0

      subsection lrm-section11-4-2



     711.4.2. Exceptions Raised During the Elaboration of Declarations

0     If an exception is raised during the elaboration of the declarative part of a given frame, this
     elaboration is abandoned.  The next action depends on the nature of the frame:

        - For a subprogram body, the same exception is raised again at the point of call of the
          subprogram, unless the subprogram is the main program itself, in which case execution of the
          main program is abandoned.

        - For a block statement, the same exception is raised again immediately after the block
          statement.

        - For a package body that is a declarative item, the same exception is raised again immediately
          after this declarative item, in the enclosing declarative part.  If the package body is that of
          a subunit, the exception is raised again at the place of the corresponding body stub.  If the
          package is a library unit, execution of the main program is abandoned.

        - For a task body, the task becomes completed, and the exception TASKING_ERROR is raised at the
          point of activation of the task, as explained in section 9.3.

     Similarly, if an exception is raised during the elaboration of either a package declaration or a task
     declaration, this elaboration is abandoned; the next action depends on the nature of the declaration.

        - For a package declaration or a task declaration, that is a declarative item, the exception is
          raised again immediately after the declarative item in the enclosing declarative part or
          package specification.  For the declaration of a library package, the execution of the main
          program is abandoned.

     An exception that is raised again (as in the above cases (a), (b), (c) and (e)) is said to be
     6propagated,0 either by the execution of the subprogram or block statement, or by the elaboration of
     the package declaration, task declaration or package body.

     6Example0 of an exception in the declarative part of a block statement (case (b)):

         1procedure0 P 1is
0            ...
         1begin
0            1declare
0               N : INTEGER := F;    6--  the function F may raise ERROR
0            1begin
0               ...
            exception
               1when0 ERROR =>     6--  handler E1
0            1end0;
            ...
         1exception
0            1when0 ERROR =>        6--  handler E2
0         1end0 P;

         6--  if the exception ERROR is raised in the declaration of N, it is handled by E2

0     6References:0 4 activation 9.3, block statement 5.6, body stub 10.2, completed task 9.4, declarative
     item 3.9, declarative part 3.9, elaboration 3.1 3.9, exception 11, frame 11.2, library unit 10.1, main
     program 10.1, package body 7.1, package declaration 7.1, package specification 7.1, subprogram 6,
     subprogram body 6.3, subprogram call 6.4, subunit 10.2, task 9, task body 9.1, task declaration 9.1,
     tasking_error exception 11.1 0

      section lrm-section11-5

     211.5. Exceptions Raised During Task Communication

0     An exception can be propagated to a task communicating, or attempting to communicate, with another task.
     An exception can also be propagated to a calling task if the exception is raised during a rendezvous.

     When a task calls an entry of another task, the exception TASKING_ERROR is raised in the calling task, at
     the place of the call, if the called task is completed before accepting the entry call or is already
     completed at the time of the call.

     A rendezvous can be completed abnormally in two cases:

        - When an exception is raised within an accept statement, but not handled within an inner frame.
          In this case, the execution of the accept statement is abandoned and the same exception is
          raised again immediately after the accept statement within the called task; the exception is
          also propagated to the calling task at the point of the entry call.

        - When the task containing the accept statement is completed abnormally as the result of an abort
          statement.  In this case, the exception TASKING_ERROR is raised in the calling task at the
          point of the entry call.

     On the other hand, if a task issuing an entry call becomes abnormal (as the result of an abort statement)
     no exception is raised in the called task.  If the rendezvous has not yet started, the entry call is
     cancelled.  If the rendezvous is in progress, it completes normally, and the called task is unaffected.

     6References:0 4 abnormal task 9.10, abort statement 9.10, accept statement 9.5, completed task 9.4,
     entry call 9.5, exception 11, frame 11.2, rendezvous 9.5, task 9, task termination 9.4, tasking_error
     exception 11.1 0

      section lrm-section11-6

     211.6. Exceptions and Optimization

0     The purpose of this section is to specify the conditions under which an implementation is allowed to
     perform certain actions either earlier or later than specified by other rules of the language.

     In general, when the language rules specify an order for certain actions (the 6canonical0 6order),
0     an implementation may only use an alternative order if it can guarantee that the effect of the program is
     not changed by the reordering.  In particular, no exception should arise for the execution of the
     reordered program if none arises for the execution of the program in the canonical order.  When, on the
     other hand, the order of certain actions is not defined by the language, any order can be used by the
     implementation.  (For example, the arguments of a predefined operator can be evaluated in any order since
     the rules given in section 4.5 do not require a specific order of evaluation.)

     Additional freedom is left to an implementation for reordering actions involving predefined operations
     that are either predefined operators or basic operations other than assignments.  This freedom is left,
     as defined below, even in the case where the execution of these predefined operations may propagate a
     (predefined) exception:

        - For the purpose of establishing whether the same effect is obtained by the execution of certain
          actions in the canonical and in an alternative order, it can be assumed that none of the
          predefined operations invoked by these actions propagates a (predefined) exception, provided
          that the two following requirements are met by the alternative order:  first, an operation must
          not be invoked in the alternative order if it is not invoked in the canonical order; second,
          for each operation, the innermost enclosing frame or accept statement must be the same in the
          alternative order as in the canonical order, and the same exception handlers must apply.

        - Within an expression, the association of operators with operands is specified by the syntax.
          However, for a sequence of predefined operators of the same precedence level (and in the
          absence of parentheses imposing a specific association), any association of operators with
          operands is allowed if it satisfies the following requirement:  an integer result must be equal
          to that given by the canonical left-to-right order; a real result must belong to the result
          model interval defined for the canonical left-to-right order (see 4.5.7).  Such a reordering is
          allowed even if it may remove an exception, or introduce a further predefined exception.

     Similarly, additional freedom is left to an implementation for the evaluation of numeric simple
     expressions.  For the evaluation of a predefined operation, an implementation is allowed to use the
     operation of a type that has a range wider than that of the base type of the operands, provided that this
     delivers the exact result (or a result within the declared accuracy, in the case of a real type), even if
     some intermediate results lie outside the range of the base type.  The exception NUMERIC_ERROR need not
     be raised in such a case.  In particular, if the numeric expression is an operand of a predefined
     relational operator, the exception NUMERIC_ERROR need not be raised by the evaluation of the relation,
     provided that the correct BOOLEAN result is obtained.

     A predefined operation need not be invoked at all, if its only possible effect is to propagate a
     predefined exception.  Similarly, a predefined operation need not be invoked if the removal of subsequent
     operations by the above rule renders this invocation ineffective.

     6Notes:

0     Rule (b) applies to predefined operators but not to the short-circuit control forms.

     The expression SPEED < 300_000.0 can be replaced by TRUE if the value 300_000.0 lies outside the base
     type of SPEED, even though the implicit conversion of the numeric literal would raise the exception
     NUMERIC_ERROR.

     6Example:

0         1declare
0            N : INTEGER;
         1begin
0            N := 0;                  --  (1)
            1for0 J 1in0 1 .. 10 1loop
0               N := N + J**A(K);   6--  A and K are global variables
0            1end0 1loop0;
            PUT(N);
         1exception
0            1when0 1OTHERS0 => PUT("SOME ERROR AROSE"); PUT(N);
         1end0;

     The evaluation of A(K) may be performed before the loop, and possibly immediately before the assignment
     statement (1) even if this evaluation can raise an exception.  Consequently, within the exception
     handler, the value of N is either the undefined initial value or a value later assigned.  On the other
     hand, the evaluation of A(K) cannot be moved before 1begin0 since an exception would then be handled by
     a different handler.  For this reason, the initialization of N in the declaration itself would exclude
     the possibility of having an undefined initial value of N in the handler.

     6References:0 4 accept statement 9.5, accuracy of real operations 4.5.7, assignment 5.2, base type
     3.3, basic operation 3.3.3, conversion 4.6, error situation 11, exception 11, exception handler 11.2,
     frame 11.2, numeric_error exception 11.1, predefined operator 4.5, predefined subprogram 8.6, propagation
     of an exception 11.4, real type 3.5.6, undefined value 3.2.1 0

      section lrm-section11-7

     211.7. Suppressing Checks

0     The presence of a SUPPRESS pragma gives permission to an implementation to omit certain run-time checks.
     The form of this pragma is as follows:

         1pragma0 SUPPRESS(identifier [, [ON =>] name]);

     The identifier is that of the check that can be omitted.  The name (if present) must be either a simple
     name or an expanded name and it must denote either an object, a type or subtype, a task unit, or a
     generic unit; alternatively the name can be a subprogram name, in which case it can stand for several
     visible overloaded subprograms.

     A pragma SUPPRESS is only allowed immediately within a declarative part or immediately within a package
     specification.  In the latter case, the only allowed form is with a name that denotes an entity (or
     several overloaded subprograms) declared immediately within the package specification.  The permission to
     omit the given check extends from the place of the pragma to the end of the declarative region associated
     with the innermost enclosing block statement or program unit.  For a pragma given in a package
     specification, the permission extends to the end of the scope of the named entity.

     If the pragma includes a name, the permission to omit the given check is further restricted:  it is given
     only for operations on the named object or on all objects of the base type of a named type or subtype;
     for calls of a named subprogram; for activations of tasks of the named task type; or for instantiations
     of the given generic unit.

     The following checks correspond to situations in which the exception CONSTRAINT_ERROR may be raised; for
     these checks, the name (if present) must denote either an object or a type.

     ACCESS_CHECK        When accessing a selected component, an indexed component, a slice, or an attribute,
                           of an object designated by an access value, check that the access value is not null.

     DISCRIMINANT_CHECK  Check that a discriminant of a composite value has the value imposed by a
                           discriminant constraint.  Also, when accessing a record component, check that it
                           exists for the current discriminant values.

     INDEX_CHECK       Check that the bounds of an array value are equal to the corresponding bounds of an
                         index constraint.  Also, when accessing a component of an array object, check for
                         each dimension that the given index value belongs to the range defined by the bounds
                         of the array object.  Also, when accessing a slice of an array object, check that the
                         given discrete range is compatible with the range defined by the bounds of the array
                         object.

     LENGTH_CHECK        Check that there is a matching component for each component of an array, in the case
                         of array assignments, type conversions, and logical operators for arrays of boolean
                         components.

     RANGE_CHECK         Check that a value satisfies a range constraint.  Also, for the elaboration of a
                         subtype indication, check that the constraint (if present) is compatible with the
                         type mark.  Also, for an aggregate, check that an index or discriminant value belongs
                         to the corresponding subtype.  Finally, check for any constraint checks performed by
                         a generic instantiation.

     The following checks correspond to situations in which the exception NUMERIC_ERROR is raised.  The only
     allowed names in the corresponding pragmas are names of numeric types.

     DIVISION_CHECK      Check that the second operand is not zero for the operations /, 1rem0 and 1mod.

0     OVERFLOW_CHECK      Check that the result of a numeric operation does not overflow.

     The following check corresponds to situations in which the exception PROGRAM_ERROR is raised.  The only
     allowed names in the corresponding pragmas are names denoting task units, generic units, or subprograms.

     ELABORATION_CHECK   When either a subprogram is called, a task activation is accomplished, or a generic
                         instantiation is elaborated, check that the body of the corresponding unit has
                         already been elaborated.

     The following check corresponds to situations in which the exception STORAGE_ERROR is raised.  The only
     allowed names in the corresponding pragmas are names denoting access types, task units, or subprograms.

     STORAGE_CHECK       Check that execution of an allocator does not require more space than is available
                         for a collection.  Check that the space available for a task or subprogram has not
                         been exceeded.

     If an error situation arises in the absence of the corresponding run-time checks, the execution of the
     program is erroneous (the results are not defined by the language).

     6Examples:

0         1pragma0 SUPPRESS(RANGE_CHECK);
         1pragma0 SUPPRESS(INDEX_CHECK, ON => TABLE);

     6Notes:

0     For certain implementations, it may be impossible or too costly to suppress certain checks.  The
     corresponding SUPPRESS pragma can be ignored.  Hence, the occurrence of such a pragma within a given unit
     does not guarantee that the corresponding exception will not arise; the exceptions may also be propagated
     by called units.

     6References:0 4 

0     access type 3.8, access value 3.8, activation 9.3, aggregate 4.3, allocator 4.8, array 3.6, attribute
     4.1.4, block statement 5.6, collection 3.8, compatible 3.3.2, component of an array 3.6, component of a
     record 3.7, composite type 3.3, constraint 3.3, constraint_error exception 11.1, declarative part 3.9,
     designate 3.8, dimension 3.6, discrete range 3.6, discriminant 3.7.1, discriminant constraint 3.7.2,
     elaboration 3.1 3.9, erroneous 1.6, error situation 11, expanded name 4.1.3, generic body 11.1, generic
     instantiation 12.3, generic unit 12, identifier 2.3, index 3.6, index constraint 3.6.1, indexed component
     4.1.1, null access value 3.8, numeric operation 3.5.5 3.5.8 3.5.10, numeric type 3.5, numeric_error
     exception 11.1, object 3.2, operation 3.3.3, package body 7.1, package specification 7.1, pragma 2.8,
     program_error exception 11.1, program unit 6, propagation of an exception 11.4, range constraint 3.5,
     record type 3.7, simple name 4.1, slice 4.1.2, subprogram 6, subprogram body 6.3, subprogram call 6.4,
     subtype 3.3, subunit 10.2, task 9, task body 9.1, task type 9.1, task unit 9, type 3.3, type mark 3.3.2

      chapter lrm-chapter-12



                                                 112. Generic Units

0     A generic unit is a program unit that is either a generic subprogram or a generic package.  A generic
     unit is a 6template0, which is parameterized or not, and from which corresponding (nongeneric)
     subprograms or packages can be obtained.  The resulting program units are said to be 6instances0 of the
     original generic unit.

     A generic unit is declared by a generic declaration.  This form of declaration has a generic formal part
     declaring any generic formal parameters.  An instance of a generic unit is obtained as the result of a
     generic instantiation with appropriate generic actual parameters for the generic formal parameters.  An
     instance of a generic subprogram is a subprogram.  An instance of a generic package is a package.

     Generic units are templates.  As templates they do not have the properties that are specific to their
     nongeneric counterparts.  For example, a generic subprogram can be instantiated but it cannot be called.
     In contrast, the instance of a generic subprogram is a nongeneric subprogram; hence, this instance can be
     called but it cannot be used to produce further instances.

     6References:0 4 declaration 3.1, generic actual parameter 12.3, generic declaration 12.1, generic
     formal parameter 12.1, generic formal part 12.1, generic instantiation 12.3, generic package 12.1,
     generic subprogram 12.1, instance 12.3, package 7, program unit 6, subprogram 6 0

      section lrm-section12-1

     212.1. Generic Declarations

0     A generic declaration declares a generic unit, which is either a generic subprogram or a generic package.
     A generic declaration includes a generic formal part declaring any generic formal parameters.  A generic
     formal parameter can be an object; alternatively (unlike a parameter of a subprogram), it can be a type
     or a subprogram.

         generic_declaration ::= generic_specification;

         generic_specification ::=
                generic_formal_part subprogram_specification
            |   generic_formal_part package_specification

         generic_formal_part ::= 1generic0 {generic_parameter_declaration}

         generic_parameter_declaration ::=
                identifier_list : [1in0 [1out0]] type_mark [:= expression];
            |   1type0 identifier 1is0 generic_type_definition;
            |   private_type_declaration
            |   1with0 subprogram_specification [1is0 name];
            |   1with0 subprogram_specification [1is0 <>];

         generic_type_definition ::=
                (<>) | 1range0 <> | 1digits0 <> | 1delta0 <>
            |   array_type_definition | access_type_definition


     The terms generic formal object (or simply, 6formal0 6object0), generic formal type (or simply,
     6formal0 6type0), and generic formal subprogram (or simply, 6formal0 6subprogram0) are used to
     refer to corresponding generic formal parameters.

     The only form of subtype indication allowed within a generic formal part is a type mark (that is, the
     subtype indication must not include an explicit constraint).  The designator of a generic subprogram must
     be an identifier.

     Outside the specification and body of a generic unit, the name of this program unit denotes the generic
     unit.  In contrast, within the declarative region associated with a generic subprogram, the name of this
     program unit denotes the subprogram obtained by the current instantiation of the generic unit.
     Similarly, within the declarative region associated with a generic package, the name of this program unit
     denotes the package obtained by the current instantiation.

     The elaboration of a generic declaration has no other effect.

     6Examples0 6of0 6generic0 6formal0 6parts:

0         1generic0     6--  parameterless

0         1generic
0            SIZE : NATURAL;  6--  formal object

0         1generic
0            LENGTH    : INTEGER := 200;               6-- formal object with a default expression
0            AREA   : INTEGER := LENGTH*LENGTH;   6-- formal object with a default expression

0         1generic
0            1type0 ITEM   1is0 1private0;                                 6-- formal type
0            1type0 INDEX  1IS0 (<>);                                     6-- formal type
0            1type0 ROW    1is0 1array0(INDEX 1range0 <>) of ITEM;     6-- formal type
0            1with0 1function0 "<"(X, Y : ITEM) 1return0 BOOLEAN;    6-- formal subprogram

0     6Examples0 6of0 6generic0 6declarations0 6declaring0 6generic0 6subprograms:

0         1generic
0            1type0 ELEM 1is0 1private0;
         1procedure0 EXCHANGE(U, V : 1in0 1out0 ELEM);

         1generic
0            1type0 ITEM 1is0 1private0;
            1with0 1function0 "*"(U, V : ITEM) 1return0 ITEM 1IS0 <>;
         1function0 SQUARING(X : ITEM) 1return0 ITEM;

     6Example0 6of0 6a0 6generic0 6declaration0 6declaring0 6a0 6generic0 6package:

0         1generic
0            1type0 ITEM   1is0 1private0;
            1type0 VECTOR    1is0 1array0 (POSITIVE 1RANGE0 <>) of ITEM;
            1with0 1function0 SUM(X, Y : ITEM) 1return0 ITEM;
         1package0 ON_VECTORS 1is
0            1function0 SUM  (A, B  : VECTOR) 1return0 VECTOR;
            1function0 SIGMA   (A  : VECTOR) 1return0 ITEM;
            LENGTH_ERROR : 1exception0;
         1end0;


     6Notes:

0     Within a generic subprogram, the name of this program unit acts as the name of a subprogram.  Hence this
     name can be overloaded, and it can appear in a recursive call of the current instantiation.  For the same
     reason, this name cannot appear after the reserved word 1new0 in a (recursive) generic instantiation.

     An expression that occurs in a generic formal part is either the default expression for a generic formal
     object of mode 1in0, or a constituent of an entry name given as default name for a formal subprogram,
     or the default expression for a parameter of a formal subprogram.  Default expressions for generic formal
     objects and default names for formal subprograms are only evaluated for generic instantiations that use
     such defaults.  Default expressions for parameters of formal subprograms are only evaluated for calls of
     the formal subprograms that use such defaults.  (The usual visibility rules apply to any name used in a
     default expression:  the denoted entity must therefore be visible at the place of the expression.)

     Neither generic formal parameters nor their attributes are allowed constituents of static expressions
     (see 4.9).

     6References:0 4 access type definition 3.8, array type definition 3.6, attribute 4.1.4, constraint
     3.3, declaration 3.1, designator 6.1, elaboration has no other effect 3.1, entity 3.1, expression 4.4,
     function 6.5, generic instantiation 12.3, identifier 2.3, identifier list 3.2, instance 12.3, name 4.1,
     object 3.2, overloading 6.6 8.7, package specification 7.1, parameter of a subprogram 6.2, private type
     definition 7.4, procedure 6.1, reserved word 2.9, static expression 4.9, subprogram 6, subprogram
     specification 6.1, subtype indication 3.3.2, type 3.3, type mark 3.3.2 0

      subsection lrm-section12-1-1



     712.1.1. Generic Formal Objects

0     The first form of generic parameter declaration declares generic formal objects.  The type of a generic
     formal object is the base type of the type denoted by the type mark given in the generic parameter
     declaration.  A generic parameter declaration with several identifiers is equivalent to a sequence of
     single generic parameter declarations, as explained in section 3.2.

     A generic formal object has a mode that is either 1in0 or 1in0 1out0.  In the absence of an
     explicit mode indication in a generic parameter declaration, the mode 1in0 is assumed; otherwise the
     mode is the one indicated.  If a generic parameter declaration ends with an expression, the expression is
     the 6default0 6expression0 of the generic formal parameter.  A default expression is only allowed if
     the mode is 1in0 (whether this mode is indicated explicitly or implicitly).  The type of a default
     expression must be that of the corresponding generic formal parameter.

     A generic formal object of mode 1in0 is a constant whose value is a copy of the value supplied as the
     matching generic actual parameter in a generic instantiation, as described in section 12.3.  The type of
     a generic formal object of mode 1in0 must not be a limited type; the subtype of such a generic formal
     object is the subtype denoted by the type mark given in the generic parameter declaration.

     A generic formal object of mode 1in0 1out0 is a variable and denotes the object supplied as the
     matching generic actual parameter in a generic instantiation, as described in section 12.3.  The
     constraints that apply to the generic formal object are those of the corresponding generic actual
     parameter.

     6Note:

0     The constraints that apply to a generic formal object of mode 1in0 1out0 are those of the
     corresponding generic actual parameter (not those implied by the type mark that appears in the generic
     parameter declaration).  Whenever possible (to avoid confusion) it is recommended that the name of a base
     type be used for the declaration of such a formal object.  If, however, the base type is anonymous, it is
     recommended that the subtype name defined by the type declaration for the base type be used.

     6References:0 4 anonymous type 3.3.1, assignment 5.2, base type 3.3, constant declaration 3.2,
     constraint 3.3, declaration 3.1, generic actual parameter 12.3, generic formal object 12.1, generic
     formal parameter 12.1, generic instantiation 12.3, generic parameter declaration 12.1, identifier 2.3,
     limited type 7.4.4, matching generic actual parameter 12.3, mode 6.1, name 4.1, object 3.2, simple name
     4.1, subtype 3.3, type declaration 3.3, type mark 3.3.2, variable 3.2.1 0

      subsection lrm-section12-1-2



     712.1.2. Generic Formal Types

0     A generic parameter declaration that includes a generic type definition or a private type declaration
     declares a generic formal type.  A generic formal type denotes the subtype supplied as the corresponding
     actual parameter in a generic instantiation, as described in 12.3(d).  However, within a generic unit, a
     generic formal type is considered as being distinct from all other (formal or nonformal) types.  The form
     of constraint applicable to a formal type in a subtype indication depends on the class of the type as for
     a nonformal type.

     The only form of discrete range that is allowed within the declaration of a generic formal (constrained)
     array type is a type mark.

     The discriminant part of a generic formal private type must not include a default expression for a
     discriminant.  (Consequently, a variable that is declared by an object declaration must be constrained if
     its type is a generic formal type with discriminants.)

     Within the declaration and body of a generic unit, the operations available for values of a generic
     formal type (apart from any additional operation specified by a generic formal subprogram) are determined
     by the generic parameter declaration for the formal type:

        - For a private type declaration, the available operations are those defined in section 7.4.2 (in
          particular, assignment, equality, and inequality are available for a private type unless it is
          limited).

        - For an array type definition, the available operations are those defined in section 3.6.2 (for
          example, they include the formation of indexed components and slices).

        - For an access type definition, the available operations are those defined in section 3.8.2 (for
          example, allocators can be used).

     The four forms of generic type definition in which a 6box0 appears (that is, the compound delimiter <>)
     correspond to the following major forms of scalar type:

        - Discrete types:  (<>)

        - The available operations are the operations common to enumeration and integer types; these are
          defined in section 3.5.5.

        - Integer types:  1range0 <>

        - The available operations are the operations of integer types defined in section 3.5.5.

        - Floating point types:  1digits0 <>

        - The available operations are those defined in section 3.5.8.

        - Fixed point types:  1delta0 <>

        - The available operations are those defined in section 3.5.10.

     In all of the above cases (a) through (f), each operation implicitly associated with a formal type (that
     is, other than an operation specified by a formal subprogram) is implicitly declared at the place of the
     declaration of the formal type.  The same holds for a formal fixed point type, except for the multiplying
     operators that deliver a result of the type 6universal0_6fixed0 (see 4.5.5), since these special
     operators are declared in the package STANDARD.

     For an instantiation of the generic unit, each of these operations is the corresponding basic operation
     or predefined operator of the matching actual type.  For an operator, this rule applies even if the
     operator has been redefined for the actual type or for some parent type of the actual type.

     6Examples0 6of0 6generic0 6formal0 6types:

0         1type0 ITEM 1is0 1private0;
         1type0 BUFFER(LENGTH : NATURAL) 1is0 1limited0 1private0;

         1type0 ENUM   1is0 (<>);
         1type0 INT    1is0 1range0 <>;
         1type0 ANGLE  1is0 1delta0 <>;
         1type0 MASS   1is0 1digits0 <>;

         1type0 TABLE 1is0 1array0 (ENUM) 1of0 ITEM;


     6Example0 6of0 6a0 6generic0 6formal0 6part0 6declaring0 6a0 6formal0 6integer
0     6type:

0         1generic
0            1type0 RANK 1is0 1RANGE0 <>;
            FIRST  : RANK := RANK'FIRST;
            SECOND    : RANK := FIRST + 1;  6--  the operator "+" of the type RANK


0     6References:0 4 access type definition 3.8, allocator 4.8, array type definition 3.6, assignment 5.2,
     body of a generic unit 12.2, class of type 3.3, constraint 3.3, declaration 3.1, declaration of a generic
     unit 12.1, discrete range 3.6, discrete type 3.5, discriminant part 3.7.1, enumeration type 3.5.1,
     equality 4.5.2, fixed point type 3.5.9, floating point type 3.5.7, generic actual type 12.3, generic
     formal part 12.1, generic formal subprogram 12.1.3, generic formal type 12.1, generic parameter
     declaration 12.1, generic type definition 12.1, indexed component 4.1.1, inequality 4.5.2, instantiation
     12.3, integer type 3.5.4, limited private type 7.4.4, matching generic actual type 12.3.2 12.3.3 12.3.4
     12.3.5, multiplying operator 4.5 4.5.5, operation 3.3, operator 4.5, parent type 3.4, private type
     definition 7.4, scalar type 3.5, slice 4.1.2, standard package 8.6 C, subtype indication 3.3.2, type mark
     3.3.2, universal_fixed 3.5.9 0

      subsection lrm-section12-1-3



     712.1.3. Generic Formal Subprograms

0     A generic parameter declaration that includes a subprogram specification declares a generic formal
     subprogram.

     Two alternative forms of defaults can be specified in the declaration of a generic formal subprogram.  In
     these forms, the subprogram specification is followed by the reserved word 1is0 and either a box or the
     name of a subprogram or entry.  The matching rules for these defaults are explained in section 12.3.6.

     A generic formal subprogram denotes the subprogram, enumeration literal, or entry supplied as the
     corresponding generic actual parameter in a generic instantiation, as described in section 12.3(f).

     6Examples0 6of0 6generic0 6formal0 6subprograms:

0         1with0 1function0 INCREASE(X : INTEGER) 1return0 INTEGER;
         1with0 1function0 SUM(X, Y : ITEM) 1return0 ITEM;

         1with0 1function0 "+"(X, Y : ITEM) 1return0 ITEM 1IS0 <>;
         1with0 1function0 IMAGE(X : ENUM) 1return0 STRING 1is0 ENUM'IMAGE;

         1with0 1procedure0 UPDATE 1is0 DEFAULT_UPDATE;

     6Notes:

0     The constraints that apply to a parameter of a formal subprogram are those of the corresponding parameter
     in the specification of the matching actual subprogram (not those implied by the corresponding type mark
     in the specification of the formal subprogram).  A similar remark applies to the result of a function.
     Whenever possible (to avoid confusion), it is recommended that the name of a base type be used rather
     than the name of a subtype in any declaration of a formal subprogram.  If, however, the base type is
     anonymous, it is recommended that the subtype name defined by the type declaration be used.

     The type specified for a formal parameter of a generic formal subprogram can be any visible type,
     including a generic formal type of the same generic formal part.

     6References:0 4 anonymous type 3.3.1, base type 3.3, box delimiter 12.1.2, constraint 3.3, designator
     6.1, generic actual parameter 12.3, generic formal function 12.1, generic formal subprogram 12.1, generic
     instantiation 12.3, generic parameter declaration 12.1, identifier 2.3, matching generic actual
     subprogram 12.3.6, operator symbol 6.1, parameter of a subprogram 6.2, renaming declaration 8.5, reserved
     word 2.9, scope 8.2, subprogram 6, subprogram specification 6.1, subtype 3.3.2, type 3.3, type mark 3.3.2
     0

      section lrm-section12-2

     212.2. Generic Bodies

0     The body of a generic subprogram or generic package is a template for the bodies of the corresponding
     subprograms or packages obtained by generic instantiations.  The syntax of a generic body is identical to
     that of a nongeneric body.

     For each declaration of a generic subprogram, there must be a corresponding body.

     The elaboration of a generic body has no other effect than to establish that the body can from then on be
     used as the template for obtaining the corresponding instances.

     6Example0 6of0 6a0 6generic0 6procedure0 6body:

0         1procedure0 EXCHANGE(U, V : 1in0 1out0 ELEM) IS   6--  see example in 12.1
0            T : ELEM;  6--  the generic formal type
0         1begin
0            T := U;
            U := V;
            V := T;
         1end0 EXCHANGE;


     6Example0 6of0 6a0 6generic0 6function0 6body:

0         1function0 SQUARING(X : ITEM) 1return0 ITEM IS   6--  see example in 12.1
0         1begin
0            1return0 X*X;  6--  the formal operator "*"
0         1end0;


     6Example0 6of0 6a0 6generic0 6package0 6body:

0         1package0 1body0 ON_VECTORS 1is0                 6--  see example in 12.1

0            1function0 SUM(A, B : VECTOR) 1return0 VECTOR 1is
0               RESULT    : VECTOR(A'RANGE);          6--  the formal type VECTOR
0               BIAS   : 1constant0 INTEGER := B'FIRST - A'FIRST;
            1begin
0               1if0 A'LENGTH /= B'LENGTH 1then
0                  1raise0 LENGTH_ERROR;
               1end0 1if0;

               1for0 N 1in0 A'RANGE 1loop
0                  RESULT(N) := SUM(A(N), B(N + BIAS)); 6--  the formal function SUM
0               1end0 1loop0;
               1return0 RESULT;
            1end0;

            1function0 SIGMA(A : VECTOR) 1return0 ITEM 1is
0               TOTAL : ITEM := A(A'FIRST);              6--  the formal type ITEM
0            1begin
0               1for0 N 1in0 A'FIRST + 1 .. A'LAST 1loop
0                  TOTAL := SUM(TOTAL, A(N));         6--  the formal function SUM
0               1end0 1loop0;
               1return0 TOTAL;
            1end0;
         1end0;


     6References:0 4 body 3.9, elaboration 3.9, generic body 12.1, generic instantiation 12.3, generic
     package 12.1, generic subprogram 12.1, instance 12.3, package body 7.1, package 7, subprogram 6,
     subprogram body 6.3 0

      section lrm-section12-3

     212.3. Generic Instantiation

0     An instance of a generic unit is declared by a generic instantiation.

         generic_instantiation ::=
                1package0 identifier 1is
0                  1new0 6generic0_6package0_name [generic]_6actual0_6part0;
            |   1procedure0 identifier 1is
0                  1new0 6generic0_6procedure0_name [generic]_6actual0_6part0;
            |   1function0 designator 1is
0                  1new0 6generic0_6function0_name [generic]_6actual0_6part0;

         generic_actual_part ::=
            (generic_association {, generic_association})

         generic_association ::=
            [generic_formal_parameter =>] generic_actual_parameter

         generic_formal_parameter ::= 6parameter0_simple_name | operator_symbol

         generic_actual_parameter ::= expression | 6variable0_name
            | 6subprogram0_name | 6entry0_name | type_mark

     An explicit generic actual parameter must be supplied for each generic formal parameter, unless the
     corresponding generic parameter declaration specifies that a default can be used.  Generic associations
     can be either positional or named in the same manner as parameter associations of subprogram calls (see
     6.4).  If two or more formal subprograms have the same designator, then named associations are not
     allowed for the corresponding generic parameters.

     Each generic actual parameter must 6match0 the corresponding generic formal parameter.  An expression
     can match a formal object of mode 1in0; a variable name can match a formal object of mode 1in
0     1out0; a subprogram name or an entry name can match a formal subprogram; a type mark can match a formal
     type.  The detailed rules defining the allowed matches are given in sections 12.3.1 to 12.3.6; these are
     the only allowed matches.

     The instance is a copy of the generic unit, apart from the generic formal part; thus the instance of a
     generic package is a package, that of a generic procedure is a procedure, and that of a generic function
     is a function.  For each occurrence, within the generic unit, of a name that denotes a given entity, the
     following list defines which entity is denoted by the corresponding occurrence within the instance.

        - For a name that denotes the generic unit:  The corresponding occurrence denotes the instance.

        - For a name that denotes a generic formal object of mode 1in:0 The corresponding name denotes
          a constant whose value is a copy of the value of the associated generic actual parameter.

        - For a name that denotes a generic formal object of mode 1in0 1out:0 The corresponding name
          denotes the variable named by the associated generic actual parameter.

        - For a name that denotes a generic formal type:  The corresponding name denotes the subtype
          named by the associated generic actual parameter (the actual subtype).

        - For a name that denotes a discriminant of a generic formal type:  The corresponding name
          denotes the corresponding discriminant (there must be one) of the actual type associated with
          the generic formal type.

        - For a name that denotes a generic formal subprogram:  The corresponding name denotes the
          subprogram, enumeration literal, or entry named by the associated generic actual parameter (the
          actual subprogram).

        - For a name that denotes a formal parameter of a generic formal subprogram:  The corresponding
          name denotes the corresponding formal parameter of the actual subprogram associated with the
          formal subprogram.

        - For a name that denotes a local entity declared within the generic unit:  The corresponding
          name denotes the entity declared by the corresponding local declaration within the instance.

        - For a name that denotes a global entity declared outside of the generic unit:  The
          corresponding name denotes the same global entity.

     Similar rules apply to operators and basic operations:  in particular, formal operators follow a rule
     similar to rule (f), local operations follow a rule similar to rule (h), and operations for global types
     follow a rule similar to rule (i).  In addition, if within the generic unit a predefined operator or
     basic operation of a formal type is used, then within the instance the corresponding occurrence refers to
     the corresponding predefined operation of the actual type associated with the formal type.

     The above rules apply also to any type mark or (default) expression given within the generic formal part
     of the generic unit.

     For the elaboration of a generic instantiation, each expression supplied as an explicit generic actual
     parameter is first evaluated, as well as each expression that appears as a constituent of a variable name
     or entry name supplied as an explicit generic actual parameter; these evaluations proceed in some order
     that is not defined by the language.  Then, for each omitted generic association (if any), the
     corresponding default expression or default name is evaluated; such evaluations are performed in the
     order of the generic parameter declarations.  Finally, the implicitly generated instance is elaborated.
     The elaboration of a generic instantiation may also involve certain constraint checks as described in
     later subsections.

     Recursive generic instantiation is not allowed in the following sense:  if a given generic unit includes
     an instantiation of a second generic unit, then the instance generated by this instantiation must not
     include an instance of the first generic unit (whether this instance is generated directly, or indirectly
     by intermediate instantiations).

     6Examples0 6of0 6generic0 6instantiations0 (see 12.1):

         1procedure0   SWAP  1is0 1new0 EXCHANGE   (ELEM => INTEGER);
         1procedure0   SWAP  1is0 1new0 EXCHANGE   (CHARACTER);     6--  SWAP is overloaded

0         1function0    SQUARE 1is0 1new0 SQUARING(INTEGER); 6--  "*" of INTEGER used by default
0         1function0    SQUARE 1is0 1new0 SQUARING  (ITEM => MATRIX, "*" => MATRIX_PRODUCT);
         1function0    SQUARE 1is0 1new0 SQUARING  (MATRIX, MATRIX_PRODUCT); 6-- Same as previous

0         1package0 INT_VECTORS 1is0 1new0 ON_VECTORS(INTEGER, TABLE, "+");

     6Examples0 6of0 6uses0 6of0 6instantiated0 6units:

0         SWAP(A, B);
         A := SQUARE(A);

         T   : TABLE(1 .. 5) := (10, 20, 30, 40, 50);
         N   : INTEGER := INT_VECTORS.SIGMA(T);  6--  150 (see 12.2 for the body of SIGMA)

0         1use0 INT_VECTORS;
         M : INTEGER := SIGMA(T);  6--  150


0     6Notes:

0     Omission of a generic actual parameter is only allowed if a corresponding default exists.  If default
     expressions or default names (other than simple names) are used, they are evaluated in the order in which
     the corresponding generic formal parameters are declared.

     If two overloaded subprograms declared in a generic package specification differ only by the (formal)
     type of their parameters and results, then there exist legal instantiations for which all calls of these
     subprograms from outside the instance are ambiguous.  For example:

         1generic
0            1type0 A 1IS0 (<>);
            1type0 B 1is0 1private0;
         1package0 G 1is
0            1function0 NEXT(X : A)    1return0 A;
            1function0 NEXT(X : B)    1return0 B;
         1end0;

         1package0 P 1is0 1new0 G(A => BOOLEAN, B => BOOLEAN);
         -- calls of P.NEXT are ambiguous

     6References:0 4 declaration 3.1, designator 6.1, discriminant 3.7.1, elaboration 3.1 3.9, entity 3.1,
     entry name 9.5, evaluation 4.5, expression 4.4, generic formal object 12.1, generic formal parameter
     12.1, generic formal subprogram 12.1, generic formal type 12.1, generic parameter declaration 12.1,
     global declaration 8.1, identifier 2.3, implicit declaration 3.1, local declaration 8.1, mode in 12.1.1,
     mode in out 12.1.1, name 4.1, operation 3.3, operator symbol 6.1, overloading 6.6 8.7, package 7, simple
     name 4.1, subprogram 6, subprogram call 6.4, subprogram name 6.1, subtype declaration 3.3.2, type mark
     3.3.2, variable 3.2.1, visibility 8.3 0

      subsection lrm-section12-3-1



     712.3.1. Matching Rules for Formal Objects

0     A generic formal parameter of mode 1in0 of a given type is matched by an expression of the same type.
     If a generic unit has a generic formal object of mode 1in0, a check is made that the value of the
     expression belongs to the subtype denoted by the type mark, as for an explicit constant declaration (see
     3.2.1). The exception CONSTRAINT_ERROR is raised if this check fails.

     A generic formal parameter of mode 1in0 1out0 of a given type is matched by the name of a variable of
     the same type.  The variable must not be a formal parameter of mode 1out0 or a subcomponent thereof.
     The name must denote a variable for which renaming is allowed (see 8.5).

     6Notes:

0     The type of a generic actual parameter of mode 1in0 must not be a limited type.  The constraints that
     apply to a generic formal parameter of mode 1in0 1out0 are those of the corresponding generic actual
     parameter (see 12.1.1).

     6References:0 4 constraint 3.3, constraint_error exception 11.1, expression 4.4, formal parameter 6.1,
     generic actual parameter 12.3, generic formal object 12.1.1, generic formal parameter 12.1, generic
     instantiation 12.3, generic unit 12.1, limited type 7.4.4, matching generic actual parameter 12.3, mode
     in 12.1.1, mode in out 12.1.1, mode out 6.2, name 4.1, raising of exceptions 11, satisfy 3.3,
     subcomponent 3.3, type 3.3, type mark 3.3.2, variable 3.2.1 0

      subsection lrm-section12-3-2



     712.3.2. Matching Rules for Formal Private Types

0     A generic formal private type is matched by any type or subtype (the actual subtype) that satisfies the
     following conditions:

        - If the formal type is not limited, the actual type must not be a limited type.  (If, on the
          other hand, the formal type is limited, no such condition is imposed on the corresponding
          actual type, which can be limited or not limited.)

        - If the formal type has a discriminant part, the actual type must be a type with the same number
          of discriminants; the type of a discriminant that appears at a given position in the
          discriminant part of the actual type must be the same as the type of the discriminant that
          appears at the same position in the discriminant part of the formal type; and the actual
          subtype must be unconstrained.  (If, on the other hand, the formal type has no discriminants,
          the actual type is allowed to have discriminants.)

     Furthermore, consider any occurrence of the name of the formal type at a place where this name is used as
     an unconstrained subtype indication.  The actual subtype must not be an unconstrained array type or an
     unconstrained type with discriminants, if any of these occurrences is at a place where either a
     constraint or default discriminants would be required for an array type or for a type with discriminants
     (see 3.6.1 and 3.7.2).  The same restriction applies to occurrences of the name of a subtype of the
     formal type, and to occurrences of the name of any type or subtype derived, directly or indirectly, from
     the formal type.

     If a generic unit has a formal private type with discriminants, the elaboration of a corresponding
     generic instantiation checks that the subtype of each discriminant of the actual type is the same as the
     subtype of the corresponding discriminant of the formal type.  The exception CONSTRAINT_ERROR is raised
     if this check fails.

     6References:0 4 array type 3.6, constraint 3.3, constraint_error exception 11.1, default expression
     for a discriminant 3.7.1, derived type 3.4, discriminant 3.7.1, discriminant part 3.7.1, elaboration 3.9,
     generic actual type 12.3, generic body 12.2, generic formal type 12.1.2, generic instantiation 12.3,
     generic specification 12.1, limited type 7.4.4, matching generic actual parameter 12.3, name 4.1, private
     type 7.4, raising of exceptions 11, subtype 3.3, subtype indication 3.3.2, type 3.3, type with
     discriminants 3.3, unconstrained array type 3.6, unconstrained subtype 3.3 0

      subsection lrm-section12-3-3



     712.3.3. Matching Rules for Formal Scalar Types

0     A generic formal type defined by (<>) is matched by any discrete subtype (that is, any enumeration or
     integer subtype).  A generic formal type defined by 1range0 <> is matched by any integer subtype.  A
     generic formal type defined by 1digits0 <> is matched by any floating point subtype.  A generic formal
     type defined by 1delta0 <> is matched by any fixed point subtype.  No other matches are possible for
     these generic formal types.

     6References:0 4 box delimiter 12.1.2, discrete type 3.5, enumeration type 3.5.1, fixed point type
     3.5.9, floating point type 3.5.7, generic actual type 12.3, generic formal type 12.1.2, generic type
     definition 12.1, integer type 3.5.4, matching generic actual parameter 12.3, scalar type 3.5 0

      subsection lrm-section12-3-4



     712.3.4. Matching Rules for Formal Array Types

0     A formal array type is matched by an actual array subtype that satisfies the following conditions:

        - The formal array type and the actual array type must have the same dimensionality; the formal
          type and the actual subtype must be either both constrained or both unconstrained.

        - For each index position, the index type must be the same for the actual array type as for the
          formal array type.

        - The component type must be the same for the actual array type as for the formal array type.  If
          the component type is other than a scalar type, then the component subtypes must be either both
          constrained or both unconstrained.

     If a generic unit has a formal array type, the elaboration of a corresponding instantiation checks that
     the constraints (if any) on the component type are the same for the actual array type as for the formal
     array type, and likewise that for any given index position the index subtypes or the discrete ranges have
     the same bounds.  The exception CONSTRAINT_ERROR is raised if this check fails.

     6Example:

0         6--  given the generic package

0         1generic
0            1type0 ITEM   1is0 1private0;
            1type0 INDEX  1IS0 (<>);
            1type0 VECTOR    1is0 1array0 (INDEX 1RANGE0 <>) of ITEM;
            1type0 TABLE  1is0 1array0 (INDEX) 1of0 ITEM;
         1package0 P 1is

0         1end0;

         6--  and the types

0         1type0 MIX    1is0 1array0 (COLOR 1RANGE0 <>) of BOOLEAN;
         1type0 OPTION    1is0 1array0 (COLOR) 1of0 BOOLEAN;

         6--  then   MIX   can match VECTOR and OPTION can match TABLE

0         1package0 R 1is0 1new0 P(  ITEM   => BOOLEAN,    INDEX    => COLOR,
            VECTOR    => MIX,  TABLE    => OPTION);

         6--  Note that MIX cannot match TABLE and OPTION cannot match VECTOR
0     6Note:

0     For the above rules, if any of the index or component types of the formal array type is itself a formal
     type, then within the instance its name denotes the corresponding actual subtype (see 12.3(d)).

     6References:0 4 array type 3.6, array type definition 3.6, component of an array 3.6, constrained
     array type 3.6, constraint 3.3, constraint_error exception 11.1, elaboration 3.9, formal type 12.1,
     generic formal type 12.1.2, generic instantiation 12.3, index 3.6, index constraint 3.6.1, matching
     generic actual parameter 12.3, raise statement 11.3, subtype 3.3, unconstrained array type 3.60

      subsection lrm-section12-3-5



     712.3.5. Matching Rules for Formal Access Types

0     A formal access type is matched by an actual access subtype if the type of the designated objects is the
     same for the actual type as for the formal type.  If the designated type is other than a scalar type,
     then the designated subtypes must be either both constrained or both unconstrained.

     If a generic unit has a formal access type, the elaboration of a corresponding instantiation checks that
     any constraints on the designated objects are the same for the actual access subtype as for the formal
     access type.  The exception CONSTRAINT_ERROR is raised if this check fails.

     6Example:

0         6--  the formal types of the generic package

0         1generic
0            1type0 NODE   1is0 1private0;
            1type0 LINK   1is0 1access0 NODE;
         1package0 P 1is
0            ...
         1end0;

         6--  can be matched by the actual types

0         1type0 CAR;
         1type0 CAR_NAME 1is0 1access0 CAR;

         1type0 CAR 1is
0            1record
0               PRED, SUCC   : CAR_NAME;
               NUMBER    : LICENSE_NUMBER;
               OWNER  : PERSON;
            1end0 1record0;


         6--  in the following generic instantiation

0         1package0 R 1is0 1new0 P(NODE => CAR, LINK => CAR_NAME);

     6Note:

0     For the above rules, if the designated type is itself a formal type, then within the instance its name
     denotes the corresponding actual subtype (see 12.3(d)).

     6References:0 4 access type 3.8, access type definition 3.8, constraint 3.3, constraint_error
     exception 11.1, designate 3.8, elaboration 3.9, generic formal type 12.1.2, generic instantiation 12.3,
     matching generic actual parameter 12.3, object 3.2, raise statement 11.3, value of access type 3.8 0

      subsection lrm-section12-3-6



     712.3.6. Matching Rules for Formal Subprograms

0     A formal subprogram is matched by an actual subprogram, enumeration literal, or entry if both have the
     same parameter and result type profile (see 6.6); in addition, parameter modes must be identical for
     formal parameters that are at the same parameter position.

     If a generic unit has a default subprogram specified by a name, this name must denote a subprogram, an
     enumeration literal, or an entry, that matches the formal subprogram (in the above sense).  The
     evaluation of the default name takes place during the elaboration of each instantiation that uses the
     default, as defined in section 12.3.

     If a generic unit has a default subprogram specified by a box, the corresponding actual parameter can be
     omitted if a subprogram, enumeration literal, or entry matching the formal subprogram, and with the same
     designator as the formal subprogram, is directly visible at the place of the generic instantiation; this
     subprogram, enumeration literal, or entry is then used by default (there must be exactly one subprogram,
     enumeration literal, or entry satisfying the previous conditions).

     6Example:

0         6--  given the generic function specification

0         1generic
0            1type0 ITEM 1is0 1private0;
            1with0 1function0 "*" (U, V : ITEM) 1return0 ITEM 1IS0 <>;
         1function0 SQUARING(X : ITEM) 1return0 ITEM;

         6--  and the function

0         1function0 MATRIX_PRODUCT(A, B : MATRIX) 1return0 MATRIX;

         6--  the following instantiation is possible

0         1function0 SQUARE 1is0 1new0 SQUARING(MATRIX, MATRIX_PRODUCT);

         6--  the following instantiations are equivalent

0         1function0 SQUARE 1is0 1new0 SQUARING(ITEM => INTEGER, "*" => "*");
         1function0 SQUARE 1is0 1new0 SQUARING(INTEGER, "*");
         1function0 SQUARE 1is0 1new0 SQUARING(INTEGER);

     6Notes:

0     The matching rules for formal subprograms state requirements that are similar to those applying to
     subprogram renaming declarations (see 8.5).  In particular, the name of a parameter of the formal
     subprogram need not be the same as that of the corresponding parameter of the actual subprogram;
     similarly, for these parameters, default expressions need not correspond.

     A formal subprogram is matched by an attribute of a type if the attribute is a function with a matching
     specification.  An enumeration literal of a given type matches a parameterless formal function whose
     result type is the given type.

     6References:0 4 attribute 4.1.4, box delimiter 12.1.2, designator 6.1, entry 9.5, function 6.5,
     generic actual type 12.3, generic formal subprogram 12.1.3, generic formal type 12.1.2, generic
     instantiation 12.3, matching generic actual parameter 12.3, name 4.1, parameter and result type profile
     6.3, subprogram 6, subprogram specification 6.1, subtype 3.3, visibility 8.3 0

      section lrm-section12-4

     212.4. Example of a Generic Package

0     The following example provides a possible formulation of stacks by means of a generic package.  The size
     of each stack and the type of the stack elements are provided as generic parameters.
         1generic
0            SIZE : POSITIVE;
            1type0 ITEM 1is0 1private0;
         1package0 STACK 1is
0            1procedure0 PUSH   (E : IN   ITEM);
            1procedure0 POP (E : OUT  ITEM);
            OVERFLOW, UNDERFLOW : 1exception0;
         1end0 STACK;

         1package0 1body0 STACK 1is

0            1type0 TABLE 1is0 1array0 (POSITIVE 1RANGE0 <>) of ITEM;
            SPACE  : TABLE(1 .. SIZE);
            INDEX  : NATURAL := 0;

            1procedure0 PUSH(E : 1in0 ITEM) 1is
0            1begin
0               1if0 INDEX >= SIZE 1then
0                  1raise0 OVERFLOW;
               1end0 1if0;
               INDEX := INDEX + 1;
               SPACE(INDEX) := E;
            1end0 PUSH;

            1procedure0 POP(E : 1out0 ITEM) 1is
0            1begin
0               1if0 INDEX = 0 1then
0                  1raise0 UNDERFLOW;
               1end0 1if0;
               E := SPACE(INDEX);
               INDEX := INDEX - 1;
            1end0 POP;

         1end0 STACK;

     Instances of this generic package can be obtained as follows:

         1package0 STACK_INT    1is0 1new0 STACK(SIZE => 200, ITEM => INTEGER);
         1package0 STACK_BOOL   1is0 1new0 STACK(100, BOOLEAN);

     Thereafter, the procedures of the instantiated packages can be called as follows:

         STACK_INT.PUSH(N);
         STACK_BOOL.PUSH(TRUE);

     Alternatively, a generic formulation of the type STACK can be given as follows (package body omitted):

         1generic
0            1type0 ITEM 1is0 1private0;
         1package0 ON_STACKS 1is
0            1type0 STACK(SIZE : POSITIVE) 1is0 1limited0 1private0;
            1procedure0 PUSH   (S : 1in0 1out0 STACK; E : IN    ITEM);
            1procedure0 POP (S : 1in0 1out0 STACK; E : OUT   ITEM);
            OVERFLOW, UNDERFLOW : 1exception0;
         1private
0            1type0 TABLE 1is0 1array0 (POSITIVE 1RANGE0 <>) of ITEM;
            1type0 STACK(SIZE : POSITIVE) 1is
0               1record
0                  SPACE  : TABLE(1 .. SIZE);
                  INDEX  : NATURAL := 0;
               1end0 1record0;
         1end0;

     In order to use such a package, an instantiation must be created and thereafter stacks of the
     corresponding type can be declared:
         1declare
0            1package0 STACK_REAL 1is0 1new0 ON_STACKS(REAL); 1use0 STACK_REAL;
            S : STACK(100);
         1begin
0            ...
            PUSH(S, 2.54);
            ...
         1end0;

      chapter lrm-chapter-13



                         113. Representation Clauses and Implementation-Dependent Features

0     This chapter describes representation clauses, certain implementation-dependent features, and other
     features that are used in system programming.

      section lrm-section13-1

     213.1. Representation Clauses

0     Representation clauses specify how the types of the language are to be mapped onto the underlying
     machine.  They can be provided to give more efficient representation or to interface with features that
     are outside the domain of the language (for example, peripheral hardware).

         representation_clause ::=
                type_representation_clause | address_clause

         type_representation_clause ::= length_clause
            |   enumeration_representation_clause | record_representation_clause

     A type representation clause applies either to a type or to a 6first0 6named0 6subtype0 (that is,
     to a subtype declared by a type declaration, the base type being therefore anonymous).  Such a
     representation clause applies to all objects that have this type or this first named subtype.  At most
     one enumeration or record representation clause is allowed for a given type:  an enumeration
     representation clause is only allowed for an enumeration type; a record representation clause, only for a
     record type.  (On the other hand, more than one length clause can be provided for a given type; moreover,
     both a length clause and an enumeration or record representation clause can be provided.)  A length
     clause is the only form of representation clause allowed for a type derived from a parent type that has
     (user-defined) derivable subprograms.

     An address clause applies either to an object; to a subprogram, package, or task unit; or to an entry.
     At most one address clause is allowed for any of these entities.

     A representation clause and the declaration of the entity to which the clause applies must both occur
     immediately within the same declarative part, package specification, or task specification; the
     declaration must occur before the clause.  In the absence of a representation clause for a given
     declaration, a default representation of this declaration is determined by the implementation.  Such a
     default determination occurs no later than the end of the immediately enclosing declarative part, package
     specification, or task specification.  For a declaration given in a declarative part, this default
     determination occurs before any enclosed body.

     In the case of a type, certain occurrences of its name imply that the representation of the type must
     already have been determined.  Consequently these occurrences force the default determination of any
     aspect of the representation not already determined by a prior type representation clause.  This default
     determination is also forced by similar occurrences of the name of a subtype of the type, or of the name
     of any type or subtype that has subcomponents of the type.  A forcing occurrence is any occurrence other
     than in a type or subtype declaration, a subprogram specification, an entry declaration, a deferred
     constant declaration, a pragma, or a representation clause for the type itself.  In any case, an
     occurrence within an expression is always forcing.

     A representation clause for a given entity must not appear after an occurrence of the name of the entity
     if this occurrence forces a default determination of representation for the entity.

     Similar restrictions exist for address clauses.  For an object, any occurrence of its name (after the
     object declaration) is a forcing occurrence.  For a subprogram, package, task unit, or entry, any
     occurrence of a representation attribute of such an entity is a forcing occurrence.

     The effect of the elaboration of a representation clause is to define the corresponding aspects of the
     representation.

     The interpretation of some of the expressions that appear in representation clauses is
     implementation-dependent, for example, expressions specifying addresses.  An implementation may limit its
     acceptance of representation clauses to those that can be handled simply by the underlying hardware.  If
     a representation clause is accepted by an implementation, the compiler must guarantee that the net effect
     of the program is not changed by the presence of the clause, except for address clauses and for parts of
     the program that interrogate representation attributes.  If a program contains a representation clause
     that is not accepted, the program is illegal.  For each implementation, the allowed representation
     clauses, and the conventions used for implementation-dependent expressions, must be documented in
     Appendix F of the reference manual.

     Whereas a representation clause is used to impose certain characteristics of the mapping of an entity
     onto the underlying machine, pragmas can be used to provide an implementation with criteria for its
     selection of such a mapping.  The pragma PACK specifies that storage minimization should be the main
     criterion when selecting the representation of a record or array type.  Its form is as follows:

         1pragma0 PACK(6type0_simple_name);

     Packing means that gaps between the storage areas allocated to consecutive components should be
     minimized.  It need not, however, affect the mapping of each component onto storage.  This mapping can
     itself be influenced by a pragma (or controlled by a representation clause) for the component or
     component type.  The position of a PACK pragma, and the restrictions on the named type, are governed by
     the same rules as for a representation clause; in particular, the pragma must appear before any use of a
     representation attribute of the packed entity.

     The pragma PACK is the only language-defined representation pragma.  Additional representation pragmas
     may be provided by an implementation; these must be documented in Appendix F. (In contrast to
     representation clauses, a pragma that is not accepted by the implementation is ignored.)

     6Note:

0     No representation clause is allowed for a generic formal type.

     6References:0 4 address clause 13.5, allow 1.6, body 3.9, component 3.3, declaration 3.1, declarative
     part 3.9, default expression 3.2.1, deferred constant declaration 7.4, derivable subprogram 3.4, derived
     type 3.4, entity 3.1, entry 9.5, enumeration representation clause 13.3, expression 4.4, generic formal
     type 12.1.2, illegal 1.6, length clause 13.2, must 1.6, name 4.1, object 3.2, occur immediately within
     8.1, package 7, package specification 7.1, parent type 3.4, pragma 2.8, record representation clause
     13.4, representation attribute 13.7.2 13.7.3, subcomponent 3.3, subprogram 6, subtype 3.3, subtype
     declaration 3.3.2, task specification 9.1, task unit 9, type 3.3, type declaration 3.3.10

      section lrm-section13-2

     213.2. Length Clauses

0     A length clause specifies an amount of storage associated with a type.

         length_clause ::= 1for0 attribute 1use0 simple_expression;

     The expression must be of some numeric type and is evaluated during the elaboration of the length clause
     (unless it is a static expression).  The prefix of the attribute must denote either a type or a first
     named subtype. The prefix is called T in what follows.  The only allowed attribute designators in a
     length clause are SIZE, STORAGE_SIZE, and SMALL.  The effect of the length clause depends on the
     attribute designator:

        1. Size specification:  T'SIZE

           The expression must be a static expression of some integer type.  The value of the expression
           specifies an upper bound for the number of bits to be allocated to objects of the type or
           first named subtype T. The size specification must allow for enough storage space to
           accommodate every allowable value of these objects.  A size specification for a composite type
           may affect the size of the gaps between the storage areas allocated to consecutive components.
           On the other hand, it need not affect the size of the storage area allocated to each
           component.

           The size specification is only allowed if the constraints on T and on its subcomponents (if
           any) are static.  In the case of an unconstrained array type, the index subtypes must also be
           static.

        2. Specification of collection size:  T'STORAGE_SIZE

           The prefix T must denote an access type.  The expression must be of some integer type (but
           need not be static); its value specifies the number of storage units to be reserved for the
           collection, that is, the storage space needed to contain all objects designated by values of
           the access type and by values of other types derived from the access type, directly or
           indirectly.  This form of length clause is not allowed for a type derived from an access type.

        3. Specification of storage for a task activation:  T'STORAGE_SIZE

           The prefix T must denote a task type.  The expression must be of some integer type (but need
           not be static); its value specifies the number of storage units to be reserved for an
           activation (not the code) of a task of the type.

        4. Specification of 6small0 for a fixed point type:  T'SMALL

           The prefix T must denote the first named subtype of a fixed point type.  The expression must
           be a static expression of some real type; its value must not be greater than the delta of the
           first named subtype.  The effect of the length clause is to use this value of 6small0 for
           the representation of values of the fixed point base type.  (The length clause thereby also
           affects the amount of storage for objects that have this type.)

     6Notes:

0     A size specification is allowed for an access, task, or fixed point type, whether or not another form of
     length clause is also given for the type.

     What is considered to be part of the storage reserved for a collection or for an activation of a task is
     implementation-dependent.  The control afforded by length clauses is therefore relative to the
     implementation conventions.  For example, the language does not define whether the storage reserved for
     an activation of a task includes any storage needed for the collection associated with an access type
     declared within the task body.  Neither does it define the method of allocation for objects denoted by
     values of an access type.  For example, the space allocated could be on a stack; alternatively, a general
     dynamic allocation scheme or fixed storage could be used.

     The objects allocated in a collection need not have the same size if the designated type is an
     unconstrained array type or an unconstrained type with discriminants.  Note also that the allocator
     itself may require some space for internal tables and links.  Hence a length clause for the collection of
     an access type does not always give precise control over the maximum number of allocated objects.

     6Examples:

0         6--  assumed declarations:

0         1type0 MEDIUM    1is0 RANGE   0 .. 65000;
         1type0 SHORT  1is0 DELTA   0.01  1range0 -100.0  .. 100.0;
         1type0 DEGREE    1is0 DELTA   0.1   1range0 -360.0  .. 360.0;

         BYTE   : 1constant0 := 8;
         PAGE   : 1constant0 := 2000;

         6--  length clauses:

0         1for0 COLOR'SIZE    1use0 1*BYTE;  6--  see 3.5.1
0         1for0 MEDIUM'SIZE   1use0 2*BYTE;
         1for0 SHORT'SIZE    1use0 15;

         1for0 CAR_NAME'STORAGE_SIZE 1use0  6--  approximately 2000 cars
0                     2000*((CAR'SIZE/SYSTEM.STORAGE_UNIT) + 1);

         1for0 KEYBOARD_DRIVER'STORAGE_SIZE 1use0 1*PAGE;

         1for0 DEGREE'SMALL 1use0 360.0/2**(SYSTEM.STORAGE_UNIT - 1);

     6Notes0 6on0 6the0 6examples:

0     In the length clause for SHORT, fifteen bits is the minimum necessary, since the type definition requires
     SHORT'SMALL = 2.0**(-7) and SHORT'MANTISSA = 14.  The length clause for DEGREE forces the model numbers
     to exactly span the range of the type.

     6References:0 4 access type 3.8, allocator 4.8, allow 1.6, array type 3.6, attribute 4.1.4, collection
     3.8, composite type 3.3, constraint 3.3, delta of a fixed point type 3.5.9, derived type 3.4, designate
     3.8, elaboration 3.9, entity 3.1, evaluation 4.5, expression 4.4, first named subtype 13.1, fixed point
     type 3.5.9, index subtype 3.6, integer type 3.5.4, must 1.6, numeric type 3.5, object 3.2, real type
     3.5.6, record type 3.7, small of a fixed point type 3.5.10, static constraint 4.9, static expression 4.9,
     static subtype 4.9, storage unit 13.7, subcomponent 3.3, system package 13.7, task 9, task activation
     9.3, task specification 9.1, task type 9.2, type 3.3, unconstrained array type 3.6 0

      section lrm-section13-3

     213.3. Enumeration Representation Clauses

0     An enumeration representation clause specifies the internal codes for the literals of the enumeration
     type that is named in the clause.

         enumeration_representation_clause ::= 1for0 6type0_simple_name 1use0 aggregate;

     The aggregate used to specify this mapping is written as a one-dimensional aggregate, for which the index
     subtype is the enumeration type and the component type is 6universal0_6integer.

0     All literals of the enumeration type must be provided with distinct integer codes, and all choices and
     component values given in the aggregate must be static.  The integer codes specified for the enumeration
     type must satisfy the predefined ordering relation of the type.

     6Example:

0         1type0 MIX_CODE 1is0 (ADD, SUB, MUL, LDA, STA, STZ);

         1for0 MIX_CODE 1use
0            (ADD => 1, SUB => 2, MUL => 3, LDA => 8, STA => 24, STZ => 33);

     6Notes:

0     The attributes SUCC, PRED, and POS are defined even for enumeration types with a noncontiguous
     representation; their definition corresponds to the (logical) type declaration and is not affected by the
     enumeration representation clause.  In the example, because of the need to avoid the omitted values,
     these functions are likely to be less efficiently implemented than they could be in the absence of a
     representation clause.  Similar considerations apply when such types are used for indexing.

     6References:0 4 aggregate 4.3, array aggregate 4.3.2, array type 3.6, attribute of an enumeration type
     3.5.5, choice 3.7.3, component 3.3, enumeration literal 3.5.1, enumeration type 3.5.1, function 6.5,
     index 3.6, index subtype 3.6, literal 4.2, ordering relation of an enumeration type 3.5.1, representation
     clause 13.1, simple name 4.1, static expression 4.9, type 3.3, type declaration 3.3.1, universal_integer
     type 3.5.40

      section lrm-section13-4

     213.4. Record Representation Clauses

0     A record representation clause specifies the storage representation of records, that is, the order,
     position, and size of record components (including discriminants, if any).

         record_representation_clause ::=
            1for0 6type0_simple_name 1use
0               1record0 [alignment_clause]
                  {component_clause}
               1end0 1record0;

         alignment_clause ::= 1at0 1mod0 6static_0simple_expression;

         component_clause ::=
            6component0_name 1at0 6static_0simple_expression 1range0 6static0_range;

     The simple expression given after the reserved words 1at0 1mod0 in an alignment clause, or after the
     reserved word 1at0 in a component clause, must be a static expression of some integer type.  If the
     bounds of the range of a component clause are defined by simple expressions, then each bound of the range
     must be defined by a static expression of some integer type, but the two bounds need not have the same
     integer type.

     An alignment clause forces each record of the given type to be allocated at a starting address that is a
     multiple of the value of the given expression (that is, the address modulo the expression must be zero).
     An implementation may place restrictions on the allowable alignments.

     A component clause specifies the 6storage0 6place0 of a component, relative to the start of the
     record.  The integer defined by the static expression of a component clause is a relative address
     expressed in storage units.  The range defines the bit positions of the storage place, relative to the
     storage unit.  The first storage unit of a record is numbered zero.  The first bit of a storage unit is
     numbered zero.  The ordering of bits in a storage unit is machine-dependent and may extend to adjacent
     storage units.  (For a specific machine, the size in bits of a storage unit is given by the
     configuration-dependent named number SYSTEM.STORAGE_UNIT.)  Whether a component is allowed to overlap a
     storage boundary, and if so, how, is implementation-defined.

     At most one component clause is allowed for each component of the record type, including for each
     discriminant (component clauses may be given for some, all, or none of the components).  If no component
     clause is given for a component, then the choice of the storage place for the component is left to the
     compiler.  If component clauses are given for all components, the record representation clause completely
     specifies the representation of the record type and must be obeyed exactly by the compiler.

     Storage places within a record variant must not overlap, but overlap of the storage for distinct variants
     is allowed.  Each component clause must allow for enough storage space to accommodate every allowable
     value of the component.  A component clause is only allowed for a component if any constraint on this
     component or on any of its subcomponents is static.

     An implementation may generate names that denote implementation-dependent components (for example, one
     containing the offset of another component).  Such implementation-dependent names can be used in record
     representation clauses (these names need not be simple names; for example, they could be
     implementation-dependent attributes).

     6Example:

0         WORD : 1constant0 := 4;  6--  storage unit is byte, 4 bytes per word

0         1type0 STATE  1is0 (A, M, W, P);
         1type0 MODE   1is0 (FIX, DEC, EXP, SIGNIF);

         1type0 BYTE_MASK    1is0 1array0 (0 .. 7)  1of0 BOOLEAN;
         1type0 STATE_MASK   1is0 1array0 (STATE)   1of0 BOOLEAN;
         1type0 MODE_MASK    1is0 1array0 (MODE)    1of0 BOOLEAN;

         1type0 PROGRAM_STATUS_WORD 1is
0            1record
0               SYSTEM_MASK  : BYTE_MASK;
               PROTECTION_KEY  : INTEGER 1range0 0 .. 3;
               MACHINE_STATE   : STATE_MASK;
               INTERRUPT_CAUSE    : INTERRUPTION_CODE;
               ILC    : INTEGER 1range0 0 .. 3;
               CC  : INTEGER 1range0 0 .. 3;
               PROGRAM_MASK    : MODE_MASK;
               INST_ADDRESS    : ADDRESS;
            1end0 1record0;

         1for0 PROGRAM_STATUS_WORD 1use
0            1record0 1at0 1mod0 8;
               SYSTEM_MASK  1at0 0*WORD  1range0 0    .. 7;
               PROTECTION_KEY  1at0 0*WORD  1range0 10   .. 11;    6--  bits 8, 9 unused
0               MACHINE_STATE   1at0 0*WORD  1range0 12   .. 15;
               INTERRUPT_CAUSE    1at0 0*WORD  1range0 16   .. 31;
               ILC    1at0 1*WORD  1range0 0    .. 1;                      6--  second word
0               CC  1at0 1*WORD  1range0 2    .. 3;
               PROGRAM_MASK    1at0 1*WORD  1range0 4    .. 7;
               INST_ADDRESS    1at0 1*WORD  1range0 8    .. 31;
            1end0 1record0;

         1for0 PROGRAM_STATUS_WORD'SIZE 1use0 8*SYSTEM.STORAGE_UNIT;

     6Note0 6on0 6the0 6example:

0     The record representation clause defines the record layout.  The length clause guarantees that exactly
     eight storage units are used.

     6References:0 4 allow 1.6, attribute 4.1.4, constant 3.2.1, constraint 3.3, discriminant 3.7.1,
     integer type 3.5.4, must 1.6, named number 3.2, range 3.5, record component 3.7, record type 3.7, simple
     expression 4.4, simple name 4.1, static constraint 4.9, static expression 4.9, storage unit 13.7,
     subcomponent 3.3, system package 13.7, variant 3.7.3 0

      section lrm-section13-5

     213.5. Address Clauses

0     An address clause specifies a required address in storage for an entity.

         address_clause ::= 1for0 simple_name 1use0 1at0 simple_expression;

     The expression given after the reserved word 1at0 must be of the type ADDRESS defined in the package
     SYSTEM (see 13.7); this package must be named by a with clause that applies to the compilation unit in
     which the address clause occurs.  The conventions that define the interpretation of a value of the type
     ADDRESS as an address, as an interrupt level, or whatever it may be, are implementation-dependent.  The
     allowed nature of the simple name and the meaning of the corresponding address are as follows:

        1. Name of an object:  the address is that required for the object (variable or constant).

        2. Name of a subprogram, package, or task unit:  the address is that required for the machine
           code associated with the body of the program unit.

        3. Name of a single entry:  the address specifies a hardware interrupt to which the single entry
           is to be linked.

     If the simple name is that of a single task, the address clause is understood to refer to the task unit
     and not to the task object.  In all cases, the address clause is only legal if exactly one declaration
     with this identifier occurs earlier, immediately within the same declarative part, package specification,
     or task specification.  A name declared by a renaming declaration is not allowed as the simple name.
     :text Address clauses should not be used to achieve overlays of objects or overlays of program units.
     Nor should a given interrupt be linked to more than one entry.  Any program using address clauses to
     achieve such effects is erroneous.

     6Example:

0         1for0 CONTROL 1use0 1at0 16#0020#;  --  assuming that SYSTEM.ADDRESS is an integer type

     6Notes:

0     The above rules imply that if two subprograms overload each other and are visible at a given point, an
     address clause for any of them is not legal at this point.  Similarly if a task specification declares
     entries that overload each other, they cannot be interrupt entries.  The syntax does not allow an address
     clause for a library unit.  An implementation may provide pragmas for the specification of program
     overlays.

     6References:0 4 address predefined type 13.7, apply 10.1.1, compilation unit 10.1, constant 3.2.1,
     entity 3.1, entry 9.5, erroneous 1.6, expression 4.4, library unit 10.1, name 4.1, object 3.2, package 7,
     pragma 2.8, program unit 6, reserved word 2.9, simple expression 4.4, simple name 4.1, subprogram 6,
     subprogram body 6.3, system package 13.7, task body 9.1, task object 9.2, task unit 9, type 3.3, variable
     3.2.1, with clause 10.1.1 0

      subsection lrm-section13-5-1



     713.5.1. Interrupts

0     An address clause given for an entry associates the entry with some device that may cause an interrupt;
     such an entry is referred to in this section as an 6interrupt0 6entry.0 If control information is
     supplied upon an interrupt, it is passed to an associated interrupt entry as one or more parameters of
     mode 1in0; only parameters of this mode are allowed.

     An interrupt acts as an entry call issued by a hardware task whose priority is higher than the priority
     of the main program, and also higher than the priority of any user-defined task (that is, any task whose
     type is declared by a task unit in the program).  The entry call may be an ordinary entry call, a timed
     entry call, or a conditional entry call, depending on the kind of interrupt and on the implementation.

     If a select statement contains both a terminate alternative and an accept alternative for an interrupt
     entry, then an implementation may impose further requirements for the selection of the terminate
     alternative in addition to those given in section 9.4.

     6Example:

0         1task0 INTERRUPT_HANDLER 1is
0            1entry0 DONE;
            1for0 DONE 1use0 1at0 16#40#;  6--  assuming that SYSTEM.ADDRESS is an integer type
0         1end0 INTERRUPT_HANDLER;

     6Notes:

0     Interrupt entry calls need only have the semantics described above; they may be implemented by having the
     hardware directly execute the appropriate accept statements.

     Queued interrupts correspond to ordinary entry calls.  Interrupts that are lost if not immediately
     processed correspond to conditional entry calls.  It is a consequence of the priority rules that an
     accept statement executed in response to an interrupt takes precedence over ordinary, user-defined tasks,
     and can be executed without first invoking a scheduling action.

     One of the possible effects of an address clause for an interrupt entry is to specify the priority of the
     interrupt (directly or indirectly).  Direct calls to an interrupt entry are allowed.

     6References:0 4 accept alternative 9.7.1, accept statement 9.5, address predefined type 13.7, allow
     1.6, conditional entry call 9.7.2, entry 9.5, entry call 9.5, mode 6.1, parameter of a subprogram 6.2,
     priority of a task 9.8, select alternative 9.7.1, select statement 9.7, system package 13.7, task 9,
     terminate alternative 9.7.1, timed entry call 9.7.3 0

      section lrm-section13-6

     213.6. Change of Representation

0     At most one representation clause is allowed for a given type and a given aspect of its representation.
     Hence, if an alternative representation is needed, it is necessary to declare a second type, derived from
     the first, and to specify a different representation for the second type.

     6Example:

0         6--  PACKED0_6DESCRIPTOR and DESCRIPTOR are two different types
0         6--  with identical characteristics, apart from their representation

0         1type0 DESCRIPTOR 1is
0            1record
0               6--  components of a descriptor
0            1end0 1record0;

         1type0 PACKED_DESCRIPTOR 1is0 1new0 DESCRIPTOR;

         1for0 PACKED_DESCRIPTOR 1use
0            1record
0               6--  component clauses for some or for all components
0            1end0 1record0;

     Change of representation can now be accomplished by assignment with explicit type conversions:

         D   : DESCRIPTOR;
         P   : PACKED_DESCRIPTOR;

         P   := PACKED_DESCRIPTOR(D);    6--  pack D
0         D   := DESCRIPTOR(P);     6--  unpack P

0     6References:0 4 assignment 5.2, derived type 3.4, type 3.3, type conversion 4.6, type declaration 3.1,
     representation clause 13.10

      section lrm-section13-7

     213.7. The Package System

0     For each implementation there is a predefined library package called SYSTEM which includes the
     definitions of certain configuration-dependent characteristics.  The specification of the package SYSTEM
     is implementation-dependent and must be given in Appendix F. The visible part of this package must
     contain at least the following declarations.

         1package0 SYSTEM 1is
0            1type0 ADDRESS   1is0 6implementation0_6defined0;
            1type0 NAME   1is0 6implementation0_6defined0_6enumeration0_6type0;

            SYSTEM_NAME  : 1constant0 NAME  := 6implementation0_6defined0;

            STORAGE_UNIT    : 1constant0 := 6implementation0_6defined0;
            MEMORY_SIZE  : 1constant0 := 6implementation0_6defined0;

            --  System-Dependent Named Numbers:

            MIN_INT   : 1constant0 := 6implementation0_6defined0;
            MAX_INT   : 1constant0 := 6implementation0_6defined0;
            MAX_DIGITS   : 1constant0 := 6implementation0_6defined0;
            MAX_MANTISSA    : 1constant0 := 6implementation0_6defined0;
            FINE_DELTA   : 1constant0 := 6implementation0_6defined0;
            TICK   : 1constant0 := 6implementation0_6defined0;

            --  Other System-Dependent Declarations

            1subtype0 PRIORITY 1is0 INTEGER 1range0 6implementation0_6defined0;

            ...
         1end0 SYSTEM;

     The type ADDRESS is the type of the addresses provided in address clauses; it is also the type of the
     result delivered by the attribute ADDRESS.  Values of the enumeration type NAME are the names of
     alternative machine configurations handled by the implementation; one of these is the constant
     SYSTEM_NAME.  The named number STORAGE_UNIT is the number of bits per storage unit; the named number
     MEMORY_SIZE is the number of available storage units in the configuration; these named numbers are of the
     type 6universal0_6integer.

0     An alternative form of the package SYSTEM, with given values for any of SYSTEM_NAME, STORAGE_UNIT, and
     MEMORY_SIZE, can be obtained by means of the corresponding pragmas.  These pragmas are only allowed at
     the start of a compilation, before the first compilation unit (if any) of the compilation.

         1pragma0 SYSTEM_NAME(enumeration_literal);

     The effect of the above pragma is to use the enumeration literal with the specified identifier for the
     definition of the constant SYSTEM_NAME.  This pragma is only allowed if the specified identifier
     corresponds to one of the literals of the type NAME.

         1pragma0 STORAGE_UNIT(numeric_literal);

     The effect of the above pragma is to use the value of the specified numeric literal for the definition of
     the named number STORAGE_UNIT.

         1pragma0 MEMORY_SIZE(numeric_literal);

     The effect of the above pragma is to use the value of the specified numeric literal for the definition of
     the named number MEMORY_SIZE.

     The compilation of any of these pragmas causes an implicit recompilation of the package SYSTEM.
     Consequently any compilation unit that names SYSTEM in its context clause becomes obsolete after this
     implicit recompilation.  An implementation may impose further limitations on the use of these pragmas.
     For example, an implementation may allow them only at the start of the first compilation, when creating a
     new program library.

     6Note:

0     It is a consequence of the visibility rules that a declaration given in the package SYSTEM is not visible
     in a compilation unit unless this package is mentioned by a with clause that applies (directly or
     indirectly) to the compilation unit.

     6References:0 4 address clause 13.5, apply 10.1.1, attribute 4.1.4, compilation unit 10.1, declaration
     3.1, enumeration literal 3.5.1, enumeration type 3.5.1, identifier 2.3, library unit 10.1, must 1.6,
     named number 3.2, number declaration 3.2.2, numeric literal 2.4, package 7, package specification 7.1,
     pragma 2.8, program library 10.1, type 3.3, visibility 8.3, visible part 7.2, with clause 10.1.1 0

      subsection lrm-section13-7-1



     713.7.1. System-Dependent Named Numbers

0     Within the package SYSTEM, the following named numbers are declared.  The numbers FINE_DELTA and TICK are
     of the type 6universal0_6real0; the others are of the type 6universal0_6integer.

0     MIN_INT             The smallest (most negative) value of all predefined integer types.

     MAX_INT             The largest (most positive) value of all predefined integer types.

     MAX_DIGITS          The largest value allowed for the number of significant decimal digits in a floating
                         point constraint.

     MAX_MANTISSA        The largest possible number of binary digits in the mantissa of model numbers of a
                         fixed point subtype.

     FINE_DELTA          The smallest delta allowed in a fixed point constraint that has the range constraint
                         -1.0 .. 1.0.

     TICK                The basic clock period, in seconds.

     6References:0 4 allow 1.6, delta of a fixed point constraint 3.5.9, fixed point constraint 3.5.9,
     floating point constraint 3.5.7, integer type 3.5.4, model number 3.5.6, named number 3.2, package 7,
     range constraint 3.5, system package 13.7, type 3.3, universal0_4integer type 3.5.4, universal0_4real
     type 3.5.6 0

      subsection lrm-section13-7-2



     713.7.2. Representation Attributes

0     The values of certain implementation-dependent characteristics can be obtained by interrogating
     appropriate 6representation0 6attributes.0 These attributes are described below.

     For any object, program unit, label, or entry X:
     X'ADDRESS           Yields the address of the first of the storage units allocated to X. For a
                         subprogram, package, task unit or label, this value refers to the machine code
                         associated with the corresponding body or statement.  For an entry for which an
                         address clause has been given, the value refers to the corresponding hardware
                         interrupt.  The value of this attribute is of the type ADDRESS defined in the package
                         SYSTEM.

     For any type or subtype X, or for any object X:

     X'SIZE              Applied to an object, yields the number of bits allocated to hold the object.
                         Applied to a type or subtype, yields the minimum number of bits that is needed by the
                         implementation to hold any possible object of this type or subtype.  The value of
                         this attribute is of the type 6universal0_6integer.

0     For the above two representation attributes, if the prefix is the name of a function, the attribute is
     understood to be an attribute of the function (not of the result of calling the function).  Similarly, if
     the type of the prefix is an access type, the attribute is understood to be an attribute of the prefix
     (not of the designated object:  attributes of the latter can be written with a prefix ending with the
     reserved word 1all0).

     For any component C of a record object R:

     R.C'POSITION        Yields the offset, from the start of the first storage unit occupied by the record,
                         of the first of the storage units occupied by C. This offset is measured in storage
                         units.  The value of this attribute is of the type 6universal0_6integer.

0     R.C'FIRST_BIT       Yields the offset, from the start of the first of the storage units occupied by C, of
                         the first bit occupied by C. This offset is measured in bits.  The value of this
                         attribute is of the type 6universal0_6integer.

0     R.C'LAST_BIT        Yields the offset, from the start of the first of the storage units occupied by C, of
                         the last bit occupied by C. This offset is measured in bits.  The value of this
                         attribute is of the type 6universal0_6integer.

0     For any access type or subtype T:

     T'STORAGE_SIZE      Yields the total number of storage units reserved for the collection associated with
                         the base type of T. The value of this attribute is of the type
                         6universal0_6integer.

0     For any task type or task object T:

     T'STORAGE_SIZE      Yields the number of storage units reserved for each activation of a task of the type
                         T or for the activation of the task object T. The value of this attribute is of the
                         type 6universal0_6integer.

0     6Notes:

0     For a task object X, the attribute X'SIZE gives the number of bits used to hold the object X, whereas
     X'STORAGE_SIZE gives the number of storage units allocated for the activation of the task designated by
     X. For a formal parameter X, if parameter passing is achieved by copy, then the attribute X'ADDRESS
     yields the address of the local copy; if parameter passing is by reference, then the address is that of
     the actual parameter.

     6References:0 4 access subtype 3.8, access type 3.8, activation 9.3, actual parameter 6.2, address
     clause 13.5, address predefined type 13.7, attribute 4.1.4, base type 3.3, collection 3.8, component 3.3,
     entry 9.5, formal parameter 6.1 6.2, label 5.1, object 3.2, package 7, package body 7.1, parameter
     passing 6.2, program unit 6, record object 3.7, statement 5, storage unit 13.7, subprogram 6, subprogram
     body 6.3, subtype 3.3, system predefined package 13.7, task 9, task body 9.1, task object 9.2, task type
     9.2, task unit 9, type 3.3, universal_integer type 3.5.4 0

      subsection lrm-section13-7-3



     713.7.3. Representation Attributes of Real Types

0     For every real type or subtype T, the following machine-dependent attributes are defined, which are not
     related to the model numbers.  Programs using these attributes may thereby exploit properties that go
     beyond the minimal properties associated with the numeric type (see section 4.5.7 for the rules defining
     the accuracy of operations with real operands).  Precautions must therefore be taken when using these
     machine-dependent attributes if portability is to be ensured.

     For both floating point and fixed point types:

     T'MACHINE_ROUNDS    Yields the value TRUE if every predefined arithmetic operation on values of the base
                         type of T either returns an exact result or performs rounding; yields the value FALSE
                         otherwise.  The value of this attribute is of the predefined type BOOLEAN.

     T'MACHINE_OVERFLOWS Yields the value TRUE if every predefined operation on values of the base type of T
                         either provides a correct result, or raises the exception NUMERIC_ERROR in overflow
                         situations (see 4.5.7); yields the value FALSE otherwise.  The value of this
                         attribute is of the predefined type BOOLEAN.

     For floating point types, the following attributes provide characteristics of the underlying machine
     representation, in terms of the canonical form defined in section 3.5.7:

     T'MACHINE_RADIX     Yields the value of the 6radix0 used by the machine representation of the base type
                         of T. The value of this attribute is of the type 6universal0_6integer.

0     T'MACHINE_MANTISSA  Yields the number of digits in the 6mantissa0 for the machine representation of the
                         base type of T (the digits are extended digits in the range 0 to T'MACHINE_RADIX -1).
                         The value of this attribute is of the type 6universal0_6integer.

0     T'MACHINE_EMAX      Yields the largest value of 6exponent0 for the machine representation of the base
                         type of T. The value of this attribute is of the type 6universal0_6integer.

0     T'MACHINE_EMIN      Yields the smallest (most negative) value of 6exponent0 for the machine
                         representation of the base type of T. The value of this attribute is of the type
                         6universal0_6integer.

0     6Note:

0     For many machines the largest machine representable number of type F is almost

         (F'MACHINE_RADIX)**(F'MACHINE_EMAX),

     and the smallest positive representable number is

         F'MACHINE_RADIX ** (F'MACHINE_EMIN - 1)

     6References:0 4 arithmetic operator 4.5, attribute 4.1.4, base type 3.3, boolean predefined type
     3.5.3, false boolean value 3.5.3, fixed point type 3.5.9, floating point type 3.5.7, model number 3.5.6,
     numeric type 3.5, numeric_error exception 11.1, predefined operation 3.3.3, radix 3.5.7, real type 3.5.6,
     subtype 3.3, true boolean value 3.5.3, type 3.3, universal0_4integer type 3.5.4 0

      section lrm-section13-8

     213.8. Machine Code Insertions

0     A machine code insertion can be achieved by a call to a procedure whose sequence of statements contains
     code statements.

         code_statement ::= type_mark'6record0_aggregate;

     A code statement is only allowed in the sequence of statements of a procedure body.  If a procedure body
     contains code statements, then within this procedure body the only allowed form of statement is a code
     statement (labeled or not), the only allowed declarative items are use clauses, and no exception handler
     is allowed (comments and pragmas are allowed as usual).

     Each machine instruction appears as a record aggregate of a record type that defines the corresponding
     instruction.  The base type of the type mark of a code statement must be declared within the predefined
     library package called MACHINE_CODE; this package must be named by a with clause that applies to the
     compilation unit in which the code statement occurs.  An implementation is not required to provide such a
     package.

     An implementation is allowed to impose further restrictions on the record aggregates allowed in code
     statements.  For example, it may require that expressions contained in such aggregates be static
     expressions.

     An implementation may provide machine-dependent pragmas specifying register conventions and calling
     conventions.  Such pragmas must be documented in Appendix F.

     6Example:

0         M : MASK;
         1procedure0 SET_MASK; 1pragma0 INLINE(SET_MASK);

         1procedure0 SET_MASK 1is
0            1use0 MACHINE_CODE;
         1begin
0            SI_FORMAT'(CODE => SSM, B => M'BASE_REG, D => M'DISP);
            6--  M'BASE_REG and M'DISP are implementation-specific predefined attributes
0         1end0;


     6References:0 4 allow 1.6, apply 10.1.1, comment 2.7, compilation unit 10.1, declarative item 3.9,
     exception handler 11.2, inline pragma 6.3.2, labeled statement 5.1, library unit 10.1, package 7, pragma
     2.8, procedure 6 6.1, procedure body 6.3, record aggregate 4.3.1, record type 3.7, sequence of statements
     5.1, statement 5, static expression 4.9, use clause 8.4, with clause 10.1.1 0

      section lrm-section13-9

     213.9. Interface to Other Languages

0     A subprogram written in another language can be called from an Ada program provided that all
     communication is achieved via parameters and function results.  A pragma of the form

         1pragma0 INTERFACE (6language0_name, 6subprogram0_name);

     must be given for each such subprogram; a subprogram name is allowed to stand for several overloaded
     subprograms.  This pragma is allowed at the place of a declarative item, and must apply in this case to a
     subprogram declared by an earlier declarative item of the same declarative part or package specification.
     The pragma is also allowed for a library unit; in this case the pragma must appear after the subprogram
     declaration, and before any subsequent compilation unit.  The pragma specifies the other language (and
     thereby the calling conventions) and informs the compiler that an object module will be supplied for the
     corresponding subprogram.  A body is not allowed for such a subprogram (not even in the form of a body
     stub) since the instructions of the subprogram are written in another language.

     This capability need not be provided by all implementations.  An implementation may place restrictions on
     the allowable forms and places of parameters and calls.

     6Example:

0         1package0 FORT_LIB 1is
0            1function0 SQRT (X : FLOAT) 1return0 FLOAT;
            1function0 EXP  (X : FLOAT) 1return0 FLOAT;
         1private
0            1pragma0 INTERFACE(FORTRAN, SQRT);
            1pragma0 INTERFACE(FORTRAN, EXP);
         1end0 FORT_LIB;

     6Notes:

0     The conventions used by other language processors that call Ada programs are not part of the Ada language
     definition.  Such conventions must be defined by these other language processors.

     The pragma INTERFACE is not defined for generic subprograms.

     6References:0 4 allow 1.6, body stub 10.2, compilation unit 10.1, declaration 3.1, declarative item
     3.9, declarative part 3.9, function result 6.5, library unit 10.1, must 1.6, name 4.1, overloaded
     subprogram 6.6, package specification 7.1, parameter of a subprogram 6.2, pragma 2.8, subprogram 6,
     subprogram body 6.3, subprogram call 6.4, subprogram declaration 6.10

      section lrm-section13-10

     213.10. Unchecked Programming

0     The predefined generic library subprograms UNCHECKED_DEALLOCATION and UNCHECKED_CONVERSION are used for
     unchecked storage deallocation and for unchecked type conversions.

         1generic
0            1type0 OBJECT    1is0 1limited0 1private0;
            1type0 NAME   1is0 1access0 OBJECT;
         1procedure0 UNCHECKED_DEALLOCATION(X : 1in0 1out0 NAME);

         1generic
0            1type0 SOURCE    1is0 1limited0 1private0;
            1type0 TARGET    1is0 1limited0 1private0;
         1function0 UNCHECKED_CONVERSION(S : SOURCE) 1return0 TARGET;

     6References:0 4 generic subprogram 12.1, library unit 10.1, type 3.30

      subsection lrm-section13-10-1



     713.10.1. Unchecked Storage Deallocation

0     Unchecked storage deallocation of an object designated by a value of an access type is achieved by a call
     of a procedure that is obtained by instantiation of the generic procedure UNCHECKED_DEALLOCATION.  For
     example:

         1procedure0 FREE 1is0 1new0 UNCHECKED_DEALLOCATION(6object0_6type0_name, 6access0_6t

     0Such a FREE procedure has the following effect:

6        0(a) after executing FREE(X), the value of X is 1null0;

        (b) FREE(X), when X is already equal to 1null0, has no effect;

        (c) FREE(X), when X is not equal to 1null0, is an indication that the object designated by X is
            no longer required, and that the storage it occupies is to be reclaimed.

     If X and Y designate the same object, then accessing this object through Y is erroneous if this access is
     performed (or attempted) after the call FREE(X); the effect of each such access is not defined by the
     language.

     6Notes:

0     It is a consequence of the visibility rules that the generic procedure UNCHECKED_DEALLOCATION is not
     visible in a compilation unit unless this generic procedure is mentioned by a with clause that applies to
     the compilation unit.

     If X designates a task object, the call FREE(X) has no effect on the task designated by the value of this
     task object.  The same holds for any subcomponent of the object designated by X, if this subcomponent is
     a task object.

     6References:0 4 access type 3.8, apply 10.1.1, compilation unit 10.1, designate 3.8 9.1, erroneous
     1.6, generic instantiation 12.3, generic procedure 12.1, generic unit 12, library unit 10.1, null access
     value 3.8, object 3.2, procedure 6, procedure call 6.4, subcomponent 3.3, task 9, task object 9.2,
     visibility 8.3, with clause 10.1.10

      subsection lrm-section13-10-2



     713.10.2. Unchecked Type Conversions

0     An unchecked type conversion can be achieved by a call of a function that is obtained by instantiation of
     the generic function UNCHECKED_CONVERSION.

     The effect of an unchecked conversion is to return the (uninterpreted) parameter value as a value of the
     target type, that is, the bit pattern defining the source value is returned unchanged as the bit pattern
     defining a value of the target type.  An implementation may place restrictions on unchecked conversions,
     for example, restrictions depending on the respective sizes of objects of the source and target type.
     Such restrictions must be documented in appendix F.

     Whenever unchecked conversions are used, it is the programmer's responsibility to ensure that these
     conversions maintain the properties that are guaranteed by the language for objects of the target type.
     Programs that violate these properties by means of unchecked conversions are erroneous.

     6Note:

0     It is a consequence of the visibility rules that the generic function UNCHECKED_CONVERSION is not visible
     in a compilation unit unless this generic function is mentioned by a with clause that applies to the
     compilation unit.

     6References:0 4 apply 10.1.1, compilation unit 10.1, erroneous 1.6, generic function 12.1,
     instantiation 12.3, parameter of a subprogram 6.2, type 3.3, with clause 10.1.1 0

      chapter lrm-chapter-14



                                                 114. Input-Output

0     Input-output is provided in the language by means of predefined packages.  The generic packages
     SEQUENTIAL_IO and DIRECT_IO define input-output operations applicable to files containing elements of a
     given type.  Additional operations for text input-output are supplied in the package TEXT_IO.  The
     package IO_EXCEPTIONS defines the exceptions needed by the above three packages.  Finally, a package
     LOW_LEVEL_IO is provided for direct control of peripheral devices.

     6References:0 4 direct0_4io package 14.2 14.2.4, io0_4exceptions package 14.5,
     low0_4level0_4io package 14.6, sequential0_4io package 14.2 14.2.2, text0_4io package 14.30

      section lrm-section14-1

     214.1. External Files and File Objects

0     Values input from the external environment of the program, or output to the environment, are considered
     to occupy 6external0 6files0.  An external file can be anything external to the program that can
     produce a value to be read or receive a value to be written.  An external file is identified by a string
     (the 6name0).  A second string (the 6form)0 gives further system-dependent characteristics that may
     be associated with the file, such as the physical organization or access rights.  The conventions
     governing the interpretation of such strings must be documented in Appendix F.

     Input and output operations are expressed as operations on objects of some 6file0 6type0, rather than
     directly in terms of the external files.  In the remainder of this chapter, the term 6file0 is always
     used to refer to a file object; the term 6external0 6file0 is used otherwise.  The values transferred
     for a given file must all be of one type.

     Input-output for sequential files of values of a single element type is defined by means of the generic
     package SEQUENTIAL_IO.  The skeleton of this package is given below.

         1with0 IO_EXCEPTIONS;
         1generic
0            1type0 ELEMENT_TYPE 1is0 1private0;
         1package0 SEQUENTIAL_IO 1is
0            1type0 FILE_TYPE 1is0 1limited0 1private0;

            1type0 FILE_MODE 1is0 (IN_FILE, OUT_FILE);
            ...
            1procedure0 OPEN   (FILE : 1in0 1out0 FILE_TYPE; ...);
            ...
            1procedure0 READ   (FILE : 1in0 FILE_TYPE; ITEM : 1out0 ELEMENT_TYPE);
            1procedure0 WRITE  (FILE : 1in0 FILE_TYPE; ITEM : 1in0 ELEMENT_TYPE);
            ...
         1end0 SEQUENTIAL_IO;

     In order to define sequential input-output for a given element type, an instantiation of this generic
     unit, with the given type as actual parameter, must be declared.  The resulting package contains the
     declaration of a file type (called FILE_TYPE) for files of such elements, as well as the operations
     applicable to these files, such as the OPEN, READ, and WRITE procedures.

     Input-output for direct access files is likewise defined by a generic package called DIRECT_IO.
     Input-output in human-readable form is defined by the (nongeneric) package TEXT_IO.

     Before input or output operations can be performed on a file, the file must first be associated with an
     external file.  While such an association is in effect, the file is said to be 6open0, and otherwise
     the file is said to be 6closed0.

     The language does not define what happens to external files after the completion of the main program (in
     particular, if corresponding files have not been closed).  The effect of input-output for access types is
     implementation-dependent.

     An open file has a 6current0 6mode0, which is a value of one of the enumeration types
         1type0 FILE_MODE 1is0 (IN_FILE, INOUT_FILE, OUT_FILE);    6--  for DIRECT0_6IO
0         1type0 FILE_MODE 1is0 (IN_FILE, OUT_FILE);                    6--  for SEQUENTIAL0_6IO and TEXT0_6IO

0     These values correspond respectively to the cases where only reading, both reading and writing, or only
     writing are to be performed.  The mode of a file can be changed.

     Several file management operations are common to the three input-output packages.  These operations are
     described in section 14.2.1 for sequential and direct files.  Any additional effects concerning text
     input-output are described in section 14.3.1.

     The exceptions that can be raised by a call of an input-output subprogram are all defined in the package
     IO_EXCEPTIONS; the situations in which they can be raised are described, either following the description
     of the subprogram (and in section 14.4), or in Appendix F in the case of error situations that are
     implementation-dependent.

     6Notes:

0     Each instantiation of the generic packages SEQUENTIAL_IO and DIRECT_IO declares a different type
     FILE_TYPE; in the case of TEXT_IO, the type FILE_TYPE is unique.

     A bidirectional device can often be modeled as two sequential files associated with the device, one of
     mode IN_FILE, and one of mode OUT_FILE.  An implementation may restrict the number of files that may be
     associated with a given external file.  The effect of sharing an external file in this way by several
     file objects is implementation-dependent.

     6References:0 4 create procedure 14.2.1, current index 14.2, current size 14.2, delete procedure
     14.2.1, direct access 14.2, direct file procedure 14.2, direct0_4io package 14.1 14.2, enumeration type
     3.5.1, exception 11, file mode 14.2.3, generic instantiation 12.3, index 14.2, input file 14.2.2,
     io0_4exceptions package 14.5, open file 14.1, open procedure 14.2.1, output file 14.2.2, read procedure
     14.2.4, sequential access 14.2, sequential file 14.2, sequential input-output 14.2.2, sequential0_4io
     package 14.2 14.2.2, string 3.6.3, text0_4io package 14.3, write procedure 14.2.40

      section lrm-section14-2

     214.2. Sequential and Direct Files

0     Two kinds of access to external files are defined:  6sequential0 6access0 and 6direct0 6access0.
     The corresponding file types and the associated operations are provided by the generic packages
     SEQUENTIAL_IO and DIRECT_IO.  A file object to be used for sequential access is called a 6sequential
0     6file0, and one to be used for direct access is called a 6direct0 6file0.

     For sequential access, the file is viewed as a sequence of values that are transferred in the order of
     their appearance (as produced by the program or by the environment).  When the file is opened, transfer
     starts from the beginning of the file.

     For direct access, the file is viewed as a set of elements occupying consecutive positions in linear
     order; a value can be transferred to or from an element of the file at any selected position.  The
     position of an element is specified by its 6index0, which is a number, greater than zero, of the
     implementation-defined integer type COUNT.  The first element, if any, has index one; the index of the
     last element, if any, is called the 6current0 6size0; the current size is zero if there are no
     elements.  The current size is a property of the external file.

     An open direct file has a 6current0 6index0, which is the index that will be used by the next read or
     write operation.  When a direct file is opened, the current index is set to one.  The current index of a
     direct file is a property of a file object, not of an external file.

     All three file modes are allowed for direct files.  The only allowed modes for sequential files are the
     modes IN_FILE and OUT_FILE.

     6References:0 4 count type 14.3, file mode 14.1, in0_4file 14.1, out0_4file 14.10

      subsection lrm-section14-2-1



     714.2.1. File Management

0     The procedures and functions described in this section provide for the control of external files; their
     declarations are repeated in each of the three packages for sequential, direct, and text input-output.
     For text input-output, the procedures CREATE, OPEN, and RESET have additional effects described in
     section 14.3.1.

         1procedure0 CREATE
                 (FILE : 1in0 1out0 FILE_TYPE;
                  MODE : 1in0 FILE_MODE := 6default0_6mode0;
                  NAME : 1in0 STRING := "";
                  FORM : 1in0 STRING := "");

             Establishes a new external file, with the given name and form, and associates this external file
             with the given file.  The given file is left open.  The current mode of the given file is set to
             the given access mode.  The default access mode is the mode OUT_FILE for sequential and text
             input-output; it is the mode INOUT_FILE for direct input-output.  For direct access, the size of
             the created file is implementation-dependent.  A null string for NAME specifies an external file
             that is not accessible after the completion of the main program (a temporary file).  A null
             string for FORM specifies the use of the default options of the implementation for the external
             file.

     The exception STATUS_ERROR is raised if the given file is already open.  The exception NAME_ERROR is
     raised if the string given as NAME does not allow the identification of an external file.  The exception
     USE_ERROR is raised if, for the specified mode, the environment does not support creation of an external
     file with the given name (in the absence of NAME_ERROR) and form.

         1procedure0 OPEN
                 (FILE : 1in0 1out0 FILE_TYPE;
                  MODE : 1in0 FILE_MODE;
                  NAME : 1in0 STRING;
                  FORM : 1in0 STRING := "");

             Associates the given file with an existing external file having the given name and form, and sets
             the current mode of the given file to the given mode.  The given file is left open.

             The exception STATUS_ERROR is raised if the given file is already open.  The exception NAME_ERROR
             is raised if the string given as NAME does not allow the identification of an external file; in
             particular, this exception is raised if no external file with the given name exists.  The
             exception USE_ERROR is raised if, for the specified mode, the environment does not support
             opening for an external file with the given name (in the absence of NAME_ERROR) and form.

         1procedure0 CLOSE(FILE : 1in0 1out0 FILE_TYPE);

             Severs the association between the given file and its associated external file.  The given file
             is left closed.

             The exception STATUS_ERROR is raised if the given file is not open.

         1procedure0 DELETE(FILE : 1in0 1out0 FILE_TYPE);

             Deletes the external file associated with the given file.  The given file is closed, and the
             external file ceases to exist.

             The exception STATUS_ERROR is raised if the given file is not open.  The exception USE_ERROR is
             raised if (as fully defined in Appendix F) deletion of the external file is not supported by the
             environment.

         1procedure0 RESET(FILE : 1in0 1out0 FILE_TYPE; MODE : 1in0 FILE_MODE);
         1procedure0 RESET(FILE : 1in0 1out0 FILE_TYPE);

             Resets the given file so that reading from or writing to its elements can be restarted from the
             beginning of the file; in particular, for direct access this means that the current index is set
             to one.  If a MODE parameter is supplied, the current mode of the given file is set to the given
             mode.

             The exception STATUS_ERROR is raised if the file is not open.  The exception USE_ERROR is raised
             if the environment does not support resetting for the external file and, also, if the environment
             does not support resetting to the specified mode for the external file.

         1function0 MODE(FILE : 1in0 FILE_TYPE) 1return0 FILE_MODE;

             Returns the current mode of the given file.

             The exception STATUS_ERROR is raised if the file is not open.

         1function0 NAME(FILE : 1in0 FILE_TYPE)    1return0 STRING;

             Returns a string which uniquely identifies the external file currently associated with the given
             file (and may thus be used in an OPEN operation).  If an environment allows alternative
             specifications of the name (for example, abbreviations), the string returned by the function
             should correspond to a full specification of the name.

             The exception STATUS_ERROR is raised if the given file is not open.

         1function0 FORM(FILE : 1in0 FILE_TYPE)    1return0 STRING;

             Returns the form string for the external file currently associated with the given file.  If an
             environment allows alternative specifications of the form (for example, abbreviations using
             default options), the string returned by the function should correspond to a full specification
             (that is, it should indicate explicitly all options selected, including default options).

             The exception STATUS_ERROR is raised if the given file is not open.

         1function0 IS_OPEN(FILE : 1in0 FILE_TYPE)    1return0 BOOLEAN;

             Returns TRUE if the file is open (that is, if it is associated with an external file), otherwise
             returns FALSE.

     6References:0 4 current mode 14.1, current size 14.1, closed file 14.1, direct access 14.2, external
     file 14.1, file 14.1, file0_4mode type 14.1, file0_4type type 14.1, form string 14.1, inout0_4file
     14.2.4, mode 14.1, name string 14.1, name0_4error exception 14.4, open file 14.1, out0_4file 14.1,
     status0_4error exception 14.4, use0_4error exception 14.40

      subsection lrm-section14-2-2



     714.2.2. Sequential Input-Output

0     The operations available for sequential input and output are described in this section.  The exception
     STATUS_ERROR is raised if any of these operations is attempted for a file that is not open.

         1procedure0 READ(FILE : 1in0 FILE_TYPE;   ITEM : 1out0 ELEMENT_TYPE);

             Operates on a file of mode IN_FILE.  Reads an element from the given file, and returns the value
             of this element in the ITEM parameter.

             The exception MODE_ERROR is raised if the mode is not IN_FILE.  The exception END_ERROR is raised
             if no more elements can be read from the given file.  The exception DATA_ERROR is raised if the
             element read cannot be interpreted as a value of the type ELEMENT_TYPE; however, an
             implementation is allowed to omit this check if performing the check is too complex.

         1procedure0 WRITE(FILE : 1in0 FILE_TYPE;  ITEM : 1in0 ELEMENT_TYPE);

             Operates on a file of mode OUT_FILE.  Writes the value of ITEM to the given file.

             The exception MODE_ERROR is raised if the mode is not OUT_FILE.  The exception USE_ERROR is
             raised if the capacity of the external file is exceeded.

         1function0 END_OF_FILE(FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;

             Operates on a file of mode IN_FILE.  Returns TRUE if no more elements can be read from the given
             file; otherwise returns FALSE.

             The exception MODE_ERROR is raised if the mode is not IN_FILE.

     6References:0 4 data0_4error exception 14.4, element 14.1, element0_4type 14.1, end0_4error
     exception 14.4, external file 14.1, file 14.1, file mode 14.1, file0_4type 14.1, in0_4file 14.1,
     mode0_4error exception 14.4, out0_4file 14.1, status0_4error exception 14.4, use0_4error
     exception 14.40

      subsection lrm-section14-2-3



     714.2.3. Specification of the Package Sequential_IO

0         1with0 IO_EXCEPTIONS;
         1generic
0            1type0 ELEMENT_TYPE 1is0 1private0;
         1package0 SEQUENTIAL_IO 1is

0            1type0 FILE_TYPE    1is0 1limited0 1private0;

            1type0 FILE_MODE 1is0 (IN_FILE, OUT_FILE);


            -- FILE MANAGEMENT

            1procedure0 CREATE
               (FILE  : 1in0 1out0 FILE_TYPE;
                MODE  : 1in0 FILE_MODE   := OUT_FILE;
                NAME  : 1in0 STRING := "";
                FORM  : 1in0 STRING := "");

            1procedure0 OPEN
               (FILE  : 1in0 1out0 FILE_TYPE;
                MODE  : 1in0 FILE_MODE  ;
                NAME  : 1in0 STRING;
                FORM  : 1in0 STRING := "");

            1procedure0 CLOSE  (FILE : 1in0 1out0 FILE_TYPE);
            1procedure0 DELETE (FILE : 1in0 1out0 FILE_TYPE);
            1procedure0 RESET  (FILE : 1in0 1out0 FILE_TYPE; MODE : 1in0 FILE_MODE);
            1procedure0 RESET  (FILE : 1in0 1out0 FILE_TYPE);

            1function0 MODE (FILE : 1in0 FILE_TYPE) 1return0 FILE_MODE;
            1function0 NAME (FILE : 1in0 FILE_TYPE) 1return0 STRING;
            1function0 FORM (FILE : 1in0 FILE_TYPE) 1return0 STRING;

            1function0 IS_OPEN (FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;

            -- INPUT 1and0 OUTPUT OPERATIONS

            1procedure0 READ   (FILE : 1in0 FILE_TYPE; ITEM : 1out0 ELEMENT_TYPE);
            1procedure0 WRITE  (FILE : 1in0 FILE_TYPE; ITEM : 1in0 ELEMENT_TYPE);

            1function0 END_OF_FILE(FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;

            -- EXCEPTIONS

            STATUS_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.STATUS_ERROR;
            MODE_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.MODE_ERROR;
            NAME_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.NAME_ERROR;
            USE_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.USE_ERROR;
            DEVICE_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.DEVICE_ERROR;
            END_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.END_ERROR;
            DATA_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.DATA_ERROR;

         1private
0            -- IMPLEMENTATION-DEPENDENT
         1end0 SEQUENTIAL_IO;


     6References:0 4 close procedure 14.2.1, create procedure 14.2.1, data0_4error exception 14.4, delete
     procedure 14.2.1, device0_4error exception 14.4, end0_4error exception 14.4, end0_4of0_4file
     function 14.2.2, file0_4mode 14.1, file0_4type 14.1, form function 14.2.1, in0_4file 14.1,
     io0_4exceptions 14.4, is0_4open function 14.2.1, mode function 14.2.1, mode0_4error exception 14.4,
     name function 14.2.1, name0_4error exception 14.4, open procedure 14.2.1, out0_4file 14.1, read
     procedure 14.2.2, reset procedure 14.2.1, sequential0_4io package 14.2 14.2.2, status0_4error
     exception 14.4, use0_4error exception 14.4, write procedure 14.2.2, 0

      subsection lrm-section14-2-4



     714.2.4. Direct Input-Output

0     The operations available for direct input and output are described in this section.  The exception
     STATUS_ERROR is raised if any of these operations is attempted for a file that is not open.

         1procedure0 READ
                 (FILE : 1in0 FILE_TYPE; ITEM : 1out0 ELEMENT_TYPE;
                  FROM : 1in0 POSITIVE_COUNT);
         1procedure0 READ(FILE : 1in0 FILE_TYPE; ITEM : 1out0 ELEMENT_TYPE);

             Operates on a file of mode IN_FILE or INOUT_FILE.  In the case of the first form, sets the
             current index of the given file to the index value given by the parameter FROM.  Then (for both
             forms) returns, in the parameter ITEM, the value of the element whose position in the given file
             is specified by the current index of the file; finally, increases the current index by one.

             The exception MODE_ERROR is raised if the mode of the given file is OUT_FILE.  The exception
             END_ERROR is raised if the index to be used exceeds the size of the external file.  The exception
             DATA_ERROR is raised if the element read cannot be interpreted as a value of the type
             ELEMENT_TYPE; however, an implementation is allowed to omit this check if performing the check is
             too complex.

         1procedure0 WRITE
                 (FILE : 1in0 FILE_TYPE; ITEM : 1in0 ELEMENT_TYPE;
                  TO : 1in0 POSITIVE_COUNT);
         1procedure0 WRITE(FILE : 1in0 FILE_TYPE; ITEM : 1in0 ELEMENT_TYPE);

             Operates on a file of mode INOUT_FILE or OUT_FILE.  In the case of the first form, sets the index
             of the given file to the index value given by the parameter TO.  Then (for both forms) gives the
             value of the parameter ITEM to the element whose position in the given file is specified by the
             current index of the file; finally, increases the current index by one.

             The exception MODE_ERROR is raised if the mode of the given file is IN_FILE.  The exception
             USE_ERROR is raised if the capacity of the external file is exceeded.

         1procedure0 SET_INDEX(FILE : 1in0 FILE_TYPE; TO : 1in0 POSITIVE_COUNT);

             Operates on a file of any mode.  Sets the current index of the given file to the given index
             value (which may exceed the current size of the file).

         1function0 INDEX(FILE : 1in0 FILE_TYPE) 1return0 POSITIVE_COUNT;

             Operates on a file of any mode.  Returns the current index of the given file.

         1function0 SIZE(FILE : 1in0 FILE_TYPE) 1return0 COUNT;
             Operates on a file of any mode.  Returns the current size of the external file that is associated
             with the given file.

         1function0 END_OF_FILE(FILE : 1in0 FILE_TYPE)   1return0 BOOLEAN;

             Operates on a file of mode IN_FILE or INOUT_FILE.  Returns TRUE if the current index exceeds the
             size of the external file; otherwise returns FALSE.

             The exception MODE_ERROR is raised if the mode of the given file is OUT_FILE.

     6References:0 4 count type 14.2, current index 14.2, current size 14.2, data0_4error exception 14.4,
     element 14.1, element0_4type 14.1, end0_4error exception 14.4, external file 14.1, file 14.1, file
     mode 14.1, file0_4type 14.1, in0_4file 14.1, index 14.2, inout0_4file 14.1, mode0_4error
     exception 14.4, open file 14.1, positive0_4count 14.3, status0_4error exception 14.4, use0_4error
     exception 14.4 0

      subsection lrm-section14-2-5



     714.2.5. Specification of the Package Direct_IO

0         1with0 IO_EXCEPTIONS;
         1generic
0            1type0 ELEMENT_TYPE 1is0 1private0;
         1package0 DIRECT_IO 1is

0            1type0 FILE_TYPE    1is0 1limited0 1private0;

            TYPE   FILE_MODE   1is0 (IN_FILE, INOUT_FILE, OUT_FILE);
            TYPE   COUNT    1is0 1range0 0 .. 6implementation0_6defined0;
            SUBTYPE   POSITIVE_COUNT 1is0 COUNT 1range0 1 .. COUNT'LAST;


            -- FILE MANAGEMENT

            1procedure0 CREATE
                  (  FILE   : 1in0 1out0 FILE_TYPE;
                  MODE   : 1in0 FILE_MODE := INOUT_FILE;
                  NAME   : 1in0 STRING := "";
                  FORM   : 1in0 STRING := "");

            1procedure0 OPEN
               (  FILE   : 1in0 1out0 FILE_TYPE;
                  MODE   : 1in0 FILE_MODE;
                  NAME   : 1in0 STRING;
                  FORM   : 1in0 STRING := "");

            1procedure0 CLOSE  (FILE : 1in0 1out0 FILE_TYPE);
            1procedure0 DELETE (FILE : 1in0 1out0 FILE_TYPE);
            1procedure0 RESET  (FILE : 1in0 1out0 FILE_TYPE; MODE : 1in0 FILE_MODE);
            1procedure0 RESET  (FILE : 1in0 1out0 FILE_TYPE);

            1function0 MODE (FILE : 1in0 FILE_TYPE) 1return0 FILE_MODE;
            1function0 NAME (FILE : 1in0 FILE_TYPE) 1return0 STRING;
            1function0 FORM (FILE : 1in0 FILE_TYPE) 1return0 STRING;

            1function0 IS_OPEN (FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;

            6-- Input and output operations

0            1procedure0 READ(FILE: 1in0 FILE_TYPE; ITEM: 1out0 ELEMENT_TYPE; FROM : POSITIVE_COUNT);
            1procedure0 READ(FILE: 1in0 FILE_TYPE; ITEM: 1out0 ELEMENT_TYPE);

            1procedure0 WRITE(FILE: 1in0 FILE_TYPE; ITEM: 1in0 ELEMENT_TYPE; TO : POSITIVE_COUNT);
            1procedure0 WRITE(FILE: 1in0 FILE_TYPE; ITEM: 1in0 ELEMENT_TYPE);

            1procedure0 SET_INDEX(FILE: 1in0 FILE_TYPE; TO: 1in0 POSITIVE_COUNT);

            1function0 INDEX(FILE: 1in0 FILE_TYPE) 1return0 POSITIVE_COUNT;
            1function0 SIZE(FILE: 1in0 FILE_TYPE) 1return0 COUNT;

            1function0 END_OF_FILE(FILE: 1in0 FILE_TYPE) 1return0 BOOLEAN;

            -- EXCEPTIONS

            STATUS_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.STATUS_ERROR;
            MODE_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.MODE_ERROR;
            NAME_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.NAME_ERROR;
            USE_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.USE_ERROR;
            DEVICE_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.DEVICE_ERROR;
            END_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.END_ERROR;
            DATA_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.DATA_ERROR;

         1private
0            -- IMPLEMENTATION-DEPENDENT
         1end0 DIRECT_IO;


     6References0 4 close procedure 14.2.1, count type 14.2, create procedure 14.2.1, data_error exception
     14.4, default_mode 14.2.5, delete procedure 14.2.1, device_error exception 14.4, element_type 14.2.4,
     end_error exception 14.4, end_of_file function 14.2.4, file_mode 14.2.5, file_type 14.2.4, form function
     14.2.1, in_file 14.2.4, index function 14.2.4, inout_file 14.2.4 14.2.1, io_exceptions package 14.4,
     is_open function 14.2.1, mode function 14.2.1, mode_error exception 14.4, name function 14.2.1,
     name_error exception 14.4, open procedure 14.2.1, out_file 14.2.1, read procedure 14.2.4, set_index
     procedure 14.2.4, size function 14.2.4, status_error exception 14.4, use_error exception 14.4, write
     procedure 14.2.4 14.2.1 0

      section lrm-section14-3

     214.3. Text Input-Output

0     This section describes the package TEXT_IO, which provides facilities for input and output in
     human-readable form.  Each file is read or written sequentially, as a sequence of characters grouped into
     lines, and as a sequence of lines grouped into pages.  The specification of the package is given below in
     section 14.3.10.

     The facilities for file management given above, in sections 14.2.1 and 14.2.2, are available for text
     input-output.  In place of READ and WRITE, however, there are procedures GET and PUT that input values of
     suitable types from text files, and output values to them.  These values are provided to the PUT
     procedures, and returned by the GET procedures, in a parameter ITEM.  Several overloaded procedures of
     these names exist, for different types of ITEM.  These GET procedures analyze the input sequences of
     characters as lexical elements (see Chapter 2) and return the corresponding values; the PUT procedures
     output the given values as appropriate lexical elements.  Procedures GET and PUT are also available that
     input and output individual characters treated as character values rather than as lexical elements.

     In addition to the procedures GET and PUT for numeric and enumeration types of ITEM that operate on text
     files, analogous procedures are provided that read from and write to a parameter of type STRING.  These
     procedures perform the same analysis and composition of character sequences as their counterparts which
     have a file parameter.

     For all GET and PUT procedures that operate on text files, and for many other subprograms, there are
     forms with and without a file parameter.  Each such GET procedure operates on an input file, and each
     such PUT procedure operates on an output file.  If no file is specified, a default input file or a
     default output file is used.

     At the beginning of program execution the default input and output files are the so-called standard input
     file and standard output file.  These files are open, have respectively the current modes IN_FILE and
     OUT_FILE, and are associated with two implementation-defined external files.  Procedures are provided to
     change the current default input file and the current default output file.

     From a logical point of view, a text file is a sequence of pages, a page is a sequence of lines, and a
     line is a sequence of characters; the end of a line is marked by a 6line0 6terminator0; the end of a
     page is marked by the combination of a line terminator immediately followed by a 6page0 6terminator0;
     and the end of a file is marked by the combination of a line terminator immediately followed by a page
     terminator and then a 6file0 6terminator0.  Terminators are generated during output; either by calls
     of procedures provided expressly for that purpose; or implicitly as part of other operations, for
     example, when a bounded line length, a bounded page length, or both, have been specified for a file.

     The actual nature of terminators is not defined by the language and hence depends on the implementation.
     Although terminators are recognized or generated by certain of the procedures that follow, they are not
     necessarily implemented as characters or as sequences of characters.  Whether they are characters (and if
     so which ones) in any particular implementation need not concern a user who neither explicitly outputs
     nor explicitly inputs control characters.  The effect of input or output of control characters (other
     than horizontal tabulation) is not defined by the language.

     The characters of a line are numbered, starting from one; the number of a character is called its
     6column0 6number0.  For a line terminator, a column number is also defined:  it is one more than the
     number of characters in the line.  The lines of a page, and the pages of a file, are similarly numbered.
     The 6current0 6column0 6number0 is the column number of the next character or line terminator to be
     transferred.  The 6current0 6line0 6number0 is the number of the current line.  The 6current
0     6page0 6number0 is the number of the current page.  These numbers are values of the subtype
     POSITIVE_COUNT of the type COUNT (by convention, the value zero of the type COUNT is used to indicate
     special conditions).

         1type0 COUNT 1is0 1range0 0 .. 6implementation0_6defined0;
         1subtype0 POSITIVE_COUNT 1is0 COUNT 1range0 1 .. COUNT'LAST;

     For an output file, a 6maximum0 6line0 6length0 can be specified and a 6maximum0 6page
0     6length0 can be specified.  If a value to be output cannot fit on the current line, for a specified
     maximum line length, then a new line is automatically started before the value is output; if, further,
     this new line cannot fit on the current page, for a specified maximum page length, then a new page is
     automatically started before the value is output.  Functions are provided to determine the maximum line
     length and the maximum page length.  When a file is opened with mode OUT_FILE, both values are zero:  by
     convention, this means that the line lengths and page lengths are unbounded.  (Consequently, output
     consists of a single line if the subprograms for explicit control of line and page structure are not
     used.)  The constant UNBOUNDED is provided for this purpose.

     6References:0 4 count type 14.3.10, default current input file 14.3.2, default current output file
     14.3.2, external file 14.1, file 14.1, get procedure 14.3.5, in0_4file 14.1, out0_4file 14.1, put
     procedure 14.3.5, read 14.2.2, sequential access 14.1, standard input file 14.3.2, standard output file
     14.3.20

      subsection lrm-section14-3-1



     714.3.1. File Management

0     The only allowed file modes for text files are the modes IN_FILE and OUT_FILE.  The subprograms given in
     section 14.2.1 for the control of external files, and the function END_OF_FILE given in section 14.2.2
     for sequential input-output, are also available for text files.  There is also a version of END_OF_FILE
     that refers to the current default input file.  For text files, the procedures have the following
     additional effects:

        - For the procedures CREATE and OPEN:  After opening a file with mode OUT_FILE, the page length
          and line length are unbounded (both have the conventional value zero).  After opening a file
          with mode IN_FILE or OUT_FILE, the current column, current line, and current page numbers are
          set to one.

        - For the procedure CLOSE:  If the file has the current mode OUT_FILE, has the effect of calling
          NEW_PAGE, unless the current page is already terminated; then outputs a file terminator.

        - For the procedure RESET:  If the file has the current mode OUT_FILE, has the effect of calling
          NEW_PAGE, unless the current page is already terminated; then outputs a file terminator.  If
          the new file mode is OUT_FILE, the page and line lengths are unbounded.  For all modes, the
          current column, line, and page numbers are set to one.

     The exception MODE_ERROR is raised by the procedure RESET upon an attempt to change the mode of a file
     that is either the current default input file, or the current default output file.

     6References:0 4 create procedure 14.2.1, current column number 14.3, current default input file 14.3,
     current line number 14.3, current page number 14.3, end0_4of0_4file 14.3, external file 14.1, file
     14.1, file mode 14.1, file terminator 14.3, in0_4file 14.1, line length 14.3, mode0_4error exception
     14.4, open procedure 14.2.1, out0_4file 14.1, page length 14.3, reset procedure 14.2.10

      subsection lrm-section14-3-2



     714.3.2.  Default Input and Output Files

0     The following subprograms provide for the control of the particular default files that are used when a
     file parameter is omitted from a GET, PUT or other operation of text input-output described below.

         1procedure0 SET_INPUT(FILE : 1in0 FILE_TYPE);

             Operates on a file of mode IN_FILE.  Sets the current default input file to FILE.

             The exception STATUS_ERROR is raised if the given file is not open.  The exception MODE_ERROR is
             raised if the mode of the given file is not IN_FILE.

         1procedure0 SET_OUTPUT(FILE : 1in0 FILE_TYPE);

             Operates on a file of mode OUT_FILE.  Sets the current default output file to FILE.

             The exception STATUS_ERROR is raised if the given file is not open.  The exception MODE_ERROR is
             raised if the mode of the given file is not OUT_FILE.

         1function0 STANDARD_INPUT 1return0 FILE_TYPE;

             Returns the standard input file (see 14.3).

         1function0 STANDARD_OUTPUT 1return0 FILE_TYPE;

             Returns the standard output file (see 14.3).

         1function0 CURRENT_INPUT 1return0 FILE_TYPE;

             Returns the current default input file.

         1function0 CURRENT_OUTPUT 1return0 FILE_TYPE;

             Returns the current default output file.

     6Note:

0     The standard input and the standard output files cannot be opened, closed, reset, or deleted, because the
     parameter FILE of the corresponding procedures has the mode 1in0 1out0.

     6References:0 4 current default file 14.3, default file 14.3, file0_4type 14.1, get procedure
     14.3.5, mode0_4error exception 14.4, put procedure 14.3.5, status0_4error exception 14.40

      subsection lrm-section14-3-3



     714.3.3. Specification of Line and Page Lengths

0     The subprograms described in this section are concerned with the line and page structure of a file of
     mode OUT_FILE.  They operate either on the file given as the first parameter, or, in the absence of such
     a file parameter, on the current default output file.  They provide for output of text with a specified
     maximum line length or page length.  In these cases, line and page terminators are output implicitly and
     automatically when needed.  When line and page lengths are unbounded (that is, when they have the
     conventional value zero), as in the case of a newly opened file, new lines and new pages are only started
     when explicitly called for.

     In all cases, the exception STATUS_ERROR is raised if the file to be used is not open; the exception
     MODE_ERROR is raised if the mode of the file is not OUT_FILE.

         1procedure0 SET_LINE_LENGTH(FILE   : 1in0 FILE_TYPE; TO : 1in0 COUNT);
         1procedure0 SET_LINE_LENGTH(TO  : 1in0 COUNT);

             Sets the maximum line length of the specified output file to the number of characters specified
             by TO.  The value zero for TO specifies an unbounded line length.

             The exception USE_ERROR is raised if the specified line length is inappropriate for the
             associated external file.

         1procedure0 SET_PAGE_LENGTH (FILE  : 1in0 FILE_TYPE; TO : 1in0 COUNT);
         1procedure0 SET_PAGE_LENGTH (TO    : 1in0 COUNT);

             Sets the maximum page length of the specified output file to the number of lines specified by TO.
             The value zero for TO specifies an unbounded page length.

             The exception USE_ERROR is raised if the specified page length is inappropriate for the
             associated external file.

         1function0 LINE_LENGTH(FILE : 1in0 FILE_TYPE) 1return0 COUNT;
         1function0 LINE_LENGTH 1return0 COUNT;

             Returns the maximum line length currently set for the specified output file, or zero if the line
             length is unbounded.

         1function0 PAGE_LENGTH(FILE : 1in0 FILE_TYPE) 1return0 COUNT;
         1function0 PAGE_LENGTH 1return0 COUNT;

             Returns the maximum page length currently set for the specified output file, or zero if the page
             length is unbounded.

     6References:0 4 count type 14.3, current default output file 14.3, external file 14.1, file 14.1,
     file0_4type 14.1, line 14.3, line length 14.3, line terminator 14.3, maximum line length 14.3, maximum
     page length 14.3, mode0_4error exception 14.4, open file 14.1, out0_4file 14.1, page 14.3, page
     length 14.3, page terminator 14.3, status0_4error exception 14.4, unbounded page length 14.3,
     use0_4error exception 14.40

      subsection lrm-section14-3-4



     714.3.4. Operations on Columns, Lines, and Pages

0     The subprograms described in this section provide for explicit control of line and page structure; they
     operate either on the file given as the first parameter, or, in the absence of such a file parameter, on
     the appropriate (input or output) current default file.  The exception STATUS_ERROR is raised by any of
     these subprograms if the file to be used is not open.

         1procedure0 NEW_LINE(FILE : 1in0 FILE_TYPE; SPACING : 1in0 POSITIVE_COUNT := 1);
         1procedure0 NEW_LINE(SPACING : 1in0 POSITIVE_COUNT := 1);

             Operates on a file of mode OUT_FILE.

             For a SPACING of one:  Outputs a line terminator and sets the current column number to one.  Then
             increments the current line number by one, except in the case that the current line number is
             already greater than or equal to the maximum page length, for a bounded page length; in that case
             a page terminator is output, the current page number is incremented by one, and the current line
             number is set to one.

             For a SPACING greater than one, the above actions are performed SPACING times.

             The exception MODE_ERROR is raised if the mode is not OUT_FILE.

         1procedure0 SKIP_LINE(FILE   : 1in0 FILE_TYPE; SPACING : 1in0 POSITIVE_COUNT := 1);
         1procedure0 SKIP_LINE(SPACING   : 1in0 POSITIVE_COUNT := 1);

             Operates on a file of mode IN_FILE.

             For a SPACING of one:  Reads and discards all characters until a line terminator has been read,
             and then sets the current column number to one.  If the line terminator is not immediately
             followed by a page terminator, the current line number is incremented by one.  Otherwise, if the
             line terminator is immediately followed by a page terminator, then the page terminator is
             skipped, the current page number is incremented by one, and the current line number is set to
             one.

             For a SPACING greater than one, the above actions are performed SPACING times.

             The exception MODE_ERROR is raised if the mode is not IN_FILE.  The exception END_ERROR is raised
             if an attempt is made to read a file terminator.

         1function0 END_OF_LINE(FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;
         1function0 END_OF_LINE 1return0 BOOLEAN;

             Operates on a file of mode IN_FILE.  Returns TRUE if a line terminator or a file terminator is
             next; otherwise returns FALSE.

             The exception MODE_ERROR is raised if the mode is not IN_FILE.

         1procedure0 NEW_PAGE(FILE : 1in0 FILE_TYPE);
         1procedure0 NEW_PAGE;

             Operates on a file of mode OUT_FILE.  Outputs a line terminator if the current line is not
             terminated, or if the current page is empty (that is, if the current column and line numbers are
             both equal to one).  Then outputs a page terminator, which terminates the current page.  Adds one
             to the current page number and sets the current column and line numbers to one.

             The exception MODE_ERROR is raised if the mode is not OUT_FILE.

         1procedure0 SKIP_PAGE(FILE  : 1in0 FILE_TYPE);
         1procedure0 SKIP_PAGE;

             Operates on a file of mode IN_FILE.  Reads and discards all characters and line terminators until
             a page terminator has been read.  Then adds one to the current page number, and sets the current
             column and line numbers to one.

             The exception MODE_ERROR is raised if the mode is not IN_FILE.  The exception END_ERROR is raised
             if an attempt is made to read a file terminator.

         1function0 END_OF_PAGE(FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;
         1function0 END_OF_PAGE 1return0 BOOLEAN;

             Operates on a file of mode IN_FILE.  Returns TRUE if the combination of a line terminator and a
             page terminator is next, or if a file terminator is next; otherwise returns FALSE.

             The exception MODE_ERROR is raised if the mode is not IN_FILE.

         1function0 END_OF_FILE(FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;
         1function0 END_OF_FILE 1return0 BOOLEAN;

             Operates on a file of mode IN_FILE.  Returns TRUE if a file terminator is next, or if the
             combination of a line, a page, and a file terminator is next; otherwise returns FALSE.

             The exception MODE_ERROR is raised if the mode is not IN_FILE.

     The following subprograms provide for the control of the current position of reading or writing in a
     file.  In all cases, the default file is the current output file.
         1procedure0 SET_COL(FILE  : 1in0 FILE_TYPE; TO : 1in0 POSITIVE_COUNT);
         1procedure0 SET_COL(TO    : 1in0 POSITIVE_COUNT);

             If the file mode is OUT_FILE:

                     If the value specified by TO is greater than the current column number, outputs spaces,
                     adding one to the current column number after each space, until the current column number
                     equals the specified value.  If the value specified by TO is equal to the current column
                     number, there is no effect.  If the value specified by TO is less than the current column
                     number, has the effect of calling NEW_LINE (with a spacing of one), then outputs (TO - 1)
                     spaces, and sets the current column number to the specified value.

                     The exception LAYOUT_ERROR is raised if the value specified by TO exceeds LINE_LENGTH
                     when the line length is bounded (that is, when it does not have the conventional value
                     zero).

             If the file mode is IN_FILE:

                     Reads (and discards) individual characters, line terminators, and page terminators, until
                     the next character to be read has a column number that equals the value specified by TO;
                     there is no effect if the current column number already equals this value.  Each transfer
                     of a character or terminator maintains the current column, line, and page numbers in the
                     same way as a GET procedure (see 14.3.5).  (Short lines will be skipped until a line is
                     reached that has a character at the specified column position.)

                     The exception END_ERROR is raised if an attempt is made to read a file terminator.

         1procedure0 SET_LINE(FILE    : 1in0 FILE_TYPE; TO : 1in0 POSITIVE_COUNT);
         1procedure0 SET_LINE(TO   : 1in0 POSITIVE_COUNT);

             If the file mode is OUT_FILE:

                     If the value specified by TO is greater than the current line number, has the effect of
                     repeatedly calling NEW_LINE (with a spacing of one), until the current line number equals
                     the specified value.  If the value specified by TO is equal to the current line number,
                     there is no effect.  If the value specified by TO is less than the current line number,
                     has the effect of calling NEW_PAGE followed by a call of NEW_LINE with a spacing equal to
                     (TO - 1).

                     The exception LAYOUT_ERROR is raised if the value specified by TO exceeds PAGE_LENGTH
                     when the page length is bounded (that is, when it does not have the conventional value
                     zero).

             If the mode is IN_FILE:

                     Has the effect of repeatedly calling SKIP_LINE (with a spacing of one), until the current
                     line number equals the value specified by TO; there is no effect if the current line
                     number already equals this value.  (Short pages will be skipped until a page is reached
                     that has a line at the specified line position.)

                     The exception END_ERROR is raised if an attempt is made to read a file terminator.

         1function0 COL(FILE : 1in0 FILE_TYPE)  1return0 POSITIVE_COUNT;
         1function0 COL 1return0 POSITIVE_COUNT;

             Returns the current column number.

             The exception LAYOUT_ERROR is raised if this number exceeds COUNT'LAST.

         1function0 LINE(FILE   : 1in0 FILE_TYPE)  1return0 POSITIVE_COUNT;
         1function0 LINE 1return0 POSITIVE_COUNT;

             Returns the current line number.

             The exception LAYOUT_ERROR is raised if this number exceeds COUNT'LAST.
         1function0 PAGE(FILE : 1in0 FILE_TYPE)    1return0 POSITIVE_COUNT;
         1function0 PAGE 1return0 POSITIVE_COUNT;

             Returns the current page number.

             The exception LAYOUT_ERROR is raised if this number exceeds COUNT'LAST.

     The column number, line number, or page number are allowed to exceed COUNT'LAST (as a consequence of the
     input or output of sufficiently many characters, lines, or pages).  These events do not cause any
     exception to be raised.  However, a call of COL, LINE, or PAGE raises the exception LAYOUT_ERROR if the
     corresponding number exceeds COUNT'LAST.

     6Note:

0     A page terminator is always skipped whenever the preceding line terminator is skipped.  An implementation
     may represent the combination of these terminators by a single character, provided that it is properly
     recognized at input.

     6References:0 4 current column number 14.3, current default file 14.3, current line number 14.3,
     current page number 14.3, end0_4error exception 14.4, file 14.1, file terminator 14.3, get procedure
     14.3.5, in0_4file 14.1, layout0_4error exception 14.4, line 14.3, line number 14.3, line terminator
     14.3, maximum page length 14.3, mode0_4error exception 14.4, open file 14.1, page 14.3, page length
     14.3, page terminator 14.3, positive count 14.3, status0_4error exception 14.40

      subsection lrm-section14-3-5



     714.3.5. Get and Put Procedures

0     The procedures GET and PUT for items of the types CHARACTER, STRING, numeric types, and enumeration types
     are described in subsequent sections.  Features of these procedures that are common to most of these
     types are described in this section.  The GET and PUT procedures for items of type CHARACTER and STRING
     deal with individual character values; the GET and PUT procedures for numeric and enumeration types treat
     the items as lexical elements.

     All procedures GET and PUT have forms with a file parameter, written first.  Where this parameter is
     omitted, the appropriate (input or output) current default file is understood to be specified.  Each
     procedure GET operates on a file of mode IN_FILE.  Each procedure PUT operates on a file of mode
     OUT_FILE.

     All procedures GET and PUT maintain the current column, line, and page numbers of the specified file:
     the effect of each of these procedures upon these numbers is the resultant of the effects of individual
     transfers of characters and of individual output or skipping of terminators.  Each transfer of a
     character adds one to the current column number.  Each output of a line terminator sets the current
     column number to one and adds one to the current line number.  Each output of a page terminator sets the
     current column and line numbers to one and adds one to the current page number.  For input, each skipping
     of a line terminator sets the current column number to one and adds one to the current line number; each
     skipping of a page terminator sets the current column and line numbers to one and adds one to the current
     page number.  Similar considerations apply to the procedures GET_LINE, PUT_LINE, and SET_COL.

     Several GET and PUT procedures, for numeric and enumeration types, have 6format0 parameters which
     specify field lengths; these parameters are of the nonnegative subtype FIELD of the type INTEGER.

     Input-output of enumeration values uses the syntax of the corresponding lexical elements.  Any GET
     procedure for an enumeration type begins by skipping any leading blanks, or line or page terminators; a
     6blank0 being defined as a space or a horizontal tabulation character.  Next, characters are input only
     so long as the sequence input is an initial sequence of an identifier or of a character literal (in
     particular, input ceases when a line terminator is encountered).  The character or line terminator that
     causes input to cease remains available for subsequent input.

     For a numeric type, the GET procedures have a format parameter called WIDTH.  If the value given for this
     parameter is zero, the GET procedure proceeds in the same manner as for enumeration types, but using the
     syntax of numeric literals instead of that of enumeration literals.  If a nonzero value is given, then
     exactly WIDTH characters are input, or the characters up to a line terminator, whichever comes first; any
     skipped leading blanks are included in the count.  The syntax used for numeric literals is an extended
     syntax that allows a leading sign (but no intervening blanks, or line or page terminators).

     Any PUT procedure, for an item of a numeric or an enumeration type, outputs the value of the item as a
     numeric literal, identifier, or character literal, as appropriate.  This is preceded by leading spaces if
     required by the format parameters WIDTH or FORE (as described in later sections), and then a minus sign
     for a negative value; for an enumeration type, the spaces follow instead of leading.  The format given
     for a PUT procedure is overridden if it is insufficiently wide.

     Two further cases arise for PUT procedures for numeric and enumeration types, if the line length of the
     specified output file is bounded (that is, if it does not have the conventional value zero).  If the
     number of characters to be output does not exceed the maximum line length, but is such that they cannot
     fit on the current line, starting from the current column, then (in effect) NEW_LINE is called (with a
     spacing of one) before output of the item.  Otherwise, if the number of characters exceeds the maximum
     line length, then the exception LAYOUT_ERROR is raised and no characters are output.

     The exception STATUS_ERROR is raised by any of the procedures GET, GET_LINE, PUT, and PUT_LINE if the
     file to be used is not open.  The exception MODE_ERROR is raised by the procedures GET and GET_LINE if
     the mode of the file to be used is not IN_FILE; and by the procedures PUT and PUT_LINE, if the mode is
     not OUT_FILE.

     The exception END_ERROR is raised by a GET procedure if an attempt is made to skip a file terminator.
     The exception DATA_ERROR is raised by a GET procedure if the sequence finally input is not a lexical
     element corresponding to the type, in particular if no characters were input; for this test, leading
     blanks are ignored; for an item of a numeric type, when a sign is input, this rule applies to the
     succeeding numeric literal.  The exception LAYOUT_ERROR is raised by a PUT procedure that outputs to a
     parameter of type STRING, if the length of the actual string is insufficient for the output of the item.

     6Examples:

0     In the examples, here and in sections 14.3.7 and 14.3.8, the string quotes and the lower case letter b
     are not transferred:  they are shown only to reveal the layout and spaces.

         N : INTEGER;
            ...
         GET(N);

         -- Characters at input         Sequence input          Value of  N

         --      bb-12535b           -12535            -12535
         --      bb12_535E1b          12_535E1          125350
         --      BB12_535E;           12_535E           (none) DATA_ERROR raised

     6Example0 6of0 6overridden0 6width0 6parameter:

0         PUT(ITEM => -23, WIDTH => 2);   --  "-23"

     6References:0 4 blank 14.3.9, column number 14.3, current default file 14.3, data0_4error exception
     14.4, end0_4error exception 14.4, file 14.1, fore 14.3.8, get procedure 14.3.6 14.3.7 14.3.8 14.3.9,
     in0_4file 14.1, layout0_4error exception 14.4, line number 14.1, line terminator 14.1, maximum line
     length 14.3, mode 14.1, mode0_4error exception 14.4, new0_4file procedure 14.3.4, out0_4file 14.1,
     page number 14.1, page terminator 14.1, put procedure 14.3.6 14.3.7 14.3.8 14.3.9, skipping 14.3.7 14.3.8
     14.3.9, status0_4error exception 14.4, width 14.3.5 14.3.7 14.3.9 0

      subsection lrm-section14-3-6



     714.3.6. Input-Output of Characters and Strings

0     For an item of type CHARACTER the following procedures are provided:

         1procedure0 GET(FILE   : 1in0 FILE_TYPE; ITEM : 1out0 CHARACTER);
         1procedure0 GET(ITEM   : 1out0 CHARACTER);

             After skipping any line terminators and any page terminators, reads the next character from the
             specified input file and returns the value of this character in the 1out0 parameter ITEM.

             The exception END_ERROR is raised if an attempt is made to skip a file terminator.

         1procedure0 PUT(FILE   : 1in0 FILE_TYPE; ITEM : 1in0 CHARACTER);
         1procedure0 PUT(ITEM   : 1in0 CHARACTER);

             If the line length of the specified output file is bounded (that is, does not have the
             conventional value zero), and the current column number exceeds it, has the effect of calling
             NEW_LINE with a spacing of one.  Then, or otherwise, outputs the given character to the file.

     For an item of type STRING the following procedures are provided:

         1procedure0 GET(FILE   : 1in0 FILE_TYPE; ITEM : 1out0 STRING);
         1procedure0 GET(ITEM   : 1out0 STRING);

             Determines the length of the given string and attempts that number of GET operations for
             successive characters of the string (in particular, no operation is performed if the string is
             null).

         1procedure0 PUT(FILE   : 1in0 FILE_TYPE; ITEM : 1in0 STRING);
         1procedure0 PUT(ITEM   : 1in0 STRING);

             Determines the length of the given string and attempts that number of PUT operations for
             successive characters of the string (in particular, no operation is performed if the string is
             null).

         1procedure0 GET_LINE(FILE: 1in0 FILE_TYPE; ITEM: 1out0 STRING; LAST : 1out0 NATURAL);
         1procedure0 GET_LINE(ITEM: 1out0 STRING; LAST: 1out0 NATURAL);

             Replaces successive characters of the specified string by successive characters read from the
             specified input file.  Reading stops if the end of the line is met, in which case the procedure
             SKIP_LINE is then called (in effect) with a spacing of one; reading also stops if the end of the
             string is met.  Characters not replaced are left undefined.

             If characters are read, returns in LAST the index value such that ITEM(LAST) is the last
             character replaced (the index of the first character replaced is ITEM'FIRST).  If no characters
             are read, returns in LAST an index value that is one less than ITEM'FIRST.

             The exception END_ERROR is raised if an attempt is made to skip a file terminator.

         1procedure0 PUT_LINE(FILE : 1in0 FILE_TYPE; ITEM : 1in0 STRING);
         1procedure0 PUT_LINE(ITEM : 1in0 STRING);

             Calls the procedure PUT for the given string, and then the procedure NEW_LINE with a spacing of
             one.

     6Notes:

0     In a literal string parameter of PUT, the enclosing string bracket characters are not output.  Each
     doubled string bracket character in the enclosed string is output as a single string bracket character,
     as a consequence of the rule for string literals (see 2.6).

     A string read by GET or written by PUT can extend over several lines.

     6References:0 4 current column number 14.3, end0_4error exception 14.4, file 14.1, file terminator
     14.3, get procedure 14.3.5, line 14.3, line length 14.3, new0_4line procedure 14.3.4, page terminator
     14.3, put procedure 14.3.4, skipping 14.3.5 0

      subsection lrm-section14-3-7



     714.3.7. Input-Output for Integer Types

0     The following procedures are defined in the generic package INTEGER_IO.  This must be instantiated for
     the appropriate integer type (indicated by NUM in the specification).

     Values are output as decimal or based literals, without underline characters or exponent, and preceded by
     a minus sign if negative.  The format (which includes any leading spaces and minus sign) can be specified
     by an optional field width parameter.  Values of widths of fields in output formats are of the
     nonnegative integer subtype FIELD.  Values of bases are of the integer subtype NUMBER_BASE.

         1subtype0 NUMBER_BASE 1is0 INTEGER 1range0 2 .. 16;

     The default field width and base to be used by output procedures are defined by the following variables
     that are declared in the generic package INTEGER_IO:

         DEFAULT_WIDTH   : FIELD := NUM'WIDTH;
         DEFAULT_BASE    : NUMBER_BASE := 10;

     The following procedures are provided:

         1procedure0 GET(FILE   : 1in0 FILE_TYPE; ITEM : 1out0 NUM; WIDTH : 1in0 FIELD := 0);
         1procedure0 GET(ITEM   : 1out0 NUM; WIDTH : 1in0 FIELD := 0);

             If the value of the parameter WIDTH is zero, skips any leading blanks, line terminators, or page
             terminators, then reads a plus or a minus sign if present, then reads according to the syntax of
             an integer literal (which may be a based literal).  If a nonzero value of WIDTH is supplied, then
             exactly WIDTH characters are input, or the characters (possibly none) up to a line terminator,
             whichever comes first; any skipped leading blanks are included in the count.

             Returns, in the parameter ITEM, the value of type NUM that corresponds to the sequence input.

             The exception DATA_ERROR is raised if the sequence input does not have the required syntax or if
             the value obtained is not of the subtype NUM.

         1procedure0 PUT
               (  FILE   : 1in0 FILE_TYPE;
                   ITEM  : 1in0 NUM;
                   WIDTH    : 1in0 FIELD := DEFAULT_WIDTH;
                   BASE  : 1in0 NUMBER_BASE := DEFAULT_BASE);

         1procedure0 PUT
               (  ITEM   : 1in0 NUM;
                  WIDTH  : 1in0 FIELD := DEFAULT_WIDTH;
                  BASE   : 1in0 NUMBER_BASE := DEFAULT_BASE);

             Outputs the value of the parameter ITEM as an integer literal, with no underlines, no exponent,
             and no leading zeros (but a single zero for the value zero), and a preceding minus sign for a
             negative value.

             If the resulting sequence of characters to be output has fewer than WIDTH characters, then
             leading spaces are first output to make up the difference.

             Uses the syntax for decimal literal if the parameter BASE has the value ten (either explicitly or
             through DEFAULT_BASE); otherwise, uses the syntax for based literal, with any letters in upper
             case.

         1procedure0 GET(FROM : 1in0 STRING; ITEM : 1out0 NUM; LAST : 1out0 POSITIVE);

             Reads an integer value from the beginning of the given string, following the same rules as the
             GET procedure that reads an integer value from a file, but treating the end of the string as a
             file terminator.  Returns, in the parameter ITEM, the value of type NUM that corresponds to the
             sequence input.  Returns in LAST the index value such that FROM(LAST) is the last character read.

             The exception DATA_ERROR is raised if the sequence input does not have the required syntax or if
             the value obtained is not of the subtype NUM.

         1procedure0 PUT
               (  TO  : 1out0 STRING;
                  ITEM   : 1in0 NUM;
                  BASE   : 1in0 NUMBER_BASE := DEFAULT_BASE);
             Outputs the value of the parameter ITEM to the given string, following the same rule as for
             output to a file, using the length of the given string as the value for WIDTH.

     6Examples:

0         1package0 INT_IO 1is0 1new0 INTEGER_IO(SMALL_INT); 1use0 INT_IO;
         6-- Default format used at instantiation, default_width = 4, default_base = 10

0         PUT(126);       6-- "b126"
0         PUT(-126, 7);      6-- "bbb-126"
0         PUT(126, WIDTH => 13, BASE => 2);       6-- "bbb2#1111110#"

0     6References:0 4 based literal 2.4.2, blank 14.3.5, data0_4error exception 14.4, decimal literal
     2.4.1, field subtype 14.3.5, file0_4type 14.1, get procedure 14.3.5, integer0_4io package 14.3.10,
     integer literal 2.4, layout0_4error exception 14.4, line terminator 14.3, put procedure 14.3.5,
     skipping 14.3.5, width 14.3.50

      subsection lrm-section14-3-8



     714.3.8. Input-Output for Real Types

0     The following procedures are defined in the generic packages FLOAT_IO and FIXED_IO, which must be
     instantiated for the appropriate floating point or fixed point type respectively (indicated by NUM in the
     specifications).

     Values are output as decimal literals without underline characters.  The format of each value output
     consists of a FORE field, a decimal point, an AFT field, and (if a nonzero EXP parameter is supplied) the
     letter E and an EXP field.  The two possible formats thus correspond to:

         FORE  .  AFT

     and to:

         FORE  .  AFT  E  EXP

     without any spaces between these fields.  The FORE field may include leading spaces, and a minus sign for
     negative values.  The AFT field includes only decimal digits (possibly with trailing zeros).  The EXP
     field includes the sign (plus or minus) and the exponent (possibly with leading zeros).

     For floating point types, the default lengths of these fields are defined by the following variables that
     are declared in the generic package FLOAT_IO:

         DEFAULT_FORE    : FIELD := 2;
         DEFAULT_AFT  : FIELD := NUM'DIGITS-1;
         DEFAULT_EXP  : FIELD := 3;

     For fixed point types, the default lengths of these fields are defined by the following variables that
     are declared in the generic package FIXED_IO:

         DEFAULT_FORE    : FIELD := NUM'FORE;
         DEFAULT_AFT  : FIELD := NUM'AFT;
         DEFAULT_EXP  : FIELD := 0;

     The following procedures are provided:

         1procedure0 GET(FILE   : 1in0 FILE_TYPE; ITEM : 1out0 NUM; WIDTH : 1in0 FIELD := 0);
         1procedure0 GET(ITEM   : 1out0 NUM; WIDTH : 1in0 FIELD := 0);

             If the value of the parameter WIDTH is zero, skips any leading blanks, line terminators, or page
             terminators, then reads a plus or a minus sign if present, then reads according to the syntax of
             a real literal (which may be a based literal).  If a nonzero value of WIDTH is supplied, then
             exactly WIDTH characters are input, or the characters (possibly none) up to a line terminator,
             whichever comes first; any skipped leading blanks are included in the count.

             Returns, in the parameter ITEM, the value of type NUM that corresponds to the sequence input.

             The exception DATA_ERROR is raised if the sequence input does not have the required syntax or if
             the value obtained is not of the subtype NUM.

         1procedure0 PUT
               (  FILE   : 1in0 FILE_TYPE;
                  ITEM   : 1in0 NUM;
                  FORE   : 1in0 FIELD := DEFAULT_FORE;
                  AFT    : 1in0 FIELD := DEFAULT_AFT;
                  EXP    : 1in0 FIELD := DEFAULT_EXP);

         1procedure0 PUT
               (  ITEM   : 1in0 NUM;
                  FORE   : 1in0 FIELD := DEFAULT_FORE;
                  AFT    : 1in0 FIELD := DEFAULT_AFT;
                  EXP    : 1in0 FIELD := DEFAULT_EXP);

             Outputs the value of the parameter ITEM as a decimal literal with the format defined by FORE, AFT
             and EXP.  If the value is negative, a minus sign is included in the integer part.  If EXP has the
             value zero, then the integer part to be output has as many digits as are needed to represent the
             integer part of the value of ITEM, overriding FORE if necessary, or consists of the digit zero if
             the value of ITEM has no integer part.

             If EXP has a value greater than zero, then the integer part to be output has a single digit,
             which is nonzero except for the value 0.0 of ITEM.

             In both cases, however, if the integer part to be output has fewer than FORE characters,
             including any minus sign, then leading spaces are first output to make up the difference.  The
             number of digits of the fractional part is given by AFT, or is one if AFT equals zero.  The value
             is rounded; a value of exactly one half in the last place may be rounded either up or down.

             If EXP has the value zero, there is no exponent part.  If EXP has a value greater than zero, then
             the exponent part to be output has as many digits as are needed to represent the exponent part of
             the value of ITEM (for which a single digit integer part is used), and includes an initial sign
             (plus or minus).  If the exponent part to be output has fewer than EXP characters, including the
             sign, then leading zeros precede the digits, to make up the difference.  For the value 0.0 of
             ITEM, the exponent has the value zero.

         1procedure0 GET(FROM : 1in0 STRING; ITEM : 1out0 NUM; LAST : 1out0 POSITIVE);

             Reads a real value from the beginning of the given string, following the same rule as the GET
             procedure that reads a real value from a file, but treating the end of the string as a file
             terminator.  Returns, in the parameter ITEM, the value of type NUM that corresponds to the
             sequence input.  Returns in LAST the index value such that FROM(LAST) is the last character read.

             The exception DATA_ERROR is raised if the sequence input does not have the required syntax, or if
             the value obtained is not of the subtype NUM.

         1procedure0 PUT
               (  TO  : 1out0 STRING;
                  ITEM   : 1in0 NUM;
                  AFT    : 1in0 FIELD := DEFAULT_AFT;
                  EXP    : 1in0 INTEGER := DEFAULT_EXP);

             Outputs the value of the parameter ITEM to the given string, following the same rule as for
             output to a file, using a value for FORE such that the sequence of characters output exactly
             fills the string, including any leading spaces.

     6Examples:

0         1package0 REAL_IO 1is0 1new0 FLOAT_IO(REAL); 1use0 REAL_IO;
         -- DEFAULT FORMAT USED 1at0 INSTANTIATION, DEFAULT_EXP = 3

         X : REAL := -123.4567;  6--  digits 8      (see 3.5.7)

0         PUT(X); -- DEFAULT FORMAT        "-1.2345670E+02"
         PUT(X, FORE => 5, AFT => 3, EXP => 2);   --  "BBB-1.235E+2"
         PUT(X, 5, 3, 0);    --  "B-123.457"

     6Note:

0     For an item with a positive value, if output to a string exactly fills the string without leading spaces,
     then output of the corresponding negative value will raise LAYOUT_ERROR.

     6References:0 4 aft attribute 3.5.10, based literal 2.4.2, blank 14.3.5, data0_4error exception
     14.3.5, decimal literal 2.4.1, field subtype 14.3.5, file0_4type 14.1, fixed0_4io package 14.3.10,
     floating0_4io package 14.3.10, fore attribute 3.5.10, get procedure 14.3.5, layout0_4error 14.3.5,
     line terminator 14.3.5, put procedure 14.3.5, real literal 2.4, skipping 14.3.5, width 14.3.5 0

      subsection lrm-section14-3-9



     714.3.9. Input-Output for Enumeration Types

0     The following procedures are defined in the generic package ENUMERATION_IO, which must be instantiated
     for the appropriate enumeration type (indicated by ENUM in the specification).

     Values are output using either upper or lower case letters for identifiers.  This is specified by the
     parameter SET, which is of the enumeration type TYPE_SET.

         1type0 TYPE_SET 1is0 (LOWER_CASE, UPPER_CASE);

     The format (which includes any trailing spaces) can be specified by an optional field width parameter.
     The default field width and letter case are defined by the following variables that are declared in the
     generic package ENUMERATION_IO:

         DEFAULT_WIDTH   : FIELD := 0;
         DEFAULT_SETTING    : TYPE_SET := UPPER_CASE;

     The following procedures are provided:

         1procedure0 GET(FILE   : 1in0 FILE_TYPE; ITEM : 1out0 ENUM);
         1procedure0 GET(ITEM   : 1out0 ENUM);

             After skipping any leading blanks, line terminators, or page terminators, reads an identifier
             according to the syntax of this lexical element (lower and upper case being considered
             equivalent), or a character literal according to the syntax of this lexical element (including
             the apostrophes).  Returns, in the parameter ITEM, the value of type ENUM that corresponds to the
             sequence input.

             The exception DATA_ERROR is raised if the sequence input does not have the required syntax, or if
             the identifier or character literal does not correspond to a value of the subtype ENUM.

         1procedure0 PUT(   FILE   : 1in0 FILE_TYPE;
            ITEM   : 1in0 ENUM;
            WIDTH  : 1in0 FIELD := DEFAULT_WIDTH;
            SET    : 1in0 TYPE_SET := DEFAULT_SETTING);

         1procedure0 PUT(   ITEM   : 1in0 ENUM;
            WIDTH  : 1in0 FIELD := DEFAULT_WIDTH;
            SET    : 1in0 TYPE_SET := DEFAULT_SETTING);

             Outputs the value of the parameter ITEM as an enumeration literal (either an identifier or a
             character literal).  The optional parameter SET indicates whether lower case or upper case is
             used for identifiers; it has no effect for character literals.  If the sequence of characters
             produced has fewer than WIDTH characters, then trailing spaces are finally output to make up the
             difference.

         1procedure0 GET(FROM : 1in0 STRING; ITEM : 1out0 ENUM; LAST : 1out0 POSITIVE);
             Reads an enumeration value from the beginning of the given string, following the same rule as the
             GET procedure that reads an enumeration value from a file, but treating the end of the string as
             a file terminator.  Returns, in the parameter ITEM, the value of type ENUM that corresponds to
             the sequence input.  Returns in LAST the index value such that FROM(LAST) is the last character
             read.

             The exception DATA_ERROR is raised if the sequence input does not have the required syntax, or if
             the identifier or character literal does not correspond to a value of the subtype ENUM.

         1procedure0 PUT(   TO  : 1out0 STRING;
            ITEM   : 1in0 ENUM;
            SET    : 1in0 TYPE_SET := DEFAULT_SETTING);

             Outputs the value of the parameter ITEM to the given string, following the same rule as for
             output to a file, using the length of the given string as the value for WIDTH.

     Although the specification of the package ENUMERATION_IO would allow instantiation for an integer type,
     this is not the intended purpose of this generic package, and the effect of such instantiations is not
     defined by the language.

     6Notes:

0     There is a difference between PUT defined for characters, and for enumeration values.  Thus

         TEXT_IO.PUT('A');   6--  outputs the character A

0         1package0 CHAR_IO 1is0 1new0 TEXT_IO.ENUMERATION_IO(CHARACTER);
         CHAR_IO.PUT('A');   6--  outputs the character 'A', between single quotes

0     The type BOOLEAN is an enumeration type, hence ENUMERATION_IO can be instantiated for this type.

     6References:0 4 blank 14.3.5, data0_4error 14.3.5, enumeration0_4io package 14.3.10, field subtype
     14.3.5, file0_4type 14.1, get procedure 14.3.5, line terminator 14.3.5, put procedure 14.3.5, skipping
     14.3.5, width 14.3.50

      subsection lrm-section14-3-10



     714.3.10. Specification of the Package Text_IO

0         1with0 IO_EXCEPTIONS;
         1package0 TEXT_IO 1is

0            1type0 FILE_TYPE    1is0 1limited0 1private0;

            1type0 FILE_MODE 1is0 (IN_FILE, OUT_FILE);

            1type0 COUNT  1is0 1range0 0 .. 6implementation0_6defined0;
            1subtype0 POSITIVE_COUNT  1is0 COUNT 1range0 1 .. COUNT'LAST;
            UNBOUNDED : 1constant0 COUNT := 0; -- LINE 1and0 PAGE LENGTH

            1subtype0 FIELD  1is0 INTEGER 1range0 0 .. 6implementation0_6defined0;
            1subtype0 NUMBER_BASE  1is0 INTEGER 1range0 2 .. 16;

            1type0 TYPE_SET 1is0 (LOWER_CASE, UPPER_CASE);

            -- FILE MANAGEMENT

            1procedure0 CREATE  ( FILE   : 1in0 1out0 FILE_TYPE;
               MODE   : 1in0 FILE_MODE   := OUT_FILE;
               NAME   : 1in0 STRING   := "";
               FORM   : 1in0 STRING   := "");

            1procedure0 OPEN    ( FILE : 1in0 1out0 FILE_TYPE;
               MODE : 1in0 FILE_MODE;
               NAME : 1in0 STRING;
               FORM : 1in0 STRING := "");

            1procedure0   CLOSE   (FILE : 1in0 1out0 FILE_TYPE);
            1procedure0   DELETE  (FILE : 1in0 1out0 FILE_TYPE);
            1procedure0   RESET   (FILE : 1in0 1out0 FILE_TYPE; MODE : 1in0 FILE_MODE);
            1procedure0   RESET   (FILE : 1in0 1out0 FILE_TYPE);

            1function0    MODE (FILE : 1in0 FILE_TYPE)   1return0 FILE_MODE;
            1function0    NAME (FILE : 1in0 FILE_TYPE)   1return0 STRING;
            1function0    FORM (FILE : 1in0 FILE_TYPE)   1return0 STRING;

            1function0    IS_OPEN (FILE : 1in0 FILE_TYPE)   1return0 BOOLEAN;

            6-- Control of default input and output files

0            1procedure0   SET_INPUT  (FILE : 1in0 FILE_TYPE);
            1procedure0   SET_OUTPUT (FILE : 1in0 FILE_TYPE);


            1function0    STANDARD_INPUT    1return0 FILE_TYPE;
            1function0    STANDARD_OUTPUT   1return0 FILE_TYPE;

            1function0    CURRENT_INPUT  1return0 FILE_TYPE;
            1function0    CURRENT_OUTPUT    1return0 FILE_TYPE;

            6-- Specification of line and page lengths

0            1procedure0   SET_LINE_LENGTH  (FILE : 1in0 FILE_TYPE; TO : 1in0 COUNT);
            1procedure0   SET_LINE_LENGTH  (TO : 1in0 COUNT);

            1procedure0   SET_PAGE_LENGTH  (FILE : 1in0 FILE_TYPE; TO : 1in0 COUNT);
            1procedure0   SET_PAGE_LENGTH  (TO : 1in0 COUNT);

            1function0    LINE_LENGTH   (FILE : 1in0 FILE_TYPE) 1return0 COUNT;
            1function0    LINE_LENGTH    1return0 COUNT;

            1function0    PAGE_LENGTH   (FILE : 1in0 FILE_TYPE) 1return0 COUNT;
            1function0    PAGE_LENGTH    1return0 COUNT;

            6-- Column, line, and page control

0            1procedure0   NEW_LINE   (FILE : 1in0 FILE_TYPE; SPACING : 1in0 POSITIVE_COUNT := 1);
            1procedure0   NEW_LINE   (SPACING : 1in0 POSITIVE_COUNT := 1);

            1procedure0   SKIP_LINE  (FILE : 1in0 FILE_TYPE; SPACING : 1in0 POSITIVE_COUNT := 1);
            1procedure0   SKIP_LINE  (SPACING : 1in0 POSITIVE_COUNT := 1);

            1function0    END_OF_LINE   (FILE : 1in0 FILE_TYPE)   1return0 BOOLEAN;
            1function0    END_OF_LINE    1return0 BOOLEAN;

            1procedure0   NEW_PAGE   (FILE : 1in0 FILE_TYPE);
            1procedure0   NEW_PAGE;

            1procedure0   SKIP_PAGE  (FILE : 1in0 FILE_TYPE);
            1procedure0   SKIP_PAGE;

            1function0    END_OF_PAGE   (FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;
            1function0    END_OF_PAGE    1return0 BOOLEAN;

            1function0    END_OF_FILE   (FILE : 1in0 FILE_TYPE) 1return0 BOOLEAN;
            1function0    END_OF_FILE    1return0 BOOLEAN;


            1procedure0   SET_COL (FILE  : 1in0 FILE_TYPE; TO : 1in0 POSITIVE_COUNT);
            1procedure0   SET_COL (TO    : 1in0 POSITIVE_COUNT);

            1procedure0   SET_LINE   (FILE  : 1in0 FILE_TYPE; TO : 1in0 POSITIVE_COUNT);
            1procedure0   SET_LINE   (TO    : 1in0 POSITIVE_COUNT);


            1function0    COL  (FILE : 1in0 FILE_TYPE)   1return0 POSITIVE_COUNT;
            1function0    COL   1return0 POSITIVE_COUNT;

            1function0    LINE (FILE : 1in0 FILE_TYPE)   1return0 POSITIVE_COUNT;
            1function0    LINE 1return0 POSITIVE_COUNT;

            1function0    PAGE (FILE : 1in0 FILE_TYPE)   1return0 POSITIVE_COUNT;
            1function0    PAGE  1return0 POSITIVE_COUNT;


            6-- Character input-output

0            1procedure0   GET(FILE    : 1in0    FILE_TYPE; ITEM : 1out0 CHARACTER);
            1procedure0   GET(ITEM    : OUT    CHARACTER);
            1procedure0   PUT(FILE    : 1in0    FILE_TYPE; ITEM : 1in0 CHARACTER);
            1procedure0   PUT(ITEM    : IN  CHARACTER);

            6-- String input-output

0            1procedure0 GET(FILE   : 1in0    FILE_TYPE; ITEM : 1out0 STRING);
            1procedure0 GET(ITEM   : OUT    STRING);
            1procedure0 PUT(FILE   : 1in0    FILE_TYPE; ITEM : 1in0 STRING);
            1procedure0 PUT(ITEM   : IN  STRING);

            1procedure0 GET_LINE(FILE: 1in0 FILE_TYPE; ITEM: 1out0 STRING; LAST: 1out0 NATURAL);
            1procedure0 GET_LINE(ITEM: 1out0 STRING; LAST: 1out0 NATURAL);
            1procedure0 PUT_LINE(FILE: 1in0 FILE_TYPE; ITEM: 1in0 STRING);
            1procedure0 PUT_LINE(ITEM: 1in0 STRING);

            6-- Generic package for input-output of integer types

0            1generic
0               1type0 NUM 1is0 1RANGE0 <>;
            1package0 INTEGER_IO 1is

0               DEFAULT_WIDTH   : FIELD := NUM'WIDTH;
               DEFAULT_BASE    : NUMBER_BASE := 10;

               1procedure0 GET(FILE: 1in0 FILE_TYPE; ITEM : 1out0 NUM; WIDTH : 1in0 FIELD := 0);
               1procedure0 GET(ITEM: OUT NUM; WIDTH : 1in0 FIELD := 0);

               1procedure0 PUT
                  (FILE  : IN  FILE_TYPE;
                   ITEM  : IN  NUM;
                   WIDTH    : IN  FIELD := DEFAULT_WIDTH;
                   BASE  : IN  NUMBER_BASE := DEFAULT_BASE);
               1procedure0 PUT
                  (ITEM  : IN  NUM;
                   WIDTH    : IN  FIELD := DEFAULT_WIDTH;
                   BASE  : IN  NUMBER_BASE := DEFAULT_BASE);

               1procedure0 GET(   FROM   : IN  STRING; ITEM : 1out0 NUM; LAST : 1out0 POSITIVE);
               1procedure0 PUT
                  (TO    : OUT    STRING;
                   ITEM  : 1in0 NUM;
                   BASE  : 1in0 NUMBER_BASE := DEFAULT_BASE);

            1end0 INTEGER_IO;
            6-- Generic Packages for input-output of real types

0            1generic
0               1type0 NUM 1is0 1DIGITS0 <>;
            1package0 FLOAT_IO 1is

0               DEFAULT_FORE    : FIELD := 2;
               DEFAULT_AFT  : FIELD := NUM'DIGITS-1;
               DEFAULT_EXP  : FIELD := 3;

            1 PROCEDURE0  GET(FILE : 1in0 FILE_TYPE;  ITEM : 1out0 NUM; WIDTH : 1in0 FIELD := 0);
            1 PROCEDURE0  GET(ITEM : 1out0 NUM; WIDTH : 1in0 FIELD := 0);

               1procedure0 PUT
                  (FILE  : 1in0 FILE_TYPE;
                   ITEM  : 1in0 NUM;
                   FORE  : 1in0 FIELD := DEFAULT_FORE;
                   AFT   : 1in0 FIELD := DEFAULT_AFT;
                   EXP   : 1in0 FIELD := DEFAULT_EXP);
               1procedure0 PUT
                  (ITEM  : 1in0 NUM;
                   FORE  : 1in0 FIELD := DEFAULT_FORE;
                   AFT   : 1in0 FIELD := DEFAULT_AFT;
                   EXP   : 1in0 FIELD := DEFAULT_EXP);

               1procedure0 GET(   FROM   : 1in0 STRING; ITEM : 1out0 NUM; LAST : 1out0 POSITIVE);
               1procedure0 PUT
                  (TO    : OUT    STRING;
                   ITEM  : 1in0 NUM;
                   AFT   : 1in0 FIELD := DEFAULT_AFT;
                   EXP   : 1in0 FIELD := DEFAULT_EXP);
         1end0 FLOAT_IO;

            1generic
0               1type0 NUM 1is0 1delta0 <>;
            1package0 FIXED_IO 1is

0               DEFAULT_FORE    : FIELD := NUM'FORE;
               DEFAULT_AFT  : FIELD := NUM'AFT;
               DEFAULT_EXP  : FIELD := 0;

               1procedure0 GET(FILE: 1in0 FILE_TYPE; ITEM: 1out0 NUM; WIDTH: 1in0 FIELD := 0);
               1procedure0 GET(ITEM: 1out0 NUM; WIDTH: 1in0 FIELD := 0);

               1procedure0 PUT
                  (FILE  : 1in0 FILE_TYPE;
                   ITEM  : 1in0 NUM;
                   FORE  : 1in0 FIELD := DEFAULT_FORE;
                   AFT   : 1in0 FIELD := DEFAULT_AFT;
                   EXP   : 1in0 FIELD := DEFAULT_EXP);
               1procedure0 PUT
                  (ITEM  : 1in0 NUM;
                   FORE  : 1in0 FIELD := DEFAULT_FORE;
                   AFT   : 1in0 FIELD := DEFAULT_AFT;
                   EXP   : 1in0 FIELD := DEFAULT_EXP);

               1procedure0 GET(   FROM   : IN  STRING; ITEM : 1out0 NUM; LAST : 1out0 POSITIVE);
               1procedure0 PUT
                  (TO    : OUT    STRING;
                   ITEM  : 1in0 NUM;
                   AFT   : 1in0 FIELD := DEFAULT_AFT;
                   EXP   : 1in0 FIELD := DEFAULT_EXP);

            1end0 FIXED_IO;

            -- GENERIC 1package0 1for0 INPUT-OUTPUT 1of0 ENUMERATION TYPES

            1generic
0               1type0 ENUM 1IS0 (<>);
            1package0 ENUMERATION_IO 1is

0               DEFAULT_WIDTH   : FIELD := 0;
               DEFAULT_SETTING    : TYPE_SET := UPPER_CASE;

               1procedure0 GET(   FILE   : 1in0 FILE_TYPE; ITEM : 1out0 ENUM);
               1procedure0 GET(   ITEM   : 1out0 ENUM);

               1procedure0 PUT
                  (FILE  : 1in0 FILE_TYPE;
                   ITEM  : 1in0 ENUM;
                   WIDTH    : 1in0 FIELD    := DEFAULT_WIDTH;
                   SET   : 1in0 TYPE_SET    := DEFAULT_SETTING);
               1procedure0 PUT
                  (ITEM  : 1in0 ENUM;
                   WIDTH    : 1in0 FIELD    := DEFAULT_WIDTH;
                   SET   : 1in0 TYPE_SET    := DEFAULT_SETTING);

               1procedure0 GET(   FROM   : IN  STRING; ITEM : 1out0 ENUM; LAST : 1out0 POSITIVE);
               1procedure0 PUT
                  (TO    : OUT    STRING;
                   ITEM  : IN  ENUM;
                   SET   : IN  TYPE_SET := DEFAULT_SETTING);
         1end0 ENUMERATION_IO;

            6-- Exceptions

0            STATUS_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.STATUS_ERROR;
            MODE_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.MODE_ERROR;
            NAME_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.NAME_ERROR;
            USE_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.USE_ERROR;
            DEVICE_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.DEVICE_ERROR;
            END_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.END_ERROR;
            DATA_ERROR   : 1exception0 1renames0 IO_EXCEPTIONS.DATA_ERROR;
            LAYOUT_ERROR    : 1exception0 1renames0 IO_EXCEPTIONS.LAYOUT_ERROR;

         1private
0            6-- Implementation-dependent
0         1end0 TEXT_IO;

      section lrm-section14-4

     214.4. Exceptions in Input-Output

0     The following exceptions can be raised by input-output operations.  They are declared in the package
     IO_EXCEPTIONS, defined in section 14.5; this package is named in the context clause for each of the three
     input-output packages.  Only outline descriptions are given of the conditions under which NAME_ERROR,
     USE_ERROR, and DEVICE_ERROR are raised; for full details see Appendix F. If more than one error condition
     exists, the corresponding exception that appears earliest in the following list is the one that is
     raised.

     The exception STATUS_ERROR is raised by an attempt to operate upon a file that is not open, and by an
     attempt to open a file that is already open.

     The exception MODE_ERROR is raised by an attempt to read from, or test for the end of, a file whose
     current mode is OUT_FILE, and also by an attempt to write to a file whose current mode is IN_FILE.  In
     the case of TEXT_IO, the exception MODE_ERROR is also raised by specifying a file whose current mode is
     OUT_FILE in a call of SET_INPUT, SKIP_LINE, END_OF_LINE, SKIP_PAGE, or END_OF_PAGE; and by specifying a
     file whose current mode is IN_FILE in a call of SET_OUTPUT, SET_LINE_LENGTH, SET_PAGE_LENGTH,
     LINE_LENGTH, PAGE_LENGTH, NEW_LINE, or NEW_PAGE.

     The exception NAME_ERROR is raised by a call of CREATE or OPEN if the string given for the parameter NAME
     does not allow the identification of an external file.  For example, this exception is raised if the
     string is improper, or, alternatively, if either none or more than one external file corresponds to the
     string.

     The exception USE_ERROR is raised if an operation is attempted that is not possible for reasons that
     depend on characteristics of the external file.  For example, this exception is raised by the procedure
     CREATE, among other circumstances, if the given mode is OUT_FILE but the form specifies an input only
     device, if the parameter FORM specifies invalid access rights, or if an external file with the given name
     already exists and overwriting is not allowed.

     The exception DEVICE_ERROR is raised if an input-output operation cannot be completed because of a
     malfunction of the underlying system.

     The exception END_ERROR is raised by an attempt to skip (read past) the end of a file.

     The exception DATA_ERROR may be raised by the procedure READ if the element read cannot be interpreted as
     a value of the required type.  This exception is also raised by a procedure GET (defined in the package
     TEXT_IO) if the input character sequence fails to satisfy the required syntax, or if the value input does
     not belong to the range of the required type or subtype.

     The exception LAYOUT_ERROR is raised (in text input-output) by COL, LINE, or PAGE if the value returned
     exceeds COUNT'LAST.  The exception LAYOUT_ERROR is also raised on output by an attempt to set column or
     line numbers in excess of specified maximum line or page lengths, respectively (excluding the unbounded
     cases).  It is also raised by an attempt to PUT too many characters to a string.

     6References:0 4 col function 14.3.4, create procedure 14.2.1, end0_4of0_4line function 14.3.4,
     end0_4of0_4page function 14.3.4, external file 14.1, file 14.1, form string 14.1, get procedure
     14.3.5, in0_4file 14.1, io0_4exceptions package 14.5, line function 14.3.4, line0_4length function
     14.3.4, name string 14.1, new0_4line procedure 14.3.4, new0_4page procedure 14.3.4, open procedure
     14.2.1, out0_4file 14.1, page function 14.3.4, page0_4length function 14.3.4, put procedure 14.3.5,
     read procedure 14.2.2 14.2.3, set0_4input procedure 14.3.2, set0_4line0_4length 14.3.3,
     set0_4page0_4length 14.3.3, set0_4output 14.3.2, skip0_4line procedure 14.3.4, skip0_4page
     procedure 14.3.4, text0_4io package 14.3 0

      section lrm-section14-5

     214.5. Specification of the Package IO_Exceptions

0     This package defines the exceptions needed by the packages SEQUENTIAL_IO, DIRECT_IO, and TEXT_IO.

         1package0 IO_EXCEPTIONS 1is

0            STATUS_ERROR    : 1exception0;
            MODE_ERROR       : 1exception0;
            NAME_ERROR       : 1exception0;
            USE_ERROR         : 1exception0;
            DEVICE_ERROR     : 1exception0;
            END_ERROR         : 1exception0;
            DATA_ERROR       : 1exception0;
            LAYOUT_ERROR    : 1exception0;

         1end0 IO_EXCEPTIONS;

      section lrm-section14-6

     214.6. Low Level Input-Output

0     A low level input-output operation is an operation acting on a physical device.  Such an operation is
     handled by using one of the (overloaded) predefined procedures SEND_CONTROL and RECEIVE_CONTROL.

     A procedure SEND_CONTROL may be used to send control information to a physical device.  A procedure
     RECEIVE_CONTROL may be used to monitor the execution of an input-output operation by requesting
     information from the physical device.

     Such procedures are declared in the standard package LOW_LEVEL_IO and have two parameters identifying the
     device and the data.  However, the kinds and formats of the control information will depend on the
     physical characteristics of the machine and the device.  Hence, the types of the parameters are
     implementation-defined.  Overloaded definitions of these procedures should be provided for the supported
     devices.

     The visible part of the package defining these procedures is outlined as follows:

         1package0 LOW_LEVEL_IO 1is
0            6--  declarations of the possible types for DEVICE and DATA;
0            6--  declarations of overloaded procedures for these types:
0            1procedure0 SEND_CONTROL (DEVICE: 6device0_6type0; DATA : 1in0 1out0 6data0_6type
            1procedure0 RECEIVE_CONTROL (DEVICE: 6device0_6type;0 DATA : 1in0 1out0 6data0_6t
         1end0;

     The bodies of the procedures SEND_CONTROL and RECEIVE_CONTROL for various devices can be supplied in the
     body of the package LOW_LEVEL_IO.  These procedure bodies may be written with code statements.

      section lrm-section14-7

     214.7. Example of Input-Output

0     The following example shows the use of some of the text input-output facilities in a dialogue with a user
     at a terminal.  The user is prompted to type a color, and the program responds by giving the number of
     items of that color available in stock, according to an inventory.  The default input and output files
     are used.  For simplicity, all the requisite instantiations are given within one subprogram; in practice,
     a package, separate from the procedure, would be used.

         1with0 TEXT_IO; 1use0 TEXT_IO;
         1procedure0 DIALOGUE 1is
0            1type0 COLOR 1is0 (WHITE, RED, ORANGE, YELLOW, GREEN, BLUE, BROWN);
            1package0 COLOR_IO 1is0 1new0 ENUMERATION_IO(ENUM => COLOR);
            1package0 NUMBER_IO 1is0 1new0 INTEGER_IO(INTEGER);
            1use0 COLOR_IO, NUMBER_IO;

            INVENTORY : 1array0 (COLOR) 1of0 INTEGER := (20, 17, 43, 10, 28, 173, 87);
            CHOICE : COLOR;

            1procedure0 ENTER_COLOR (SELECTION : 1out0 COLOR) 1is
0            1begin
0               1loop
0                  1begin
0                     PUT   ("COLOR SELECTED: ");     6--  prompts user
0                     GET   (SELECTION);                6--  accepts color typed, or raises exception
0                     1return0;
                  1exception
0                     1when0 DATA_ERROR =>
                     PUT("INVALID COLOR, TRY AGAIN.  ");  6--  user has typed new line
0                     NEW_LINE(2);
                     --  6Completes execution of the block statement
0                  1end0;
               1end0 1loop0;  6--  repeats the block statement until color accepted
0            1end0;
         1begin0 6--  statements of DIALOGUE;

0            NUMBER_IO.DEFAULT_WIDTH := 5;

            1loop

0               ENTER_COLOR(CHOICE);  6--  user types color and new line

0               SET_COL(5);  PUT(CHOICE); PUT(" ITEMS AVAILABLE:");
               SET_COL(40);    PUT(INVENTORY(CHOICE));     6--  default width is 5
0               NEW_LINE;
            1end0 1loop0;
         1end0 DIALOGUE;

     6Example0 6of0 6an0 6interaction0 (6characters0 6typed0 6by0 6the0 6user0 6are0 6italicized):
0         Color selected:  6Black
0         Invalid color, try again.

         Color selected:  6Blue
0             BLUE items available:         173
         Color selected:  6Yellow
0             YELLOW items available:           10

      chapter lrm-annex-a



     5A. Predefined Language Attributes

0     This annex summarizes the definitions given elsewhere of the predefined language attributes.

     P'ADDRESS           For a prefix P that denotes an object, a program unit, a label, or an entry:

                         Yields the address of the first of the storage units allocated to P. For a
                         subprogram, package, task unit, or label, this value refers to the machine code
                         associated with the corresponding body or statement.  For an entry for which an
                         address clause has been given, the value refers to the corresponding hardware
                         interrupt.  The value of this attribute is of the type ADDRESS defined in the package
                         SYSTEM.  (See 13.7.2.)

     P'AFT               For a prefix P that denotes a fixed point subtype:

                         Yields the number of decimal digits needed after the point to accommodate the
                         precision of the subtype P, unless the delta of the subtype P is greater than 0.1, in
                         which case the attribute yields the value one.  (P'AFT is the smallest positive
                         integer N for which (10**N)*P'DELTA is greater than or equal to one.)  The value of
                         this attribute is of the type 6universal0_6integer.0 (See 3.5.10.)

     P'BASE              For a prefix P that denotes a type or subtype:

                         This attribute denotes the base type of P. It is only allowed as the prefix of the
                         name of another attribute:  for example, P'BASE'FIRST.  (See 3.3.3.)

     P'CALLABLE          For a prefix P that is appropriate for a task type:

                         Yields the value FALSE when the execution of the task P is either completed or
                         terminated, or when the task is abnormal; yields the value TRUE otherwise.  The value
                         of this attribute is of the predefined type BOOLEAN.  (See 9.9.)

     P'CONSTRAINED       For a prefix P that denotes an object of a type with discriminants:

                         Yields the value TRUE if a discriminant constraint applies to the object P, or if the
                         object is a constant (including a formal parameter or generic formal parameter of
                         mode 1in);0 yields the value FALSE otherwise.  If P is a generic formal parameter
                         of mode 1in0 1out,0 or if P is a formal parameter of mode 1in0 1out0 or
                         1out0 and the type mark given in the corresponding parameter specification denotes
                         an unconstrained type with discriminants, then the value of this attribute is
                         obtained from that of the corresponding actual parameter.  The value of this
                         attribute is of the predefined type BOOLEAN.  (See 3.7.4.)

     P'CONSTRAINED       For a prefix P that denotes a private type or subtype:

                         Yields the value FALSE if P denotes an unconstrained nonformal private type with
                         discriminants; also yields the value FALSE if P denotes a generic formal private type
                         and the associated actual subtype is either an unconstrained type with discriminants
                         or an unconstrained array type; yields the value TRUE otherwise.  The value of this
                         attribute is of the predefined type BOOLEAN.  (See 7.4.2.)

     P'COUNT             For a prefix P that denotes an entry of a task unit:

                         Yields the number of entry calls presently queued on the entry (if the attribute is
                         evaluated within an accept statement for the entry P, the count does not include the
                         calling task).  The value of this attribute is of the type 6universal0_6integer.
0                         (See 9.9.)

     P'DELTA             For a prefix P that denotes a fixed point subtype:

                         Yields the value of the delta specified in the fixed accuracy definition for the
                         subtype P. The value of this attribute is of the type 6universal0_6real.0 (See
                         3.5.10.)

     P'DIGITS            For a prefix P that denotes a floating point subtype:

                         Yields the number of decimal digits in the decimal mantissa of model numbers of the
                         subtype P. (This attribute yields the number D of section 3.5.7.)  The value of this
                         attribute is of the type 6universal0_6integer.0 (See 3.5.8.)

     P'EMAX              For a prefix P that denotes a floating point subtype:

                         Yields the largest exponent value in the binary canonical form of model numbers of
                         the subtype P. (This attribute yields the product 4*B of section 3.5.7.)  The value
                         of this attribute is of the type 6universal0_6integer.0 (See 3.5.8.)

     P'EPSILON           For a prefix P that denotes a floating point subtype:

                         Yields the absolute value of the difference between the model number 1.0 and the next
                         model number above, for the subtype P. The value of this attribute is of the type
                         6universal0_6real.0 (See 3.5.8.)

     P'FIRST             For a prefix P that denotes a scalar type, or a subtype of a scalar type:

                         Yields the lower bound of P. The value of this attribute has the same type as P. (See
                         3.5.)

     P'FIRST             For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the lower bound of the first index range.  The value of this attribute has the
                         same type as this lower bound.  (See 3.6.2 and 3.8.2.)

     P'FIRST(N)          For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the lower bound of the N-th index range.  The value of this attribute has the
                         same type as this lower bound.  The argument N must be a static expression of type
                         6universal0_6integer.0 The value of N must be positive (nonzero) and no greater
                         than the dimensionality of the array.  (See 3.6.2 and 3.8.2.)

     P'FIRST_BIT         For a prefix P that denotes a component of a record object:

                         Yields the offset, from the start of the first of the storage units occupied by the
                         component, of the first bit occupied by the component.  This offset is measured in
                         bits.  The value of this attribute is of the type 6universal0_6integer.0 (See
                         13.7.2.)

     P'FORE              For a prefix P that denotes a fixed point subtype:

                         Yields the minimum number of characters needed for the integer part of the decimal
                         representation of any value of the subtype P, assuming that the representation does
                         not include an exponent, but includes a one-character prefix that is either a minus
                         sign or a space.  (This minimum number does not include superfluous zeros or
                         underlines, and is at least two.)  The value of this attribute is of the type
                         6universal0_6integer.0 (See 3.5.10.)

     P'IMAGE             For a prefix P that denotes a discrete type or subtype:

                         This attribute is a function with a single parameter.  The actual parameter X must be
                         a value of the base type of P. The result type is the predefined type STRING.  The
                         result is the 6image0 of the value of X, that is, a sequence of characters
                         representing the value in display form.  The image of an integer value is the
                         corresponding decimal literal; without underlines, leading zeros, exponent, or
                         trailing spaces; but with a one character prefix that is either a minus sign or a
                         space.

                         The image of an enumeration value is either the corresponding identifier in upper
                         case or the corresponding character literal (including the two apostrophes); neither
                         leading nor trailing spaces are included.  The image of a character other than a
                         graphic character is implementation-defined.  (See 3.5.5.)

     P'LARGE             For a prefix P that denotes a real subtype:

                         The attribute yields the largest positive model number of the subtype P. The value of
                         this attribute is of the type 6universal0_6real.0 (See 3.5.8 and 3.5.10.)

     P'LAST              For a prefix P that denotes a scalar type, or a subtype of a scalar type:

                         Yields the upper bound of P. The value of this attribute has the same type as P. (See
                         3.5.)

     P'LAST              For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the upper bound of the first index range.  The value of this attribute has the
                         same type as this upper bound.  (See 3.6.2 and 3.8.2.)

     P'LAST(N)           For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the upper bound of the N-th index range.  The value of this attribute has the
                         same type as this upper bound.  The argument N must be a static expression of type
                         6universal0_6integer.0 The value of N must be positive (nonzero) and no greater
                         than the dimensionality of the array.  (See 3.6.2 and 3.8.2.)

     P'LAST_BIT          For a prefix P that denotes a component of a record object:

                         Yields the offset, from the start of the first of the storage units occupied by the
                         component, of the last bit occupied by the component.  This offset is measured in
                         bits.  The value of this attribute is of the type 6universal0_6integer.0 (See
                         13.7.2.)

     P'LENGTH            For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the number of values of the first index range (zero for a null range).  The
                         value of this attribute is of the type 6universal0_6integer.0 (See 3.6.2.)

     P'LENGTH(N)         For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the number of values of the N-th index range (zero for a null range).  The
                         value of this attribute is of the type 6universal0_6integer.0 The argument N must
                         be a static expression of type 6universal0_6integer.0 The value of N must be
                         positive (nonzero) and no greater than the dimensionality of the array.  (See 3.6.2
                         and 3.8.2.)

     P'MACHINE_EMAX      For a prefix P that denotes a floating point type or subtype:

                         Yields the largest value of 6exponent0 for the machine representation of the base
                         type of P. The value of this attribute is of the type 6universal0_6integer.0 (See
                         13.7.3.)

     P'MACHINE_EMIN      For a prefix P that denotes a floating point type or subtype:

                         Yields the smallest (most negative) value of 6exponent0 for the machine
                         representation of the base type of P. The value of this attribute is of the type
                         6universal0_6integer.0 (See 13.7.3.)

     P'MACHINE_MANTISSA  For a prefix P that denotes a floating point type or subtype:

                         Yields the number of digits in the 6mantissa0 for the machine representation of the
                         base type of P (the digits are extended digits in the range 0 to P'MACHINE_RADIX -
                         1).  The value of this attribute is of the type 6universal0_6integer.0 (See
                         13.7.3.)

     P'MACHINE_OVERFLOWS For a prefix P that denotes a real type or subtype:

                         Yields the value TRUE if every predefined operation on values of the base type of P
                         either provides a correct result, or raises the exception NUMERIC_ERROR in overflow
                         situations; yields the value FALSE otherwise.  The value of this attribute is of the
                         predefined type BOOLEAN.  (See 13.7.3.)

     P'MACHINE_RADIX     For a prefix P that denotes a floating point type or subtype:

                         Yields the value of the 6radix0 used by the machine representation of the base type
                         of P. The value of this attribute is of the type 6universal0_6integer.0 (See
                         13.7.3.)

     P'MACHINE_ROUNDS    For a prefix P that denotes a real type or subtype:

                         Yields the value TRUE if every predefined arithmetic operation on values of the base
                         type of P either returns an exact result or performs rounding; yields the value FALSE
                         otherwise.  The value of this attribute is of the predefined type BOOLEAN.  (See
                         13.7.3.)

     P'MANTISSA          For a prefix P that denotes a real subtype:

                         Yields the number of binary digits in the binary mantissa of model numbers of the
                         subtype P. (This attribute yields the number B of section 3.5.7 for a floating point
                         type, or of section 3.5.9 for a fixed point type.)  The value of this attribute is of
                         the type 6universal0_6integer.0 (See 3.5.8 and 3.5.10.)

     P'POS               For a prefix P that denotes a discrete type or subtype:

                         This attribute is a function with a single parameter.  The actual parameter X must be
                         a value of the base type of P. The result type is the type 6universal0_6integer.
0                         The result is the position number of the value of the actual parameter.  (See 3.5.5.)

     P'POSITION          For a prefix P that denotes a component of a record object:

                         Yields the offset, from the start of the first storage unit occupied by the record,
                         of the first of the storage units occupied by the component.  This offset is measured
                         in storage units.  The value of this attribute is of the type
                         6universal0_6integer.0 (See 13.7.2.)

     P'PRED              For a prefix P that denotes a discrete type or subtype:

                         This attribute is a function with a single parameter.  The actual parameter X must be
                         a value of the base type of P. The result type is the base type of P. The result is
                         the value whose position number is one less than that of X. The exception
                         CONSTRAINT_ERROR is raised if X equals P'BASE'FIRST.  (See 3.5.5.)

     P'RANGE             For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the first index range of P, that is, the range P'FIRST .. P'LAST.  (See
                         3.6.2.)

     P'RANGE(N)          For a prefix P that is appropriate for an array type, or that denotes a constrained
                         array subtype:

                         Yields the N-th index range of P, that is, the range P'FIRST(N) .. P'LAST(N).  (See
                         3.6.2.)

     P'SAFE_EMAX         For a prefix P that denotes a floating point type or subtype:

                         Yields the largest exponent value in the binary canonical form of safe numbers of the
                         base type of P. (This attribute yields the number E of section 3.5.7.)  The value of
                         this attribute is of the type 6universal0_6integer.0 (See 3.5.8.)

     P'SAFE_LARGE        For a prefix P that denotes a real type or subtype:

                         Yields the largest positive safe number of the base type of P. The value of this
                         attribute is of the type 6universal0_6real.0 (See 3.5.8 and 3.5.10.)

     P'SAFE_SMALL        For a prefix P that denotes a real type or subtype:

                         Yields the smallest positive (nonzero) safe number of the base type of P. The value
                         of this attribute is of the type 6universal0_6real.0 (See 3.5.8 and 3.5.10.)

     P'SIZE              For a prefix P that denotes an object:

                         Yields the number of bits allocated to hold the object.  The value of this attribute
                         is of the type 6universal0_6integer.0 (See 13.7.2.)

     P'SIZE              For a prefix P that denotes any type or subtype:

                         Yields the minimum number of bits that is needed by the implementation to hold any
                         possible object of the type or subtype P. The value of this attribute is of the type
                         6universal0_6integer.0 (See 13.7.2.)

     P'SMALL             For a prefix P that denotes a real subtype:

                         Yields the smallest positive (nonzero) model number of the subtype P. The value of
                         this attribute is of the type 6universal0_6real.0 (See 3.5.8 and 3.5.10.)

     P'STORAGE_SIZE      For a prefix P that denotes an access type or subtype:

                         Yields the total number of storage units reserved for the collection associated with
                         the base type of P. The value of this attribute is of the type
                         6universal0_6integer.0 (See 13.7.2.)

     P'STORAGE_SIZE      For a prefix P that denotes a task type or a task object:

                         Yields the number of storage units reserved for each activation of a task of the type
                         P or for the activation of the task object P. The value of this attribute is of the
                         type 6universal0_6integer.0 (See 13.7.2.)

     P'SUCC              For a prefix P that denotes a discrete type or subtype:

                         This attribute is a function with a single parameter.  The actual parameter X must be
                         a value of the base type of P. The result type is the base type of P. The result is
                         the value whose position number is one greater than that of X. The exception
                         CONSTRAINT_ERROR is raised if X equals P'BASE'LAST.  (See 3.5.5.)

     P'TERMINATED        For a prefix P that is appropriate for a task type:

                         Yields the value TRUE if the task P is terminated; yields the value FALSE otherwise.
                         The value of this attribute is of the predefined type BOOLEAN.  (See 9.9.)

     P'VAL               For a prefix P that denotes a discrete type or subtype:

                         This attribute is a special function with a single parameter X which can be of any
                         integer type.  The result type is the base type of P. The result is the value whose
                         position number is the 6universal0_6integer0 value corresponding to X. The
                         exception CONSTRAINT_ERROR is raised if the 6universal0_6integer0 value
                         corresponding to X is not in the range P'POS(P'BASE'FIRST) .. P'POS(P'BASE'LAST).
                         (See 3.5.5.)

     P'VALUE             For a prefix P that denotes a discrete type or subtype:

                         This attribute is a function with a single parameter.  The actual parameter X must be
                         a value of the predefined type STRING.  The result type is the base type of P. Any
                         leading and any trailing spaces of the sequence of characters that corresponds to X
                         are ignored.

                         For an enumeration type, if the sequence of characters has the syntax of an
                         enumeration literal and if this literal exists for the base type of P, the result is
                         the corresponding enumeration value.  For an integer type, if the sequence of
                         characters has the syntax of an integer literal, with an optional single leading
                         character that is a plus or minus sign, and if there is a corresponding value in the
                         base type of P, the result is this value.  In any other case, the exception
                         CONSTRAINT_ERROR is raised.  (See 3.5.5.)

     P'WIDTH             For a prefix P that denotes a discrete subtype:

                         Yields the maximum image length over all values of the subtype P (the 6image0 is
                         the sequence of characters returned by the attribute IMAGE).  The value of this
                         attribute is of the type 6universal0_6integer.0 (See 3.5.5.)

      chapter lrm-annex-b



     5B. Predefined Language Pragmas

0     This annex defines the pragmas LIST, PAGE, and OPTIMIZE, and summarizes the definitions given elsewhere
     of the remaining language-defined pragmas.

     6Pragma0              6Meaning

0     CONTROLLED          Takes the simple name of an access type as the single argument.  This pragma is only
                         allowed immediately within the declarative part or package specification that
                         contains the declaration of the access type; the declaration must occur before the
                         pragma.  This pragma is not allowed for a derived type.  This pragma specifies that
                         automatic storage reclamation must not be performed for objects designated by values
                         of the access type, except upon leaving the innermost block statement, subprogram
                         body, or task body that encloses the access type declaration, or after leaving the
                         main program (see 4.8).

     ELABORATE           Takes one or more simple names denoting library units as arguments.  This pragma is
                         only allowed immediately after the context clause of a compilation unit (before the
                         subsequent library unit or secondary unit).  Each argument must be the simple name of
                         a library unit mentioned by the context clause.  This pragma specifies that the
                         corresponding library unit body must be elaborated before the given compilation unit.
                         If the given compilation unit is a subunit, the library unit body must be elaborated
                         before the body of the ancestor library unit of the subunit (see 10.5).

     INLINE              Takes one or more names as arguments; each name is either the name of a subprogram or
                         the name of a generic subprogram.  This pragma is only allowed at the place of a
                         declarative item in a declarative part or package specification, or after a library
                         unit in a compilation, but before any subsequent compilation unit.  This pragma
                         specifies that the subprogram bodies should be expanded inline at each call whenever
                         possible; in the case of a generic subprogram, the pragma applies to calls of its
                         instantiations (see 6.3.2).

     INTERFACE           Takes a language name and a subprogram name as arguments.  This pragma is allowed at
                         the place of a declarative item, and must apply in this case to a subprogram declared
                         by an earlier declarative item of the same declarative part or package specification.
                         This pragma is also allowed for a library unit; in this case the pragma must appear
                         after the subprogram declaration, and before any subsequent compilation unit.  This
                         pragma specifies the other language (and thereby the calling conventions) and informs
                         the compiler that an object module will be supplied for the corresponding subprogram
                         (see 13.9).

     LIST                Takes one of the identifiers ON or OFF as the single argument.  This pragma is
                         allowed anywhere a pragma is allowed.  It specifies that listing of the compilation
                         is to be continued or suspended until a LIST pragma with the opposite argument is
                         given within the same compilation.  The pragma itself is always listed if the
                         compiler is producing a listing.

     MEMORY_SIZE         Takes a numeric literal as the single argument.  This pragma is only allowed at the
                         start of a compilation, before the first compilation unit (if any) of the
                         compilation.  The effect of this pragma is to use the value of the specified numeric
                         literal for the definition of the named number MEMORY_SIZE (see 13.7).

     OPTIMIZE            Takes one of the identifiers TIME or SPACE as the single argument.  This pragma is
                         only allowed within a declarative part and it applies to the block or body enclosing
                         the declarative part.  It specifies whether time or space is the primary optimization
                         criterion.

     PACK                Takes the simple name of a record or array type as the single argument. The allowed
                         positions for this pragma, and the restrictions on the named type, are governed by
                         the same rules as for a representation clause. The pragma specifies that storage
                         minimization should be the main criterion when selecting the representation of the
                         given type (see 13.1).

     PAGE                This pragma has no argument, and is allowed anywhere a pragma is allowed.  It
                         specifies that the program text which follows the pragma should start on a new page
                         (if the compiler is currently producing a listing).

     PRIORITY            Takes a static expression of the predefined integer subtype PRIORITY as the single
                         argument.  This pragma is only allowed within the specification of a task unit or
                         immediately within the outermost declarative part of a main program.  It specifies
                         the priority of the task (or tasks of the task type) or the priority of the main
                         program (see 9.8).

     SHARED              Takes the simple name of a variable as the single argument.  This pragma is allowed
                         only for a variable declared by an object declaration and whose type is a scalar or
                         access type; the variable declaration and the pragma must both occur (in this order)
                         immediately within the same declarative part or package specification.  This pragma
                         specifies that every read or update of the variable is a synchronization point for
                         that variable.  An implementation must restrict the objects for which this pragma is
                         allowed to objects for which each of direct reading and direct updating is
                         implemented as an indivisible operation (see 9.11).

     STORAGE_UNIT        Takes a numeric literal as the single argument.  This pragma is only allowed at the
                         start of a compilation, before the first compilation unit (if any) of the
                         compilation.  The effect of this pragma is to use the value of the specified numeric
                         literal for the definition of the named number STORAGE_UNIT (see 13.7).

     SUPPRESS            Takes as arguments the identifier of a check and optionally also the name of either
                         an object, a type or subtype, a subprogram, a task unit, or a generic unit.  This
                         pragma is only allowed either immediately within a declarative part or immediately
                         within a package specification.  In the latter case, the only allowed form is with a
                         name that denotes an entity (or several overloaded subprograms) declared immediately
                         within the package specification.  The permission to omit the given check extends
                         from the place of the pragma to the end of the declarative region associated with the
                         innermost enclosing block statement or program unit.  For a pragma given in a package
                         specification, the permission extends to the end of the scope of the named entity.

                         If the pragma includes a name, the permission to omit the given check is further restricted:  it is given
                         only for operations on the named object or on all objects of the base type of a named
                         type or subtype; for calls of a named subprogram; for activations of tasks of the
                         named task type; or for instantiations of the given generic unit (see 11.7).

     SYSTEM_NAME         Takes an enumeration literal as the single argument. This pragma is only allowed at
                         the start of a compilation, before the first compilation unit (if any) of the
                         compilation.  The effect of this pragma is to use the enumeration literal with the
                         specified identifier for the definition of the constant SYSTEM_NAME.  This pragma is
                         only allowed if the specified identifier corresponds to one of the literals of the
                         type NAME declared in the package SYSTEM (see 13.7).

      chapter lrm-annex-c



     5C. Predefined Language Environment

0     This annex outlines the specification of the packag STANDARD containing all predefined identifiers in the
     language.  The corresponding package body is implementation-defined and is not shown.

     The operators that are predefined for the types declared in the package STANDARD are given in comments
     since they are implicitly declared.  Italics are used for pseudo-names of anonymous types (such as
     6universal0_6real0) and for undefined information (such as 6implementation0_6defined0 and
     6any0_6fixed0_6point0_6type0).

         1package0 STANDARD 1is

0            1type0 BOOLEAN 1is0 (FALSE, TRUE);

            6-- The predefined relational operators for this type are as follows:

0            6-- 1function0 "="    (LEFT, RIGHT : BOOLEAN)    1return0 BOOLEAN;
            6-- 1function0 "/="   (LEFT, RIGHT : BOOLEAN)    1return0 BOOLEAN;
            6-- 1function0 "<"    (LEFT, RIGHT : BOOLEAN)    1return0 BOOLEAN;
            6-- 1function0 "<="   (LEFT, RIGHT : BOOLEAN)    1return0 BOOLEAN;
            6-- 1function0 ">"    (LEFT, RIGHT : BOOLEAN)    1return0 BOOLEAN;
            6-- 1function0 ">="   (LEFT, RIGHT : BOOLEAN)    1return0 BOOLEAN;

            6-- The predefined logical operators 
0            6-- and the predefined logical negation operator are as follows:

0            6-- 1function0 "and"  (LEFT, RIGHT : BOOLEAN) 1return0 BOOLEAN;
            6-- 1function0 "or"   (LEFT, RIGHT : BOOLEAN) 1return0 BOOLEAN;
            6-- 1function0 "xor"  (LEFT, RIGHT : BOOLEAN) 1return0 BOOLEAN;

            6-- 1function0 "not"  (RIGHT : BOOLEAN) 1return0 BOOLEAN;



            -- The universal type 6universal0_6integer0 is predefined.


            1type0 INTEGER 1is0 6implementation0_6defined0;

            -- THE PREDEFINED OPERATORS 1for0 THIS 1type0 ARE AS FOLLOWS:

            6-- 1function0 "="    (LEFT, RIGHT : INTEGER) 1return0 BOOLEAN;
            6-- 1function0 "/="   (LEFT, RIGHT : INTEGER) 1return0 BOOLEAN;
            6-- 1function0 "<"    (LEFT, RIGHT : INTEGER) 1return0 BOOLEAN;
            6-- 1function0 "<="   (LEFT, RIGHT : INTEGER) 1return0 BOOLEAN;
            6-- 1function0 ">"    (LEFT, RIGHT : INTEGER) 1return0 BOOLEAN;
            6-- 1function0 ">="   (LEFT, RIGHT : INTEGER) 1return0 BOOLEAN;

            6-- 1function0 "+"    (RIGHT : INTEGER) 1return0 INTEGER;
            6-- 1function0 "-"    (RIGHT : INTEGER) 1return0 INTEGER;
            6-- 1function0 "abs"  (RIGHT : INTEGER) 1return0 INTEGER;

            6-- 1function0 "+"    (LEFT, RIGHT : INTEGER) 1return0 INTEGER;
            6-- 1function0 "-"    (LEFT, RIGHT : INTEGER) 1return0 INTEGER;
            6-- 1function0 "*"    (LEFT, RIGHT : INTEGER) 1return0 INTEGER;
            6-- 1function0 "/"    (LEFT, RIGHT : INTEGER) 1return0 INTEGER;
            6-- 1function0 "rem"  (LEFT, RIGHT : INTEGER) 1return0 INTEGER;
            6-- 1function0 "mod"  (LEFT, RIGHT : INTEGER) 1return0 INTEGER;

            6-- 1function0 "**"   (LEFT : INTEGER; RIGHT : INTEGER) 1return0 INTEGER;

            -- An implementation may provide additional predefined integer types.  It is recommended that
            -- the names of such additional types end with INTEGER as in SHORT_INTEGER  or  LONG_INTEGER.
            -- The  specification  of each operator for the type 6universal0_6integer,0 or for any
            -- additional predefined integer type, is obtained by replacing INTEGER by the name of
            -- the type in the specification  of  the  corresponding  operator  of the type INTEGER,
            -- except for the right operand of the exponentiating operator.

            -- The universal type 6universal0_6real0 is predefined.

            1type0 FLOAT 1is0 6implementation0_6defined;

0            -- THE PREDEFINED OPERATORS 1for0 THIS 1type0 ARE AS FOLLOWS:

            6-- 1function0 "="    (LEFT, RIGHT : FLOAT) 1return0 BOOLEAN;
            6-- 1function0 "/="   (LEFT, RIGHT : FLOAT) 1return0 BOOLEAN;
            6-- 1function0 "<"    (LEFT, RIGHT : FLOAT) 1return0 BOOLEAN;
            6-- 1function0 "<="   (LEFT, RIGHT : FLOAT) 1return0 BOOLEAN;
            6-- 1function0 ">"    (LEFT, RIGHT : FLOAT) 1return0 BOOLEAN;
            6-- 1function0 ">="   (LEFT, RIGHT : FLOAT) 1return0 BOOLEAN;

            6-- 1function0 "+"    (RIGHT : FLOAT) 1return0 FLOAT;
            6-- 1function0 "-"    (RIGHT : FLOAT) 1return0 FLOAT;
            6-- 1function0 "abs"  (RIGHT : FLOAT) 1return0 FLOAT;

            6-- 1function0 "+"    (LEFT, RIGHT : FLOAT) 1return0 FLOAT;
            6-- 1function0 "-"    (LEFT, RIGHT : FLOAT) 1return0 FLOAT;
            6-- 1function0 "*"    (LEFT, RIGHT : FLOAT) 1return0 FLOAT;
            6-- 1function0 "/"    (LEFT, RIGHT : FLOAT) 1return0 FLOAT;

            6-- 1function0 "**"   (LEFT : FLOAT; RIGHT : INTEGER) 1return0 FLOAT;

            -- An implementation may provide additional predefined floating point types.  It  is
            -- recommended that the  names of such additional types end with FLOAT as in SHORT_FLOAT or
            -- LONG_FLOAT. The specification of each operator for the type 6universal0_6real0, or for
            -- additional predefined  floating point type, is obtained by replacing FLOAT by the name of
            -- the type in the specification of  the  corresponding  operator  of  the  type  FLOAT.

            -- In addition, the following operators are predefined for universal types:

            6-- 1function0 "*"
            --    (LEFT: 6--    (LEFT: universal0_6integer0; RIGHT: 6universal0_6real0)
            6--    1return0 6universal0_6real0;
            6-- 1function0 "*"
            --    (LEFT: 6--    (LEFT: universal0_6real0; RIGHT: 6universal0_6integer0)
            6--    1return0 6universal0_6real0;
            6-- 1function0 "/"
            --    (LEFT : 6--    (LEFT : universal0_6real;0 RIGHT : 6universal0_6integer0)
            6--    1return0 6universal0_6real0;

            6-- The type universal0_6fixed is predefined.  The only operators declared for this type ar

            -- 1function0 "*"
            --    (LEFT:6--    (LEFT:any0_6fixed0_6point0_6type0; RIGHT:6any0_6fixed0_
6            --    1return0 6universal0_6fixed0;
            6-- 1function0 "/"
            6--    (LEFT : --    (LEFT : any0_6fixed0_6point0_6type;0 RIGHT : 6any0_6fixed
            --    1return0 6universal0_6fixed0;

            -- The following characters form the standard ASCII character set. Character literals
            -- corresponding to control characters are not identifiers.

            1type0 CHARACTER 1is

0               (  6nul,     soh,0     6stx,0     6etx,0     6eot,0     6enq,0     6ack,0     6bel,
0	          6bs,0      6ht,0      6lf,0       6vt,0       6ff,0      6cr,0       6so,0      6si,
                  dle,    0 6dc1,    dc2,     dc3,     dc4,    nak,     syn,     etb,
                  can,    em,   0  6sub,     0 6esc,     fs,   0   6gs,   0   6rs,   0    6us,
                  0' ',       '!',      '"',        '#',     '$',      '%',      '&',       ''',
                  '(',       ')',      '*',       '+',      ',',       '-',      '.',        '/',
                  '0',      '1',     '2',       '3',      '4',      '5',      '6',       '7',
                  '8',      '9',     ':',        ';',       '<',      '=',      '>',        '?',

                  '@',     'A',     'B',       'C',      'D',     'E',      'F',       'G',
                  'H',     'I',      'J',       'K',       'L',     'M',      'N',       'O',
                  'P',     'Q',     'R',      'S',       'T',     'U',      'V',       'W',
                  'X',    'Y',     'Z',       '[',       '\',      '',        '^',      '_',

                  '`',      'a',      'b',       'c',       'd',     'e',       'f',      'g',
                  'h',     'i',      'j',        'k',        'l',     'm',      'n',      'o',
                  'p',     'q',     'r',        's',        't',     'u',      'v',     'w',
                  'x',     'y',     'z',        '{',        '|',     '}',      '~',     del);


            1for0 CHARACTER 1use0  --  128 ASCII character set without holes
                  (0, 1, 2, 3, 4, 5, ..., 125, 126, 127);

            -- The predefined operators for the type CHARACTER are the same as for any enumeration type.


            1package0 ASCII 1is

0               --  Control characters:

               NUL    : 1constant0 CHARACTER := nul;    SOH   : 1constant0 CHARACTER := soh;
               STX   : 1constant0 CHARACTER := stx;    ETX   : 1constant0 CHARACTER := etx;
               EOT   : 1constant0 CHARACTER := eot;    ENQ   : 1constant0 CHARACTER := enq;
               ACK   : 1constant0 CHARACTER := ack;    BEL    : 1constant0 CHARACTER := bel;
               BS     : 1constant0 CHARACTER := bs;     HT     : 1constant0 CHARACTER := ht;
               LF     : 1constant0 CHARACTER := lf;       VT    : 1constant0 CHARACTER := vt;
               FF     : 1constant0 CHARACTER := ff;      CR     : 1constant0 CHARACTER := cr;
               SO    : 1constant0 CHARACTER := so;     SI      : 1constant0 CHARACTER := si;
               DLE   : 1constant0 CHARACTER := dle;     DC1   : 1constant0 CHARACTER := dc1;
               DC2   : 1constant0 CHARACTER := dc2;    DC3   : 1constant0 CHARACTER := dc3;
               DC4   : 1constant0 CHARACTER := dc4;    NAK   : 1constant0 CHARACTER := nak;
               SYN   : 1constant0 CHARACTER := syn;    ETB   : 1constant0 CHARACTER := etb;
               CAN   : 1constant0 CHARACTER := can;    EM     : 1constant0 CHARACTER := em;
               SUB   : 1constant0 CHARACTER := sub;     ESC   : 1constant0 CHARACTER := esc;
               FS     : 1constant0 CHARACTER := fs;      GS     : 1constant0 CHARACTER := gs;
               RS     : 1constant0 CHARACTER := rs;      US     : 1constant0 CHARACTER := us;
               DEL   : 1constant0 CHARACTER := del;

               -- Other characters:

               EXCLAM   : 1constant0 CHARACTER := '!'; QUOTATION   : 1constant0 CHARACTER := '"';
               SHARP : 1constant0 CHARACTER := '#'; DOLLAR   : 1constant0 CHARACTER := '$';
               PERCENT  : 1constant0 CHARACTER := '%'; AMPERSAND   : 1constant0 CHARACTER := '&';
               COLON : 1constant0 CHARACTER := ':'; SEMICOLON   : 1constant0 CHARACTER := ';';
               QUERY : 1constant0 CHARACTER := '?'; AT_SIGN  : 1constant0 CHARACTER := '@';
               L_BRACKET   : 1constant0 CHARACTER := '['; BACK_SLASH  : 1constant0 CHARACTER := '\';
               R_BRACKET   : 1constant0 CHARACTER := ']'; CIRCUMFLEX  : 1constant0 CHARACTER := '^';
               UNDERLINE   : 1constant0 CHARACTER := '_'; GRAVE : 1constant0 CHARACTER := '`';
               L_BRACE  : 1constant0 CHARACTER := '{'; BAR   : 1constant0 CHARACTER := '|';
               R_BRACE  : 1constant0 CHARACTER := '}'; TILDE : 1constant0 CHARACTER := '~';

               -- Lower case letters:

               LC_A  : 1constant0 CHARACTER := 'a';
                     .
               LC_Z  : 1constant0 CHARACTER := 'z';

            1end0 ASCII;

            -- Predefined subtypes:

            subtype   NATURAL  is INTEGER range 0 .. INTEGER'LAST;
            subtype   POSITIVE    is INTEGER range 1 .. INTEGER'LAST;

            -- Predefined string type:

            type STRING is array(POSITIVE range <>) of CHARACTER;

            pragma PACK(STRING);


            -- The predefined operators for this type are as follows:

            -- 1function0 "="   (LEFT, RIGHT : STRING) 1return0 BOOLEAN;
            -- 1function0 "/="  (LEFT, RIGHT : STRING) 1return0 BOOLEAN;
            -- 1function0 "<"   (LEFT, RIGHT : STRING) 1return0 BOOLEAN;
            -- 1function0 "<="  (LEFT, RIGHT : STRING) 1return0 BOOLEAN;
            -- 1function0 ">"   (LEFT, RIGHT : STRING) 1return0 BOOLEAN;
            -- 1function0 ">="  (LEFT, RIGHT : STRING) 1return0 BOOLEAN;

            -- 1function0 "&"   (LEFT : STRING;   RIGHT : STRING)   1return0 STRING;
            -- 1function0 "&"   (LEFT : CHARACTER;   RIGHT : STRING)   1return0 STRING;
            -- 1function0 "&"   (LEFT : STRING;   RIGHT : CHARACTER)   1return0 STRING;
            -- 1function0 "&"   (LEFT : CHARACTER;   RIGHT : CHARACTER)   1return0 STRING;

            type DURATION is delta implementation_defined range implementation_defined;

            -- The predefined operators for the type DURATION are the same as for any fixed point type.


         -- The predefined exceptions:

                CONSTRAINT_ERROR   : 1exception0;
                NUMERIC_ERROR   : 1exception0;
                PROGRAM_ERROR   : 1exception0;
                STORAGE_ERROR   : 1exception0;
                TASKING_ERROR   : 1exception0;

             1end0 STANDARD;

     Certain aspects of the predefined entities cannot be completely described in the language itself.  For
     example, although the enumeration type BOOLEAN can be written showing the two enumeration literals FALSE
     and TRUE, the short-circuit control forms cannot be expressed in the language.

     Note:

     The language definition predefines the following library units:  :table - The package CALENDAR   (see
     9.6)

     - The package SYSTEM  (see 13.7) - The package MACHINE_CODE (if provided)   (see 13.8) - The generic
     procedure UNCHECKED_DEALLOCATION  (see 13.10.1) - The generic function UNCHECKED_CONVERSION   (see
     13.10.2)

     - The generic package SEQUENTIAL_IO  (see 14.2.3) - The generic package DIRECT_IO    (see 14.2.5) - The
     package TEXT_IO    (see 14.3.10) - The package IO_EXCEPTIONS    (see 14.5) - The package LOW_LEVEL_IO
     (see 14.6)

      chapter lrm-appendix-d



     5D. Glossary

0     This appendix is informative and is not part of the standard definition of the Ada programming language.
     Italicized terms in the abbreviated descriptions below either have glossary entries themselves or are
     described in entries for related terms.

     1Accept0 1statement.0 See 6entry.

0     1Access0 1type.0 A value of an access type (an 6access0 6value)0 is either a null value, or a
     value that 6designates0 an 6object0 created by an 6allocator.0 The designated object can be read
     and updated via the access value.  The definition of an access type specifies the type of the objects
     designated by values of the access type.  See also 6collection.

0     1Actual0 1parameter.0 See 6parameter.

0     1Aggregate.0 The evaluation of an aggregate yields a value of a 6composite0 6type.0 The value is
     specified by giving the value of each of the 6components.0 Either 6positional0 6association0 or
     6named0 6association0 may be used to indicate which value is associated with which component.

     1Allocator.0 The evaluation of an allocator creates an 6object0 and returns a new 6access
0     6value0 which 6designates0 the object.

     1Array0 1type.0 A value of an array type consists of 6components0 which are all of the same
     6subtype0 (and hence, of the same type).  Each component is uniquely distinguished by an 6index0 (for
     a one-dimensional array) or by a sequence of indices (for a multidimensional array).  Each index must be
     a value of a 6discrete0 6type0 and must lie in the correct index 6range.

0     1Assignment.0 Assignment is the 6operation0 that replaces the current value of a 6variable0 by a
     new value.  An 6assignment0 6statement0 specifies a variable on the left, and on the right, an
     6expression0 whose value is to be the new value of the variable.

     1Attribute.0 The evaluation of an attribute yields a predefined characteristic of a named entity; some
     attributes are 6functions.

0     1Block0 1statement.0 A block statement is a single statement that may contain a sequence of
     statements.  It may also include a 6declarative0 6part,0 and 6exception0 6handlers;0 their
     effects are local to the block statement.

     1Body.0 A body defines the execution of a 6subprogram,0 6package,0 or 6task.0 A 6body0 6stub
0     is a form of body that indicates that this execution is defined in a separately compiled 6subunit.

0     1Collection.0 A collection is the entire set of 6objects0 created by evaluation of 6allocators0 for
     an 6access0 6type.

0     1Compilation0 1unit.0 A compilation unit is the 6declaration0 or the 6body0 of a 6program
0     6unit,0 presented for compilation as an independent text.  It is optionally preceded by a 6context
0     6clause,0 naming other compilation units upon which it depends by means of one more 6with
0     6clauses.

0     1Component.0 A component is a value that is a part of a larger value, or an 6object0 that is part of
     a larger object.

     1Composite0 1type.0 A composite type is one whose values have 6components.0 There are two kinds of
     composite type:  6array0 6types0 and 6record0 6types.

0     1Constant.0 See 6object.

0     1Constraint.0 A constraint determines a subset of the values of a 6type.0 A value in that subset
     6satisfies0 the constraint.

     1Context0 1clause.0 See 6compilation0 6unit.

0     1Declaration.0 A declaration associates an identifier (or some other notation) with an entity.  This
     association is in effect within a region of text called the 6scope0 of the declaration.  Within the
     scope of a declaration, there are places where it is possible to use the identifier to refer to the
     associated declared entity.  At such places the identifier is said to be a 6simple0 6name0 of the
     entity; the 6name0 is said to 6denote0 the associated entity.

     1Declarative0 1Part.0 A declarative part is a sequence of 6declarations.0 It may also contain
     related information such as 6subprogram0 6bodies0 and 6representation0 6clauses.

0     1Denote.0 See 6declaration.

0     1Derived0 1Type.0 A derived type is a 6type0 whose operations and values are replicas of those of
     an existing type.  The existing type is called the 6parent0 6type0 of the derived type.

     1Designate.0 See 6access0 6type,0 6task.

0     1Direct0 1visibility.0 See 6visibility.

0     1Discrete0 1Type.0 A discrete type is a 6type0 which has an ordered set of distinct values.  The
     discrete types are the 6enumeration0 and 6integer0 6types.0 Discrete types are used for indexing
     and iteration, and for choices in case statements and record 6variants.

0     1Discriminant.0 A discriminant is a distinguished 6component0 of an 6object0 or value of a
     6record0 6type.0 The 6subtypes0 of other components, or even their presence or absence, may depend
     on the value of the discriminant.

     1Discriminant0 1constraint.0 A discriminant constraint on a 6record0 6type0 or 6private
0     6type0 specifies a value for each 6discriminant0 of the 6type.

0     1Elaboration.0 The elaboration of a 6declaration0 is the process by which the declaration achieves
     its effect (such as creating an 6object);0 this process occurs during program execution.

     1Entry.0 An entry is used for communication between 6tasks.0 Externally, an entry is called just as a
     6subprogram0 is called; its internal behavior is specified by one or more 6accept0 6statements
0     specifying the actions to be performed when the entry is called.

     1Enumeration0 1type.0 An enumeration type is a 6discrete0 6type0 whose values are represented by
     enumeration literals which are given explicitly in the 6type0 6declaration.0 These enumeration
     literals are either 6identifiers0 or 6character0 6literals.

0     1Evaluation.0 The evaluation of an 6expression0 is the process by which the value of the expression
     is computed.  This process occurs during program execution.

     1Exception.0 An exception is an error situation which may arise during program execution.  To 6raise
0     an exception is to abandon normal program execution so as to signal that the error has taken place.  An
     6exception0 6handler0 is a portion of program text specifying a response to the exception.  Execution
     of such a program text is called 6handling0 the exception.

     1Expanded0 1name.0 An expanded name 6denotes0 an entity which is 6declared0 immediately within
     some construct.  An expanded name has the form of a 6selected0 6component:0 the 6prefix0 denotes
     the construct (a 6program0 6unit;0 or a 6block,0 loop, or 6accept0 6statement);0 the
     6selector0 is the 6simple0 6name0 of the entity.

     1Expression.0 An expression defines the computation of a value.

     1Fixed0 1point0 1type.0 See 6real0 6type.

0     1Floating0 1point0 1type.0 See 6real0 6type.

0     1Formal0 1parameter.0 See 6parameter.

0     1Function.0 See 6subprogram.

0     1Generic0 1unit.0 A generic unit is a template either for a set of 6subprograms0 or for a set of
     6packages.0 A subprogram or package created using the template is called an 6instance0 of the generic
     unit.  A 6generic0 6instantiation0 is the kind of 6declaration0 that creates an instance.  A
     generic unit is written as a subprogram or package but with the specification prefixed by a 6generic
0     6formal0 6part0 which may declare 6generic0 6formal0 6parameters.0 A generic formal parameter
     is either a 6type,0 a 6subprogram,0 or an 6object.0 A generic unit is one of the kinds of
     6program0 6unit.

0     1Handler.0 See 6exception.

0     1Index.0 See 6array0 6type.

0     1Index0 1constraint.0 An index constraint for an 6array0 6type0 specifies the lower and upper
     bounds for each index 6range0 of the array type.

     1Indexed0 1component.0 An indexed component 6denotes0 a 6component0 in an 6array.0 It is a form
     of 6name0 containing 6expressions0 which specify the values of the 6indices0 of the array
     component.  An indexed component may also denote an 6entry0 in a family of entries.

     1Instance.0 See 6generic0 6unit.

0     1Integer0 1type.0 An integer type is a 6discrete0 6type0 whose values represent all integer
     numbers within a specific 6range.

0     1Lexical0 1element.0 A lexical element is an identifier, a 6literal,0 a delimiter, or a comment.

     1Limited0 1type.0 A limited type is a 6type0 for which neither assignment nor the predefined
     comparison for equality is implicitly declared.  All 6task0 types are limited.  A 6private0 6type
0     can be defined to be limited.  An equality operator can be explicitly declared for a limited type.

     1Literal.0 A literal represents a value literally, that is, by means of letters and other characters.
     A literal is either a numeric literal, an enumeration literal, a character literal, or a string literal.

     1Mode.0 See 6parameter.

0     1Model0 1number.0 A model number is an exactly representable value of a 6real0 6type.
0     6Operations0 of a real type are defined in terms of operations on the model numbers of the type.  The
     properties of the model numbers and of their operations are the minimal properties preserved by all
     implementations of the real type.

     1Name.0 A name is a construct that stands for an entity:  it is said that the name 6denotes0 the
     entity, and that the entity is the meaning of the name.  See also 6declaration,0 6prefix.

0     1Named0 1association.0 A named association specifies the association of an item with one or more
     positions in a list, by naming the positions.

     1Object.0 An object contains a value.  A program creates an object either by 6elaborating0 an
     6object0 6declaration0 or by 6evaluating0 an 6allocator.0 The declaration or allocator specifies
     a 6type0 for the object:  the object can only contain values of that type.

     1Operation.0 An operation is an elementary action associated with one or more 6types.0 It is either
     implicitly declared by the 6declaration0 of the type, or it is a 6subprogram0 that has a
     6parameter0 or 6result0 of the type.

     1Operator.0 An operator is an operation which has one or two operands.  A unary operator is written
     before an operand; a binary operator is written between two operands.  This notation is a special kind of
     6function0 6call.0 An operator can be declared as a function.  Many operators are implicitly declared
     by the 6declaration0 of a 6type0 (for example, most type declarations imply the declaration of the
     equality operator for values of the type).

     1Overloading.0 An identifier can have several alternative meanings at a given point in the program
     text:  this property is called 6overloading.0 For example, an overloaded enumeration literal can be an
     identifier that appears in the definitions of two or more 6enumeration0 6types.0 The effective
     meaning of an overloaded identifier is determined by the context.  6Subprograms,0 6aggregates,
0     6allocators,0 and string 6literals0 can also be overloaded.

     1Package.0 A package specifies a group of logically related entities, such as 6types,0 6objects0 of
     those types, and 6subprograms0 with 6parameters0 of those types.  It is written as a 6package
0     6declaration0 and a 6package0 6body.0 The package declaration has a 6visible0 6part,
0     containing the 6declarations0 of all entities that can be explicitly used outside the package.  It may
     also have a 6private0 6part0 containing structural details that complete the specification of the
     visible entities, but which are irrelevant to the user of the package.  The 6package0 6body0 contains
     implementations of 6subprograms0 (and possibly 6tasks0 as other 6packages)0 that have been
     specified in the package declaration.  A package is one of the kinds of 6program0 6unit.

0     1Parameter.0 A parameter is one of the named entities associated with a 6subprogram,0 6entry,0 or
     6generic0 6unit,0 and used to communicate with the corresponding subprogram body, 6accept
0     6statement0 or generic body.  A 6formal0 6parameter0 is an 6identifier0 used to denote the named
     entity within the body.  An 6actual0 6parameter0 is the particular entity associated with the
     corresponding formal parameter by a 6subprogram0 6call,0 6entry0 6call,0 or 6generic
0     6instantiation.0 The 6mode0 of a formal parameter specifies whether the associated actual parameter
     supplies a value for the formal parameter, or the formal supplies a value for the actual parameter, or
     both.  The association of actual parameters with formal parameters can be specified by 6named
0     6associations,0 by 6positional0 6associations,0 or by a combination of these.

     1Parent0 1type.0 See 6derived0 6type.

0     1Positional0 1association.0 A positional association specifies the association of an item with a
     position in a list, by using the same position in the text to specify the item.

     1Pragma.0 A pragma conveys information to the compiler.

     1Prefix.0 A prefix is used as the first part of certain kinds of name.  A prefix is either a
     6function0 6call0 or a 6name.

0     1Private0 1part.0 See 6package.

0     1Private0 1type.0 A private type is a 6type0 whose structure and set of values are clearly defined,
     but not directly available to the user of the type.  A private type is known only by its
     6discriminants0 (if any) and by the set of 6operations0 defined for it.  A private type and its
     applicable operations are defined in the 6visible0 6part0 of a 6package,0 or in a 6generic
0     6formal0 6part.0 6Assignment,0 equality, and inequality are also defined for private types, unless
     the private type is 6limited.

0     1Procedure.0 See 6subprogram.

0     1Program.0 A program is composed of a number of 6compilation0 6units,0 one of which is a
     6subprogram0 called the 6main0 6program.0 Execution of the program consists of execution of the
     main program, which may invoke subprograms declared in the other compilation units of the program.

     1Program0 1unit.0 A program unit is any one of a 6generic0 6unit,0 6package,0 6subprogram,
0     or 6task0 6unit.

0     1Qualified0 1expression.0 A qualified expression is an 6expression0 preceded by an indication of
     its 6type0 or 6subtype.0 Such qualification is used when, in its absence, the expression might be
     ambiguous (for example as a consequence of 6overloading).

0     1Raising0 1an0 1exception.0 See 6exception.

0     1Range.0 A range is a contiguous set of values of a 6scalar0 6type.0 A range is specified by giving
     the lower and upper bounds for the values.  A value in the range is said to 6belong0 to the range.

     1Range0 1constraint.0 A range constraint of a 6type0 specifies a 6range,0 and thereby determines
     the subset of the values of the type that 6belong0 to the range.

     1Real0 1type.0 A real type is a 6type0 whose values represent approximations to the real numbers.
     There are two kinds of real type:  6fixed0 6point0 6types0 are specified by absolute error bound;
     6floating0 6point0 6types0 are specified by a relative error bound expressed as a number of
     significant decimal digits.

     1Record0 1type.0 A value of a record type consists of 6components0 which are usually of different
     6types0 or 6subtypes.0 For each component of a record value or record 6object,0 the definition of
     the record type specifies an identifier that uniquely determines the component within the record.

     1Renaming0 1declaration.0 A renaming declaration declares another 6name0 for an entity.

     1Rendezvous.0 A rendezvous is the interaction that occurs between two parallel 6tasks0 when one task
     has called an 6entry0 of the other task, and a corresponding 6accept0 6statement0 is being executed
     by the other task on behalf of the calling task.

     1Representation0 1clause.0 A representation clause directs the compiler in the selection of the
     mapping of a 6type,0 an 6object,0 or a 6task0 onto features of the underlying machine that executes
     a program.  In some cases, representation clauses completely specify the mapping; in other cases, they
     provide criteria for choosing a mapping.

     1Satisfy.0 See 6constraint,0 6subtype.

0     1Scalar0 1type.0 An 6object0 or value of a scalar 6type0 does not have 6components.0 A scalar
     type is either a 6discrete0 6type0 or a 6real0 6type.0 The values of a scalar type are ordered.

     1Scope.0 See 6declaration.

0     1Selected0 1component.0 A selected component is a 6name0 consisting of a 6prefix0 and of an
     identifier called the 6selector.0 Selected components are used to denote record components,
     6entries,0 and 6objects0 designated by access values; they are also used as 6expanded0 6names.

0     1Selector.0 See 6selected0 6component.

0     1Simple0 1name.0 See 6declaration,0 6name.

0     1Statement.0 A statement specifies one or more actions to be performed during the execution of a
     6program.

0     1Subcomponent.0 A subcomponent is either a 6component,0 or a component of another subcomponent.

     1Subprogram.0 A subprogram is either a 6procedure0 or a 6function.0 A procedure specifies a
     sequence of actions and is invoked by a 6procedure0 6call0 statement.  A function specifies a
     sequence of actions and also returns a value called the 6result,0 and so a 6function0 6call0 is an
     6expression.0 A subprogram is written as a 6subprogram0 6declaration,0 which specifies its
     6name,0 6formal0 6parameters,0 and (for a function) its result; and a 6subprogram0 6body0 which
     specifies the sequence of actions.  The subprogram call specifies the 6actual0 6parameters0 that are
     to be associated with the formal parameters.  A subprogram is one of the kinds of 6program0 6unit.

0     1Subtype.0 A subtype of a 6type0 characterizes a subset of the values of the type.  The subset is
     determined by a 6constraint0 on the type.  Each value in the set of values of a subtype 6belongs0 to
     the subtype and 6satisfies0 the constraint determining the subtype.

     1Subunit.0 See 6body.

0     1Task.0 A task operates in parallel with other parts of the program.  It is written as a 6task
0     6specification0 (which specifies the 6name0 of the task and the names and 6formal0 6parameters
0     of its entries), and a 6task0 6body0 which defines its execution.  A 6task0 6unit0 is one of the
     kinds of 6program0 6unit.0 A 6task0 6type0 is a 6type0 that permits the subsequent
     6declaration0 of any number of similar tasks of the type.  A value of a task type is said to
     6designate0 a task.

     1Type.0 A type characterizes both a set of values, and a set of 6operations0 applicable to those
     values.  A 6type0 6definition0 is a language construct that defines a type.  A particular type is
     either an 6access0 6type,0 an 6array0 6type,0 a 6private0 6type,0 a 6record0 6type,0 a
     6scalar0 6type,0 or a 6task0 6type.

0     1Use0 1clause.0 A use clause achieves 6direct0 6visibility0 of 6declarations0 that appear in
     the 6visible0 6parts0 of named 6packages.

0     1Variable.0 See 6object.

0     1Variant0 1part.0 A variant part of a 6record0 specifies alternative record 6components,
0     depending on a 6discriminant0 of the record.  Each value of the discriminant establishes a particular
     alternative of the variant part.

     1Visibility.0 At a given point in a program text, the 6declaration0 of an entity with a certain
     identifier is said to be 6visible0 if the entity is an acceptable meaning for an occurrence at that
     point of the identifier.  The declaration is 6visible0 by 6selection0 at the place of the
     6selector0 in a 6selected0 6component0 or at the place of the name in a 6named0 6association.
0     Otherwise, the declaration is 6directly0 6visible,0 that is, if the identifier alone has that
     meaning.

     1Visible0 1part.0 See 6package.

0     1With0 1clause.0 See 6compilation0 6unit. 0

      chapter lrm-appendix-e



     5E. Syntax Summary

0         2.1

         graphic_character ::= basic_graphic_character
           | lower_case_letter | other_special_character

         basic_graphic_character ::=
            upper_case_letter    | digit
           |   special_character    | space_character

         basic_character ::=
               basic_graphic_character | format_effector

         2.3

         identifier ::=
           letter {[underline] letter_or_digit}

         letter_or_digit ::= letter | digit

         letter ::= upper_case_letter | lower_case_letter

         2.4

         numeric_literal   ::= decimal_literal | based_literal

         2.4.1

         decimal_literal   ::= integer [.integer] [exponent]

         integer  ::= digit {[underline] digit}

         exponent    ::= E [+] integer | E - integer

         2.4.2

         based_literal ::=
           base # based_integer [.based_integer] # [exponent]

         base ::= integer

         based_integer ::=
           extended_digit {[underline] extended_digit}

         extended_digit ::= digit | letter

         2.5

         character_literal ::= 'graphic_character'

         2.6

         string_literal ::= "{graphic_character}"

         2.8

         pragma ::=
           1pragma0 identifier [(argument_association
                    .....{, argument_association})];

         argument_association ::=
               [6argument0_identifier =>] name
           |   [6argument0_identifier =>] expression

         3.1

         basic_declaration ::=
               object_declaration   | number_declaration
           |   type_declaration  | subtype_declaration
           |   subprogram_declaration  | package_declaration
           |   task_declaration  | generic_declaration
           |   exception_declaration   | generic_instantiation
           |   renaming_declaration    | deferred_constant_declaration

         3.2

         object_declaration ::=
               identifier_list : [_constant] subtype_indication   [:= expression];
           |   identifier_list : [_constant] constrained_array_definition
               [:= expression];

         number_declaration ::=
            identifier_list : 1constant0 := 6universal0_6static0_expression;

         identifier_list ::=  identifier {, identifier}

         3.3.1

         type_declaration ::=  full_type_declaration
           |   incomplete_type_declaration | private_type_declaration

         full_type_declaration ::=
            1type0 identifier [discriminant_part] 1is0 type_definition;

         type_definition ::=
               enumeration_type_definition   | integer_type_definition
           |   real_type_definition    | array_type_definition
           |   record_type_definition  | access_type_definition
           |   derived_type_definition

         3.3.2

         subtype_declaration ::=
           1subtype0 identifier 1is0 subtype_indication;

         subtype_indication ::=  type_mark [constraint]

         type_mark ::= 6type0_name | 6subtype0_name

         constraint ::=
               range_constraint  | floating_point_constraint
           |   fixed_point_constraint  | index_constraint
           |   discriminant_constraint

         3.4

         derived_type_definition ::= 1new0 subtype_indication

         3.5

         range_constraint ::=  1range0 range

         range ::=  6range0_attribute
           | simple_expression .. simple_expression

         3.5.1

         enumeration_type_definition ::=
           (enumeration_literal_specification
              {, enumeration_literal_specification})

         enumeration_literal_specification ::=  enumeration_literal

         enumeration_literal ::=  identifier | character_literal

         3.5.4

         integer_type_definition ::=  range_constraint

         3.5.6

         real_type_definition ::=
           floating_point_constraint | fixed_point_constraint

         3.5.7

         floating_point_constraint ::=
           floating_accuracy_definition [range_constraint]

         floating_accuracy_definition ::=
           1digits0 6static0_simple_expression

         3.5.9

         fixed_point_constraint ::=
           fixed_accuracy_definition [range_constraint]

         fixed_accuracy_definition ::=
           1delta0 6static0_simple_expression

         3.6

         array_type_definition ::=
           unconstrained_array_definition | constrained_array_definition

         unconstrained_array_definition ::=
           1array(index_subtype_definition0 {, index_subtype_definition}) 1of
0                    6component0_subtype_indication

         constrained_array_definition ::=
           1array0 index_constraint 1of0 6component0_subtype_indication

         index_subtype_definition ::= type_mark 1range0 <>

         index_constraint  ::=  (discrete_range {, discrete_range})

         discrete_range ::= 6discrete0_subtype_indication | range

         3.7

         record_type_definition ::=
           1record
0              component_list
           1end0 1record

0         component_list ::=
              component_declaration {component_declaration}
           | {   component_declaration} variant_part
           |  1null;

0         component_declaration ::=
           identifier_list : component_subtype_definition [:= expression];

         component_subtype_definition ::=  subtype_indication

         3.7.1

         discriminant_part ::=
           (discriminant_specification {; discriminant_specification})

         discriminant_specification ::=
           identifier_list : type_mark [:= expression]

         3.7.2

         discriminant_constraint ::=
           (discriminant_association {, discriminant_association})

         discriminant_association ::=
           [6discriminant0_simple_name {| 6discriminant0_simple_name} =>]
                    expression

         3.7.3

         variant_part ::=
           1case0 6discriminant0_simple_name 1is
0           variant
              {  variant}
           1end0 1case;

0         variant ::=
           1when0 choice {| choice} =>
              component_list

         choice ::= simple_expression
           | discrete_range | 1others0 | 6component0_simple_name

         3.8

         access_type_definition ::= 1access0 subtype_indication

         3.8.1

         incomplete_type_declaration ::=
           1type0 identifier [discriminant_part];

         3.9

         declarative_part ::=
           {basic_declarative_item} {later_declarative_item}

         basic_declarative_item ::= basic_declaration
           | representation_clause | use_clause

         later_declarative_item ::= body
           |   subprogram_declaration  | package_declaration
           |   task_declaration  | generic_declaration
           |   use_clause  | generic_instantiation

         body ::= proper_body | body_stub

         proper_body ::=
           subprogram_body | package_body | task_body

         4.1

         name ::= simple_name
           | character_literal   | operator_symbol
           | indexed_component   | slice
           | selected_component  | attribute

         simple_name ::= identifier

         prefix ::= name | function_call

         4.1.1

         indexed_component ::= prefix(expression {, expression})

         4.1.2

         slice ::= prefix(discrete_range)

         4.1.3

         selected_component ::= prefix.selector

         selector ::= simple_name
           | character_literal | operator_symbol | 1all

0         4.1.4

         attribute ::= prefix'attribute_designator

         attribute_designator ::=
           simple_name [(6universal0_6static0_expression)]

         4.3

         aggregate ::=
           (component_association   {, component_association})

         component_association ::=
           [choice {| choice} => ] expression

         4.4

         expression ::=
               relation {_and relation}   | relation {_and 1then0 relation}
           |   relation {_or relation}    | relation {_or 1else0 relation}
           |   relation {_xor relation}

         relation ::=
               simple_expression [relational_operator simple_expression]
           |   simple_expression [_not] 1in0 range
           |   simple_expression [_not] 1in0 type_mark

         simple_expression ::=
           [unary_adding_operator] term {binary_adding_operator term}

         term ::= factor {multiplying_operator factor}

         factor ::= primary [** primary] | 1abs0 primary | 1not0 primary

         primary ::=
               numeric_literal | 1null0 | aggregate | string_literal
           |   name | allocator | function_call | type_conversion
           |   qualified_expression | (expression)

         4.5

         logical_operator   ::=  1and   0 | 1or   0 | 1xor  

0         relational_operator   ::=  =  | /=  | <   | <=  | >   | >=

         binary_adding_operator   ::=  +  | -   | &

         unary_adding_operator    ::=  +  | -

         multiplying_operator     ::=  *  | /   | 1mod 0 | 1rem

0         highest_precedence_operator    ::=  **    | 1abs 0 | 1not

0         4.6

         type_conversion ::= type_mark(expression)

         4.7

         qualified_expression ::=
           type_mark'(expression) | type_mark'aggregate

         4.8

         allocator ::=
           1new0 subtype_indication | 1new0 qualified_expression

         5.1

         sequence_of_statements ::= statement {statement}

         statement ::=
           {  label} simple_statement | {label} compound_statement

         simple_statement ::= null_statement
           |   assignment_statement    | procedure_call_statement
           |   exit_statement    | return_statement
           |   goto_statement    | entry_call_statement
           |   delay_statement   | abort_statement
           |   raise_statement   | code_statement

         compound_statement ::=
               if_statement   | case_statement
           |   loop_statement    | block_statement
           |   accept_statement  | select_statement

         label ::= <<6label0_simple_name>>

         null_statement ::= 1null;

0         5.2

         assignment_statement ::=
           6variable0_name := expression;

         5.3

         if_statement ::=
           1if0 condition 1then
0              sequence_of_statements
           {  1elsif0 condition 1then
0              sequence_of_statements}
           [  1else
0              sequence_of_statements]
           1end0 1if;

0         condition ::= 6boolean0_expression

         5.4

         case_statement ::=
           1case0 expression 1is
0           case_statement_alternative
              {  case_statement_alternative}
           1end0 1case;

0         case_statement_alternative ::=
           1when0 choice {| choice } =>
              sequence_of_statements

         5.5

         loop_statement ::=
           [6loop0_simple_name:]
              [  iteration_scheme] 1loop
0                 sequence_of_statements
           1end0 1loop0 [6loop0_simple_name];

         iteration_scheme ::= 1while0 condition
           |   1for0 loop_parameter_specification

         loop_parameter_specification ::=
           identifier 1in0 [_reverse] discrete_range

         5.6

         block_statement ::=
           [6block0_simple_name:]
              [  1declare
0                 declarative_part]
           1begin
0                 sequence_of_statements
              [  1exception
0                 exception_handler
              {  exception_handler}]
           1end0 [6block0_simple_name];

         5.7

         exit_statement ::=
           1exit0 [6loop0_name] [_when condition];

         5.8

         return_statement ::= 1return0 [expression];

         5.9

         goto_statement ::= 1goto0 6label0_name;

         6.1

         subprogram_declaration ::= subprogram_specification;

         subprogram_specification ::=
               1procedure0 identifier   [formal_part]
           |   1function0 designator    [formal_part] 1return0 type_mark

         designator ::= identifier | operator_symbol

         operator_symbol ::= string_literal

         formal_part ::=
           (parameter_specification {; parameter_specification})

         parameter_specification ::=
           identifier_list : mode type_mark [:= expression]
         mode ::= [_in] | 1in0 1out0 | 1out

0         6.3

         subprogram_body ::=
           subprogram_specification 1is
0              [  declarative_part]
           1begin
0                 sequence_of_statements
           [  1exception
0                 exception_handler
              {  exception_handler}]
           1end0 [designator];

         6.4

         procedure_call_statement ::=
           6procedure0_name [actual_parameter_part];

         function_call ::=
           6function0_name [actual_parameter_part]

         actual_parameter_part ::=
           (parameter_association {, parameter_association})

         parameter_association ::=
           [  formal_parameter =>] actual_parameter

         formal_parameter ::= 6parameter0_simple_name

         actual_parameter ::=
           expression | 6variable0_name | type_mark(6variable0_name)

         7.1

         package_declaration ::= package_specification;

         package_specification ::=
           1package0 identifier 1is
0              {basic_declarative_item}
           [  1private
0              {basic_declarative_item}]
           1end0 [6package0_simple_name]

         package_body ::=
           1package0 1body0 6package0_simple_name 1is
0              [  declarative_part]
           [  1begin
0                 sequence_of_statements
           [  1exception
0                 exception_handler
              {  exception_handler}]]
           1end0 [6package0_simple_name];

         7.4

         private_type_declaration ::=
           1type0 identifier [discriminant_part] 1is0 [_limited] 1private;

0         deferred_constant_declaration ::=
           identifier_list : 1constant0 type_mark;

         8.4

         use_clause ::= 1use0 6package0_name {, 6package0_name};
         8.5

         renaming_declaration ::=
               identifier : type_mark  1renames0 6object0_name;
           |   identifier : 1exception  0 1renames0 6exception0_name;
           |   1package0 identifier  1renames0 6package0_name;
           |   subprogram_specification   1renames0 6subprogram0_6or0_6entry0_name;

         9.1

         task_declaration ::= task_specification;

         task_specification ::=
           1task0 [_type] identifier [_is
              {entry_declaration}
              {representation_clause}
           1end0 [6task0_simple_name]]

         task_body ::=
           1task0 1body0 6task0_simple_name 1is
0              [  declarative_part]
           1begin
0                 sequence_of_statements
           [  1exception
0                 exception_handler
              {  exception_handler}]
           1end0 [6task0_simple_name];

         9.5

         entry_declaration ::=
           1entry0 identifier [(discrete_range)] [formal_part];

         entry_call_statement ::=
           6entry0_name [actual_parameter_part];

         accept_statement ::=
           1accept0 6entry0_simple_name [(entry_index)] [formal_part] [_do
              sequence_of_statements
           1end0 [6entry0_simple_name]];

         entry_index ::= expression

         9.6

         delay_statement ::= 1delay0 simple_expression;

         9.7

         select_statement ::= selective_wait
           | conditional_entry_call | timed_entry_call

         9.7.1

         selective_wait ::=
           1select
0              select_alternative
           {  1or
0              select_alternative}
           [  1else
0              sequence_of_statements]
           1end0 1select;

0         select_alternative ::=
           [  1when0 condition =>]
              selective_wait_alternative

         selective_wait_alternative ::= accept_alternative
           | delay_alternative | terminate_alternative

         accept_alternative   ::=
           accept_statement   [sequence_of_statements]

         delay_alternative    ::=
           delay_statement    [sequence_of_statements]

         terminate_alternative ::= 1terminate;

0         9.7.2

         conditional_entry_call ::=
           1select
0           entry_call_statement
              [  sequence_of_statements]
           1else
0           sequence_of_statements
           1end0 1select;

0         9.7.3

         timed_entry_call ::=
           1select
0           entry_call_statement
              [  sequence_of_statements]
           1or
0           delay_alternative
           1end0 1select;

0         9.10

         abort_statement ::= 1abort0 6task0_name {, 6task0_name};

         10.1

         compilation ::= {compilation_unit}

         compilation_unit ::=
               context_clause library_unit
           |   context_clause secondary_unit

         library_unit ::=
               subprogram_declaration  | package_declaration
           |   generic_declaration  | generic_instantiation
           |   subprogram_body

         secondary_unit ::= library_unit_body | subunit

         library_unit_body ::= subprogram_body | package_body

         10.1.1

         context_clause ::= {with_clause {use_clause}}

         with_clause ::=
           1with0 6unit0_simple_name {, 6unit0_simple_name};

         10.2

         body_stub ::=
               subprogram_specification 1is0 1separate;
0           |   1package0 1body0 6package0_simple_name 1is0 1separate;
0           |   1task0 1body0 6task0_simple_name 1is0 1separate;

0         subunit ::= 1separate0 (6parent0_6unit0_name) proper_body

         11.1

         exception_declaration ::= identifier_list : 1exception;

0         11.2

         exception_handler ::=
           1when0 exception_choice {| exception_choice} =>
              sequence_of_statements

         exception_choice ::= 6exception0_name | 1others

0         11.3

         raise_statement ::= 1raise0 [6exception0_name];

         12.1

         generic_declaration ::= generic_specification;

         generic_specification ::=
               generic_formal_part subprogram_specification
           |   generic_formal_part package_specification

         generic_formal_part ::= 1generic0 {generic_parameter_declaration}

         generic_parameter_declaration ::=
               identifier_list : [_in [_out]] type_mark [:= expression];
           |   1type0 identifier 1is0 generic_type_definition;
           |   private_type_declaration
           |   1with0 subprogram_specification [_is name];
           |   1with0 subprogram_specification [_is <>];

         generic_type_definition ::=
            (<>) | 1range0 <> | 1digits0 <> | 1delta0 <>
           |   array_type_definition | access_type_definition

         12.3

         generic_instantiation ::=
               1package0 identifier 1is
0                 1new0 6generic0_6package0_name [generic_actual_part];
           |   1procedure0 identifier 1is
0                 1new0 6generic0_6procedure0_name [generic_actual_part];
           |   1function0 designator 1is
0                 1new0 6generic0_6function0_name [generic_actual_part];

         generic_actual_part ::=
           (generic_association {, generic_association})

         generic_association ::=
           [generic_formal_parameter =>] generic_actual_parameter

         generic_formal_parameter ::=
           6parameter0_simple_name | operator_symbol

         generic_actual_parameter ::= expression | 6variable0_name
           | 6subprogram0_name | 6entry0_name | type_mark

         13.1

         representation_clause ::=
            type_representation_clause | address_clause

         type_representation_clause ::= length_clause
           |   enumeration_representation_clause
           |   record_representation_clause

         13.2

         length_clause ::= 1for0 attribute 1use0 simple_expression;

         13.3

         enumeration_representation_clause ::=
           1for0 6type0_simple_name 1use0 aggregate;

         13.4

         record_representation_clause ::=
           1for0 6type0_simple_name 1use
0              1record0 [alignment_clause]
                 {component_clause}
              1end0 1record;

0         alignment_clause ::= 1at0 1mod0 6static0_simple_expression;

         component_clause ::=
           6component0_name    1at0 6static0_simple_expression
            1range0 6static0_range;

         13.5

         address_clause ::=
           1for0 simple_name 1use0 1at0 simple_expression;

         13.8

         code_statement ::= type_mark'6record0_aggregate;

      chapter lrm-appendix-f



     5F. Implementation-Dependent Characteristics

0     The Ada language definition allows for certain machine-dependences in a controlled manner. No
     machine-dependent syntax or semantic extensions or restrictions are allowed.  The only allowed
     implementation-dependences correspond to implementation-dependent pragmas and attributes, certain
     machine-dependent conventions as mentioned in chapter 13, and certain allowed restrictions on
     representation clauses.

     The reference manual of each Ada implementation must include an appendix (called Appendix F) that
     describes all implementation-dependent characteristics.  The appendix F for a given implementation must
     list in particular:

        1. The form, allowed places, and effect of every implementation-dependent pragma.

        2. The name and the type of every implementation-dependent attribute.

        3. The specification of the package SYSTEM (see 13.7).

        4. The list of all restrictions on representation clauses (see 13.1)

        5. The conventions used for any implementation-generated name denoting implementation-dependent
           components (see 13.4).

        6. The interpretation of expressions that ppear in address clauses, including those for
           interrupts (see 13.5).

        7. Any restriction on unchecked conversions (see 13.10.2).

        8. Any implementation-dependent characteristics of the input-output packages (see 14).