emacs-elpa-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[elpa] externals/ada-ref-man 158227b 01/18: publish ada-mode 5.1.6, wisi


From: Stefan Monnier
Subject: [elpa] externals/ada-ref-man 158227b 01/18: publish ada-mode 5.1.6, wisi 1.0.6, new package ada-ref-man
Date: Sun, 29 Nov 2020 19:04:39 -0500 (EST)

branch: externals/ada-ref-man
commit 158227bd6d735ccc43e1d3075e419ddcdfa3fb82
Author: Stephen Leake <stephen_leake@stephe-leake.org>
Commit: Stephen Leake <stephen_leake@stephe-leake.org>

    publish ada-mode 5.1.6, wisi 1.0.6, new package ada-ref-man
    
    * admin/archive-contents.el (archive--metadata): include 'dir' in files, 
for doc-only packages
      (archive--metadata): fix typo in error message
    
    * packages/ada-mode/ada-ref-man.el: New file.
    * packages/ada-mode/*: version 5.1.6
    
    * packages/ada-ref-man/: New directory.
    
    * packages/wisi/*: version 1.0.6
    * packages/wisi/README: New file.
---
 README         |     10 +
 aarm2012.info  | 147476 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ada-ref-man.el |     12 +
 arm2012.info   |  97779 ++++++++++++++++++++++++++++++++++++
 dir            |      7 +
 5 files changed, 245284 insertions(+)

diff --git a/README b/README
new file mode 100755
index 0000000..f80fab9
--- /dev/null
+++ b/README
@@ -0,0 +1,10 @@
+Emacs info version of Ada Reference Manual 2012
+
+The Ada Reference Manual is provided as a Gnu ELPA package; to install
+the package, add to ~./emacs:
+
+(package-initialize)
+
+then invoke M-x list-packages, install Ada Reference Manual.
+
+(end of file)
diff --git a/aarm2012.info b/aarm2012.info
new file mode 100644
index 0000000..419a80e
--- /dev/null
+++ b/aarm2012.info
@@ -0,0 +1,147476 @@
+This is aarm2012.info, produced by texi2any version 5.2 from
+aarm2012.texinfo.
+
+INFO-DIR-SECTION GNU Ada tools
+START-INFO-DIR-ENTRY
+* Ada Reference Manual: (arm2012).
+* Annotated ARM: (arm2012).
+END-INFO-DIR-ENTRY
+
+
+File: aarm2012.info,  Node: Top,  Next: Front Matter,  Up: (dir)
+
+Annotated Ada Reference Manual
+******************************
+
+Ada Reference Manual, ISO/IEC 8652:2012(E)
+
+                    Annotated Ada Reference Manual
+
+                         ISO/IEC 8652:2012(E)
+
+                    Language and Standard Libraries
+
+* Menu:
+
+* Front Matter:: Copyright, Foreword, etc.
+* 1 ::        General
+* 2 ::        Lexical Elements
+* 3 ::        Declarations and Types
+* 4 ::        Names and Expressions
+* 5 ::        Statements
+* 6 ::        Subprograms
+* 7 ::        Packages
+* 8 ::        Visibility Rules
+* 9 ::        Tasks and Synchronization
+* 10 ::       Program Structure and Compilation Issues
+* 11 ::       Exceptions
+* 12 ::       Generic Units
+* 13 ::       Representation Issues
+* Annex A ::  Predefined Language Environment
+* Annex B ::  Interface to Other Languages
+* Annex C ::  Systems Programming
+* Annex D ::  Real-Time Systems
+* Annex E ::  Distributed Systems
+* Annex F ::  Information Systems
+* Annex G ::  Numerics
+* Annex H ::  High Integrity Systems
+* Annex J ::  Obsolescent Features
+* Annex K ::  Language-Defined Aspects and Attributes
+* Annex L ::  Language-Defined Pragmas
+* Annex M ::  Summary of Documentation Requirements
+* Annex N ::  Glossary
+* Annex P ::  Syntax Summary
+* Annex Q ::  Language-Defined Entities
+* Index ::    Index
+
+
+File: aarm2012.info,  Node: Front Matter,  Next: 1,  Prev: Top,  Up: Top
+
+Front Matter
+************
+
+Copyright � 1992, 1993, 1994, 1995 Intermetrics, Inc.
+
+Copyright � 2000 The MITRE Corporation, Inc.
+
+Copyright � 2004, 2005, 2006 AXE Consultants
+
+Copyright � 2004, 2005, 2006 Ada-Europe
+
+Copyright � 2008, 2009, 2010, 2011, 2012 AXE Consultants
+
+ 
+
+
+
+
+
+Ada Reference Manual - Language and Standard Libraries
+
+Copyright � 1992, 1993, 1994, 1995, Intermetrics, Inc.
+
+This copyright is assigned to the U.S. Government.  All rights reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy.  Compiled copies of standard library units and
+examples need not contain this copyright notice so long as the notice is
+included in all copies of source code and documentation.
+
+-------  
+
+Technical Corrigendum 1
+
+Copyright � 2000, The MITRE Corporation.  All Rights Reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy.  Any other use or distribution of this document
+is prohibited without the prior express permission of MITRE.
+
+You use this document on the condition that you indemnify and hold
+harmless MITRE, its Board of Trustees, officers, agents, and employees,
+from any and all liability or damages to yourself or your hardware or
+software, or third parties, including attorneys' fees, court costs, and
+other related costs and expenses, arising out of your use of this
+document irrespective of the cause of said liability.
+
+MITRE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO
+WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY
+MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL MITRE
+BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL,
+EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF MITRE HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ 
+
+Amendment 1
+
+Copyright � 2004, 2005, 2006, 2007, AXE Consultants.  All Rights
+Reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy.  Any other use or distribution of this document
+is prohibited without the prior express permission of AXE.
+
+You use this document on the condition that you indemnify and hold
+harmless AXE, its board, officers, agents, and employees, from any and
+all liability or damages to yourself or your hardware or software, or
+third parties, including attorneys' fees, court costs, and other related
+costs and expenses, arising out of your use of this document
+irrespective of the cause of said liability.
+
+AXE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO
+WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY
+MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL AXE
+BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL,
+EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF AXE HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+Third Edition
+
+Copyright � 2008, 2009, 2010, 2011, 2012 AXE Consultants.  All Rights
+Reserved.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy.  Any other use or distribution of this document
+is prohibited without the prior express permission of AXE.
+
+You use this document on the condition that you indemnify and hold
+harmless AXE, its board, officers, agents, and employees, from any and
+all liability or damages to yourself or your hardware or software, or
+third parties, including attorneys' fees, court costs, and other related
+costs and expenses, arising out of your use of this document
+irrespective of the cause of said liability.
+
+AXE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO
+WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY
+MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL AXE
+BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL,
+EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF AXE HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ 
+
+Ada 2005 Consolidated Standard
+
+Copyright � 2004, 2005, 2006, Ada-Europe.
+
+This document may be copied, in whole or in part, in any form or by any
+means, as is, or with alterations, provided that (1) alterations are
+clearly marked as alterations and (2) this copyright notice is included
+unmodified in any copy.  Any other use or distribution of this document
+is prohibited without the prior express permission of Ada-Europe.
+
+You use this document on the condition that you indemnify and hold
+harmless Ada-Europe and its Board from any and all liability or damages
+to yourself or your hardware or software, or third parties, including
+attorneys' fees, court costs, and other related costs and expenses,
+arising out of your use of this document irrespective of the cause of
+said liability.
+
+ADA-EUROPE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES
+NO WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY,
+EFFICIENCY MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT
+WILL ADA-EUROPE BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT,
+INCIDENTAL, EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF ADA-EUROPE HAS BEEN
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+* Menu:
+
+* 0.1 :: Foreword to this version of the Ada Reference Manual
+* 0.2 :: Foreword
+* 0.3 :: Introduction
+* 0.99 :: International Standard
+
+
+File: aarm2012.info,  Node: 0.1,  Next: 0.2,  Up: Front Matter
+
+0.1 Foreword
+============
+
+1/3
+ISO (the International Organization for Standardization) and IEC (the
+International Electrotechnical Commission) form the specialized system
+for worldwide standardization.  National bodies that are members of ISO
+or IEC participate in the development of International Standards through
+technical committees established by the respective organization to deal
+with particular fields of technical activity.  ISO and IEC technical
+committees collaborate in fields of mutual interest.  Other
+international organizations, governmental and non-governmental, in
+liaison with ISO and IEC, also take part in the work.  In the field of
+information technology, ISO and IEC have established a joint technical
+committee, ISO/IEC JTC 1.
+
+1.1/3
+International Standards are drafted in accordance with the rules given
+in the ISO/IEC Directives, Part 2.
+
+2/3
+The main task of the joint technical committee is to prepare
+International Standards.  Draft International Standards adopted by the
+joint technical committee are circulated to national bodies for voting.
+Publication as an International Standard requires approval by at least
+75 % of the national bodies casting a vote.
+
+2.1/3
+Attention is drawn to the possibility that some of the elements of this
+document may be the subject of patent rights.  ISO and IEC shall not be
+held responsible for identifying any or all such patent rights.
+
+3/3
+International Standard ISO/IEC 8652 was prepared by Joint Technical
+Committee ISO/IEC JTC 1, Information Technology Subcommittee SC22,
+Programming languages, their environments and system software
+interfaces.
+
+4/3
+{AI05-0299-1AI05-0299-1} This third edition cancels and replaces the
+second edition (ISO/IEC 8652:1995), which has been technically revised.
+It also incorporates the Technical Corrigendum ISO/IEC
+8652:1995:COR.1:2001 and Amendment ISO/IEC 8652:1995:AMD 1:2007.
+
+5.a/3
+          Discussion: This document is the Annotated Ada Reference
+          Manual (AARM). It contains the entire text of the Ada 2012
+          standard (ISO/IEC 8652:201x), plus various annotations.  It is
+          intended primarily for compiler writers, validation test
+          writers, and other language lawyers.  The annotations include
+          detailed rationale for individual rules and explanations of
+          some of the more arcane interactions among the rules.
+
+
+File: aarm2012.info,  Node: 0.2,  Next: 0.99,  Prev: 0.1,  Up: Front Matter
+
+0.2 Introduction
+================
+
+1
+This is the Annotated Ada Reference Manual.
+
+2
+Other available Ada documents include:
+
+3/3
+   * {AI95-00387-01AI95-00387-01} {AI05-0245-1AI05-0245-1} Ada 2012
+     Rationale.  This gives an introduction to the changes and new
+     features in Ada 2012, and explains the rationale behind them.
+     Programmers should read this rationale before reading this Standard
+     in depth.  Rationales for Ada 83, Ada 95, and Ada 2005 are also
+     available.
+
+3.a/3
+          Discussion: {AI05-0245-1AI05-0245-1} As of this writing
+          (December 2012), only five chapters of the Ada 2012 Rationale
+          have been published.  Additional chapters are in development
+          and should be published during 2013.
+
+4/1
+   * This paragraph was deleted.
+
+5/3
+   * The Ada Reference Manual (RM). This is the International Standard
+     -- ISO/IEC 8652:201x.
+
+Design Goals
+
+6/3
+{AI95-00387-01AI95-00387-01} Ada was originally designed with three
+overriding concerns: program reliability and maintenance, programming as
+a human activity, and efficiency.  The 1995 revision to the language was
+designed to provide greater flexibility and extensibility, additional
+control over storage management and synchronization, and standardized
+packages oriented toward supporting important application areas, while
+at the same time retaining the original emphasis on reliability,
+maintainability, and efficiency.  This third edition provides further
+flexibility and adds more standardized packages within the framework
+provided by the 1995 revision.
+
+7
+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.
+
+8
+Concern for the human programmer was also stressed during the design.
+Above all, an attempt was made to keep to a relatively small number of
+underlying concepts integrated in a consistent and systematic way while
+continuing to avoid the pitfalls of excessive involution.  The design
+especially aims to provide language constructs that correspond
+intuitively to the normal expectations of users.
+
+9
+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 continues to be a central idea in the 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.  An allied concern is the maintenance of programs to match
+changing requirements; type extension and the hierarchical library
+enable a program to be modified while minimizing disturbance to existing
+tested and trusted components.
+
+10
+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.
+
+Language Summary
+
+11
+An Ada program is composed of one or more program units.  Program units
+may be subprograms (which define executable algorithms), packages (which
+define collections of entities), task units (which define concurrent
+computations), protected units (which define operations for the
+coordinated sharing of data between tasks), or generic units (which
+define parameterized forms of packages and subprograms).  Each program
+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.
+Most program units can be compiled separately.
+
+12
+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.
+
+13
+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.  All libraries are
+structured in a hierarchical manner; this enables the logical
+decomposition of a subsystem into individual components.  The text of a
+separately compiled program unit must name the library units it
+requires.
+
+14
+Program Units
+
+15
+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.
+
+16
+A package is the basic unit for defining a collection of logically
+related entities.  For example, a package can be used to define 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.
+
+17
+Subprogram and package units may be compiled separately and arranged in
+hierarchies of parent and child units giving fine control over
+visibility of the logical properties and their detailed implementation.
+
+18
+A task unit is the basic unit for defining a task whose sequence of
+actions may be executed concurrently 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.
+
+19/2
+{AI95-00114-01AI95-00114-01} A protected unit is the basic unit for
+defining protected operations for the coordinated use of data shared
+between tasks.  Simple mutual exclusion is provided automatically, and
+more elaborate sharing protocols can be defined.  A protected operation
+can either be a subprogram or an entry.  A protected entry specifies a
+Boolean expression (an entry barrier) that must be True before the body
+of the entry is executed.  A protected unit may define a single
+protected object or a protected type permitting the creation of several
+similar objects.
+
+20
+Declarations and Statements
+
+21
+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.
+
+22
+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, protected units, and
+generic units to be used in the program unit.
+
+23
+The sequence of statements describes a sequence of actions that are to
+be performed.  The statements are executed in succession (unless a
+transfer of control causes execution to continue from another place).
+
+24
+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.
+
+25
+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.
+
+26
+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.
+
+27
+A block statement comprises a sequence of statements preceded by the
+declaration of local entities used by the statements.
+
+28
+Certain statements are associated with concurrent execution.  A delay
+statement delays the execution of a task for a specified duration or
+until a specified time.  An entry call statement is written as a
+procedure call statement; it requests an operation on a task or on a
+protected object, blocking the caller until the operation can be
+performed.  A called task may accept an entry call by executing a
+corresponding accept statement, which specifies the actions then to be
+performed as part of the rendezvous with the calling task.  An entry
+call on a protected object is processed when the corresponding entry
+barrier evaluates to true, whereupon the body of the entry is executed.
+The requeue statement permits the provision of a service as a number of
+related activities with preference control.  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 and the asynchronous transfer of control in response
+to some triggering event.
+
+29
+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.
+
+30
+Data Types
+
+31
+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 elementary types (comprising enumeration, numeric, and access types)
+and composite types (including array and record types).
+
+32/2
+{AI95-00285-01AI95-00285-01} {AI95-00387-01AI95-00387-01} 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, Character, Wide_Character, and Wide_Wide_Character are
+predefined.
+
+33
+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.
+
+34/2
+{AI95-00285-01AI95-00285-01} {AI95-00387-01AI95-00387-01} Composite
+types allow definitions of structured objects with related components.
+The composite types in the language include 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.  Task
+and protected types are also forms of composite types.  The array types
+String, Wide_String, and Wide_Wide_String are predefined.
+
+35
+Record, task, and protected types may have special components called
+discriminants which parameterize the type.  Variant record structures
+that depend on the values of discriminants can be defined within a
+record type.
+
+36
+Access types allow the construction of linked data structures.  A value
+of an access type represents a reference to an object declared as
+aliased or to an object created by the evaluation of an allocator.
+Several variables of an access type may designate the same object, and
+components of one object may designate the same or other objects.  Both
+the elements in such linked data structures and their relation to other
+elements can be altered during program execution.  Access types also
+permit references to subprograms to be stored, passed as parameters, and
+ultimately dereferenced as part of an indirect call.
+
+37
+Private types permit restricted views of a type.  A private type can be
+defined in a package so that only the logically necessary properties are
+made visible to the users of the type.  The full structural details that
+are externally irrelevant are then only available within the package and
+any child units.
+
+38
+From any type a new type may be defined by derivation.  A type, together
+with its derivatives (both direct and indirect) form a derivation class.
+Class-wide operations may be defined that accept as a parameter an
+operand of any type in a derivation class.  For record and private
+types, the derivatives may be extensions of the parent type.  Types that
+support these object-oriented capabilities of class-wide operations and
+type extension must be tagged, so that the specific type of an operand
+within a derivation class can be identified at run time.  When an
+operation of a tagged type is applied to an operand whose specific type
+is not known until run time, implicit dispatching is performed based on
+the tag of the operand.
+
+38.1/2
+{AI95-00387-01AI95-00387-01} Interface types provide abstract models
+from which other interfaces and types may be composed and derived.  This
+provides a reliable form of multiple inheritance.  Interface types may
+also be implemented by task types and protected types thereby enabling
+concurrent programming and inheritance to be merged.
+
+39
+The concept of a type is further 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.
+
+40
+Other Facilities
+
+41/2
+{AI95-00387-01AI95-00387-01} Aspect 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.
+
+42/2
+{AI95-00387-01AI95-00387-01} The predefined environment of the language
+provides for input-output and other capabilities by means of standard
+library packages.  Input-output is supported for values of user-defined
+as well as of predefined types.  Standard means of representing values
+in display form are also provided.
+
+42.1/2
+{AI95-00387-01AI95-00387-01} The predefined standard library packages
+provide facilities such as string manipulation, containers of various
+kinds (vectors, lists, maps, etc.), mathematical functions, random
+number generation, and access to the execution environment.
+
+42.2/2
+{AI95-00387-01AI95-00387-01} The specialized annexes define further
+predefined library packages and facilities with emphasis on areas such
+as real-time scheduling, interrupt handling, distributed systems,
+numerical computation, and high-integrity systems.
+
+43
+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 packages) and so allow
+general algorithms and data structures to be defined that are applicable
+to all types of a given class.
+
+Language Changes
+
+Paragraphs 44 through 57 have been removed as they described differences
+from the first edition of Ada (Ada 83).
+
+57.1/3
+{AI95-00387-01AI95-00387-01} This International Standard replaces the
+second edition of 1995.  It modifies the previous edition by making
+changes and additions that improve the capability of the language and
+the reliability of programs written in the language.  This edition
+incorporates the changes from Amendment 1 (ISO/IEC 8652:1995:AMD
+1:2007), which were designed to improve the portability of programs,
+interfacing to other languages, and both the object-oriented and
+real-time capabilities.
+
+57.2/3
+{AI95-00387-01AI95-00387-01} {AI05-0299-1AI05-0299-1} Significant
+changes originating in Amendment 1 are incorporated:
+
+57.3/3
+   * Support for program text is extended to cover the entire ISO/IEC
+     10646:2003 repertoire.  Execution support now includes the 32-bit
+     character set.  See subclauses *note 2.1::, *note 3.5.2::, *note
+     3.6.3::, *note A.1::, *note A.3::, and *note A.4::.
+
+57.4/3
+   * The object-oriented model has been improved by the addition of an
+     interface facility which provides multiple inheritance and
+     additional flexibility for type extensions.  See subclauses *note
+     3.4::, *note 3.9::, and *note 7.3::.  An alternative notation for
+     calling operations more akin to that used in other languages has
+     also been added.  See subclause *note 4.1.3::.
+
+57.5/3
+   * Access types have been further extended to unify properties such as
+     the ability to access constants and to exclude null values.  See
+     clause *note 3.10::.  Anonymous access types are now permitted more
+     freely and anonymous access-to-subprogram types are introduced.
+     See subclauses *note 3.3::, *note 3.6::, *note 3.10::, and *note
+     8.5.1::.
+
+57.6/3
+   * The control of structure and visibility has been enhanced to permit
+     mutually dependent references between units and finer control over
+     access from the private part of a package.  See subclauses *note
+     3.10.1:: and *note 10.1.2::.  In addition, limited types have been
+     made more useful by the provision of aggregates, constants, and
+     constructor functions.  See subclauses *note 4.3::, *note 6.5::,
+     and *note 7.5::.
+
+57.7/3
+   * The predefined environment has been extended to include additional
+     time and calendar operations, improved string handling, a
+     comprehensive container library, file and directory management, and
+     access to environment variables.  See subclauses *note 9.6.1::,
+     *note A.4::, *note A.16::, *note A.17::, and *note A.18::.
+
+57.8/3
+   * Two of the Specialized Needs Annexes have been considerably
+     enhanced:
+
+57.9/2
+             * The Real-Time Systems Annex now includes the Ravenscar
+               profile for high-integrity systems, further dispatching
+               policies such as Round Robin and Earliest Deadline First,
+               support for timing events, and support for control of CPU
+               time utilization.  See subclauses *note D.2::, *note
+               D.13::, *note D.14::, and *note D.15::.
+
+57.10/3
+             * The Numerics Annex now includes support for real and
+               complex vectors and matrices as previously defined in
+               ISO/IEC 13813:1997 plus further basic operations for
+               linear algebra.  See subclause *note G.3::.
+
+57.11/3
+   * The overall reliability of the language has been enhanced by a
+     number of improvements.  These include new syntax which detects
+     accidental overloading, as well as pragmas for making assertions
+     and giving better control over the suppression of checks.  See
+     subclauses *note 6.1::, *note 11.4.2::, and *note 11.5::.
+
+57.12/3
+{AI05-0245-1AI05-0245-1} In addition, this third edition makes
+enhancements to address two important issues, namely, the particular
+problems of multiprocessor architectures, and the need to further
+increase the capabilities regarding assertions for correctness.  It also
+makes additional changes and additions that improve the capability of
+the language and the reliability of programs written in the language.
+
+57.13/3
+{AI05-0245-1AI05-0245-1} {AI05-0299-1AI05-0299-1} The following
+significant changes with respect to the 1995 edition as amended by
+Amendment 1 are incorporated:
+
+57.14/3
+   * New syntax (the aspect specification) is introduced to enable
+     properties to be specified for various entities in a more
+     structured manner than through pragmas.  See subclause *note
+     13.1.1::.
+
+57.15/3
+   * The concept of assertions introduced in the 2005 edition is
+     extended with the ability to specify preconditions and
+     postconditions for subprograms, and invariants for private types.
+     The concept of constraints in defining subtypes is supplemented
+     with subtype predicates that enable subsets to be specified other
+     than as simple ranges.  These properties are all indicated using
+     aspect specifications.  See subclauses *note 3.2.4::, *note
+     6.1.1::, and *note 7.3.2::.
+
+57.16/3
+   * New forms of expressions are introduced.  These are if expressions,
+     case expressions, quantified expressions, and expression functions.
+     As well as being useful for programming in general by avoiding the
+     introduction of unnecessary assignments, they are especially
+     valuable in conditions and invariants since they avoid the need to
+     introduce auxiliary functions.  See subclauses *note 4.5.7::, *note
+     4.5.8::, and *note 6.8::.  Membership tests are also made more
+     flexible.  See subclauses *note 4.4:: and *note 4.5.2::.
+
+57.17/3
+   * A number of changes are made to subprogram parameters.  Functions
+     may now have parameters of all modes.  In order to mitigate
+     consequent (and indeed existing) problems of inadvertent order
+     dependence, rules are introduced to reduce aliasing.  A parameter
+     may now be explicitly marked as aliased and the type of a parameter
+     may be incomplete in certain circumstances.  See subclauses *note
+     3.10.1::, *note 6.1::, and *note 6.4.1::.
+
+57.18/3
+   * The use of access types is now more flexible.  The rules for
+     accessibility and certain conversions are improved.  See subclauses
+     *note 3.10.2::, *note 4.5.2::, *note 4.6::, and *note 8.6::.
+     Furthermore, better control of storage pools is provided.  See
+     subclause *note 13.11.4::.
+
+57.19/3
+   * The Real-Time Systems Annex now includes facilities for defining
+     domains of processors and assigning tasks to them.  Improvements
+     are made to scheduling and budgeting facilities.  See subclauses
+     *note D.10.1::, *note D.14::, and *note D.16::.
+
+57.20/3
+   * A number of important improvements are made to the standard
+     library.  These include packages for conversions between strings
+     and UTF encodings, and classification functions for wide and wide
+     wide characters.  Internationalization is catered for by a package
+     giving locale information.  See subclauses *note A.3::, *note
+     A.4.11::, and *note A.19::.  The container library is extended to
+     include bounded forms of the existing containers and new containers
+     for indefinite objects, multiway trees, and queues.  See subclause
+     *note A.18::.
+
+57.21/3
+   * Finally, certain features are added primarily to ease the use of
+     containers, such as the ability to iterate over all elements in a
+     container without having to encode the iteration.  These can also
+     be used for iteration over arrays, and within quantified
+     expressions.  See subclauses *note 4.1.5::, *note 4.1.6::, *note
+     5.5.1::, and *note 5.5.2::.
+
+Instructions for Comment Submission
+
+58/1
+Informal comments on this International Standard may be sent via e-mail
+to ada-comment@ada-auth.org.  If appropriate, the Project Editor will
+initiate the defect correction procedure.
+
+59
+Comments should use the following format:
+
+60/3
+        !topic Title summarizing comment
+        !reference Ada 2012 RMss.ss(pp)
+        !from Author Name yy-mm-dd
+        !keywords keywords related to topic
+        !discussion
+
+        text of discussion
+
+61/3
+where ss.ss is the clause or subclause number, pp is the paragraph
+number where applicable, and yy-mm-dd is the date the comment was sent.
+The date is optional, as is the !keywords line.
+
+62/1
+Please use a descriptive "Subject" in your e-mail message, and limit
+each message to a single comment.
+
+63
+When correcting typographical errors or making minor wording
+suggestions, please put the correction directly as the topic of the
+comment; use square brackets [ ] to indicate text to be omitted and
+curly braces { } to indicate text to be added, and provide enough
+context to make the nature of the suggestion self-evident or put
+additional information in the body of the comment, for example:
+
+64
+        !topic [c]{C}haracter
+        !topic it[']s meaning is not defined
+
+65
+Formal requests for interpretations and for reporting defects in this
+International Standard may be made in accordance with the ISO/IEC JTC 1
+Directives and the ISO/IEC JTC 1/SC 22 policy for interpretations.
+National Bodies may submit a Defect Report to ISO/IEC JTC 1/SC 22 for
+resolution under the JTC 1 procedures.  A response will be provided and,
+if appropriate, a Technical Corrigendum will be issued in accordance
+with the procedures.
+
+Acknowledgements for the Ada 83 edition
+
+65.1/3
+Ada is the result of a collective effort to design a common language for
+programming large scale and real-time systems.
+
+65.2/3
+The common high order language program began in 1974.  The requirements
+of the United States Department of Defense were formalized in a series
+of documents which were extensively reviewed by the Services, industrial
+organizations, universities, and foreign military departments.  The Ada
+language was designed in accordance with the final (1978) form of these
+requirements, embodied in the Steelman specification.
+
+65.3/3
+The Ada design team was led by Jean D. Ichbiah and has included Bernd
+Krieg-Brueckner, Brian A. Wichmann, Henry F. Ledgard, Jean-Claude
+Heliard, Jean-Loup Gailly, Jean-Raymond Abrial, John G.P. Barnes, Mike
+Woodger, Olivier Roubine, Paul N. Hilfinger, and Robert Firth.
+
+65.4/3
+At various stages of the project, several people closely associated with
+the design team made major contributions.  They include J.B. Goodenough,
+R.F. Brender, M.W. Davis, G. Ferran, K. Lester, L. MacLaren, E. Morel,
+I.R. Nassi, I.C. Pyle, S.A. Schuman, and S.C. Vestal.
+
+65.5/3
+Two parallel efforts that were started in the second phase of this
+design had a deep influence on the language.  One was the development of
+a formal definition using denotational semantics, with the participation
+of V. Donzeau-Gouge, G. Kahn, and B. Lang.  The other was the design of
+a test translator with the participation of K. Ripken, P. Boullier, P.
+Cadiou, J. Holden, J.F. Hueras, R.G. Lange, and D.T. Cornhill.  The
+entire effort benefitted from the dedicated assistance of Lyn Churchill
+and Marion Myers, and the effective technical support of B. Gravem, W.L.
+Heimerdinger, and P. Cleve.  H.G. Schmitz served as program manager.
+
+65.6/3
+Over the five years spent on this project, several intense week-long
+design reviews were conducted, with the participation of P. Belmont, B.
+Brosgol, P. Cohen, R. Dewar, A. Evans, G. Fisher, H. Harte, A.L. Hisgen,
+P. Knueven, M. Kronental, N. Lomuto, E. Ploedereder, G. Seegmueller, V.
+Stenning, D. Taffs, and also F. Belz, R. Converse, K. Correll, A.N.
+Habermann, J. Sammet, S. Squires, J. Teller, P. Wegner, and P.R.
+Wetherall.
+
+65.7/3
+Several persons had a constructive influence with their comments,
+criticisms and suggestions.  They include P. Brinch Hansen, G. Goos,
+C.A.R. Hoare, Mark Rain, W.A. Wulf, and also E. Boebert, P. Bonnard, H.
+Clausen, M. Cox, G. Dismukes, R. Eachus, T. Froggatt, H. Ganzinger, C.
+Hewitt, S. Kamin, R. Kotler, O. Lecarme, J.A.N. Lee, J.L. Mansion, F.
+Minel, T. Phinney, J. Roehrich, V. Schneider, A. Singer, D. Slosberg,
+I.C. Wand, the reviewers of Ada-Europe, AdaTech, Afcet, those of the
+LMSC review team, and those of the Ada Tokyo Study Group.
+
+65.8/3
+These reviews and comments, the numerous evaluation reports received at
+the end of the first and second phase, the nine hundred language issue
+reports and test and evaluation reports received from fifteen different
+countries during the third phase of the project, the thousands of
+comments received during the ANSI Canvass, and the on-going work of the
+IFIP Working Group 2.4 on system implementation languages and that of
+the Purdue Europe LTPL-E committee, all had a substantial influence on
+the final definition of Ada.
+
+65.9/3
+The Military Departments and Agencies have provided a broad base of
+support including funding, extensive reviews, and countless individual
+contributions by the members of the High Order Language Working Group
+and other interested personnel.  In particular, William A. Whitaker
+provided leadership for the program during the formative stages.  David
+A. Fisher was responsible for the successful development and refinement
+of the language requirement documents that led to the Steelman
+specification.
+
+65.10/3
+The Ada 83 language definition was developed by Cii Honeywell Bull and
+later Alsys, and by Honeywell Systems and Research Center, under
+contract to the United States Department of Defense.  William E. Carlson
+and later Larry E. Druffel served as the technical representatives of
+the United States Government and effectively coordinated the efforts of
+all participants in the Ada program.
+
+Acknowledgements for the Ada 95 edition
+
+66
+This International Standard was prepared by the Ada 9X Mapping/Revision
+Team based at Intermetrics, Inc., which has included: W. Carlson,
+Program Manager; T. Taft, Technical Director; J. Barnes (consultant); B.
+Brosgol (consultant); R. Duff (Oak Tree Software); M. Edwards; C.
+Garrity; R. Hilliard; O. Pazy (consultant); D. Rosenfeld; L. Shafer; W.
+White; M. Woodger.
+
+67
+The following consultants to the Ada 9X Project contributed to the
+Specialized Needs Annexes: T. Baker (Real-Time/Systems Programming --
+SEI, FSU); K. Dritz (Numerics -- Argonne National Laboratory); A.
+Gargaro (Distributed Systems -- Computer Sciences); J. Goodenough
+(Real-Time/Systems Programming -- SEI); J. McHugh (Secure Systems --
+consultant); B. Wichmann (Safety-Critical Systems -- NPL: UK).
+
+68
+This work was regularly reviewed by the Ada 9X Distinguished Reviewers
+and the members of the Ada 9X Rapporteur Group (XRG): E. Ploedereder,
+Chairman of DRs and XRG (University of Stuttgart: Germany); B. Bardin
+(Hughes); J. Barnes (consultant: UK); B. Brett (DEC); B. Brosgol
+(consultant); R. Brukardt (RR Software); N. Cohen (IBM); R. Dewar (NYU);
+G. Dismukes (TeleSoft); A. Evans (consultant); A. Gargaro (Computer
+Sciences); M. Gerhardt (ESL); J. Goodenough (SEI); S. Heilbrunner
+(University of Salzburg: Austria); P. Hilfinger (UC/Berkeley); B.
+K�llberg (CelsiusTech: Sweden); M. Kamrad II (Unisys); J. van Katwijk
+(Delft University of Technology: The Netherlands); V. Kaufman (Russia);
+P. Kruchten (Rational); R. Landwehr (CCI: Germany); C. Lester
+(Portsmouth Polytechnic: UK); L. M�nsson (TELIA Research: Sweden); S.
+Michell (Multiprocessor Toolsmiths: Canada); M. Mills (US Air Force); D.
+Pogge (US Navy); K. Power (Boeing); O. Roubine (Verdix: France); A.
+Strohmeier (Swiss Fed Inst of Technology: Switzerland); W. Taylor
+(consultant: UK); J. Tokar (Tartan); E. Vasilescu (Grumman); J. Vladik
+(Prospeks s.r.o.: Czech Republic); S. Van Vlierberghe (OFFIS: Belgium).
+
+69
+Other valuable feedback influencing the revision process was provided by
+the Ada 9X Language Precision Team (Odyssey Research Associates), the
+Ada 9X User/Implementer Teams (AETECH, Tartan, TeleSoft), the Ada 9X
+Implementation Analysis Team (New York University) and the Ada
+community-at-large.
+
+70
+Special thanks go to R. Mathis, Convenor of ISO/IEC JTC 1/SC 22 Working
+Group 9.
+
+71
+The Ada 9X Project was sponsored by the Ada Joint Program Office.
+Christine M. Anderson at the Air Force Phillips Laboratory (Kirtland
+AFB, NM) was the project manager.
+
+Acknowledgements for the Corrigendum version
+
+71.1/3
+The editor [R. Brukardt (USA)] would like to thank the many people whose
+hard work and assistance has made this update possible.
+
+71.2/1
+Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
+Rapporteur Group, whose work on creating and editing the wording
+corrections was critical to the entire process.  Especially valuable
+contributions came from the chairman of the ARG, E. Ploedereder
+(Germany), who kept the process moving; J. Barnes (UK) and K. Ishihata
+(Japan), whose extremely detailed reviews kept the editor on his toes;
+G. Dismukes (USA), M. Kamrad (USA), P. Leroy (France), S. Michell
+(Canada), T. Taft (USA), J. Tokar (USA), and other members too numerous
+to mention.
+
+71.3/1
+Special thanks go to R. Duff (USA) for his explanations of the previous
+system of formatting of these documents during the tedious conversion to
+more modern formats.  Special thanks also go to the convenor of ISO/IEC
+JTC 1/SC 22/WG 9, J. Moore (USA), without whose help and support the
+Corrigendum and this consolidated reference manual would not have been
+possible.
+
+Acknowledgements for the Amendment 1 version
+
+71.4/3
+The editor [R. Brukardt (USA)] would like to thank the many people whose
+hard work and assistance has made this update possible.
+
+71.5/2
+Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
+Rapporteur Group, whose work on creating and editing the wording
+corrections was critical to the entire process.  Especially valuable
+contributions came from the chairman of the ARG, P. Leroy (France), who
+kept the process on schedule; J. Barnes (UK) whose careful reviews found
+many typographical errors; T. Taft (USA), who always seemed to have a
+suggestion when we were stuck, and who also was usually able to provide
+the valuable service of explaining why things were as they are; S. Baird
+(USA), who found many obscure problems with the proposals; and A. Burns
+(UK), who pushed many of the real-time proposals to completion.  Other
+ARG members who contributed were: R. Dewar (USA), G. Dismukes (USA), R.
+Duff (USA), K. Ishihata (Japan), S. Michell (Canada), E. Ploedereder
+(Germany), J.P. Rosen (France), E. Schonberg (USA), J. Tokar (USA), and
+T. Vardanega (Italy).
+
+71.6/2
+Special thanks go to Ada-Europe and the Ada Resource Association,
+without whose help and support the Amendment and this consolidated
+reference manual would not have been possible.  M. Heaney (USA) requires
+special thanks for his tireless work on the containers packages.
+Finally, special thanks go to the convenor of ISO/IEC JTC 1/SC 22/WG 9,
+J. Moore (USA), who guided the document through the standardization
+process.
+
+Acknowledgements for the Ada 2012 edition
+
+71.7/3
+The editor [R. Brukardt (USA)] would like to thank the many people whose
+hard work and assistance has made this revision possible.
+
+71.8/3
+Thanks go out to all of the members of the ISO/IEC JTC 1/SC 22/WG 9 Ada
+Rapporteur Group, whose work on creating and editing the wording changes
+was critical to the entire process.  Especially valuable contributions
+came from the chairman of the ARG, E. Schonberg (USA), who guided the
+work; T. Taft (USA), whose insights broke many logjams, both in design
+and wording; J. Barnes (UK) whose careful reviews uncovered many
+editorial errors; S. Baird (USA), who repeatedly found obscure
+interactions with the proposals that the rest of us missed.  Other ARG
+members who substantially contributed were: A. Burns (UK), J. Cousins
+(UK), R. Dewar (USA), G. Dismukes (USA), R. Duff (USA), P. Leroy
+(France), B. Moore (Canada), E. Ploedereder (Germany), J.P. Rosen
+(France), B. Thomas (USA), and T. Vardanega (Italy).
+
+71.9/3
+Special thanks go to Ada-Europe and the Ada Resource Association,
+without whose help and support this third edition of the Ada Standard
+would not have been possible.  A special mention has to go to A.
+Beneschan (USA) for his efforts in eliminating sloppiness in our
+wording.  M. Heaney (USA) also deserves a mention for his efforts to
+improve the containers packages.  Finally, special thanks go to the
+convenor of ISO/IEC JTC 1/SC 22/WG 9, J. Tokar (USA), who guided the
+document through the standardization process.
+
+Changes
+
+72
+The International Standard is the same as this version of the Reference
+Manual, except:
+
+73
+   * This list of Changes is not included in the International Standard.
+
+74
+   * The "Acknowledgements" page is not included in the International
+     Standard.
+
+75
+   * The text in the running headers and footers on each page is
+     slightly different in the International Standard.
+
+76
+   * The title page(s) are different in the International Standard.
+
+77
+   * This document is formatted for 8.5-by-11-inch paper, whereas the
+     International Standard is formatted for A4 paper (210-by-297mm);
+     thus, the page breaks are in different places.
+
+77.1/3
+   * This paragraph was deleted.
+
+77.2/3
+   * {AI05-0299-1AI05-0299-1} The "Using this version of the Ada
+     Reference Manual" subclause is not included in the International
+     Standard.
+
+77.3/3
+   * Paragraph numbers are not included in the International Standard.
+
+Using this version of the Ada Reference Manual
+
+77.4/3
+This document has been revised with the corrections specified in
+Technical Corrigendum 1 (ISO/IEC 8652:1995/COR.1:2001) and Amendment 1
+(ISO/IEC 8652/AMD 1:2007), along with changes specifically for this
+third edition.  In addition, more annotations have been added and a
+variety of editorial errors have been corrected.
+
+77.5/3
+Changes to the original 8652:1995 can be identified by the version
+number following the paragraph number.  Paragraphs with a version number
+of /1 were changed by Technical Corrigendum 1 or were editorial
+corrections at that time, while paragraphs with a version number of /2
+were changed by Amendment 1 or were more recent editorial corrections,
+and paragraphs with a version number of /3 were changed by the third
+(2012) edition of the Standard or were still more recent editorial
+corrections.  Paragraphs not so marked are unchanged by the third
+edition, Amendment 1, Technical Corrigendum 1, or editorial corrections.
+Paragraph numbers of unchanged paragraphs are the same as in the 1995
+edition of the Ada Reference Manual.  Inserted text is indicated by
+underlining, and deleted text is indicated by strikethroughs.  Some
+versions also use color to indicate the version of the change.Where
+paragraphs are inserted, the paragraph numbers are of the form pp.nn,
+where pp is the number of the preceding paragraph, and nn is an
+insertion number.  For instance, the first paragraph inserted after
+paragraph 8 is numbered 8.1, the second paragraph inserted is numbered
+8.2, and so on.  Deleted paragraphs are indicated by the text This
+paragraph was deleted.  Deleted paragraphs include empty paragraphs that
+were numbered in the 1995 edition of the Ada Reference Manual.  Similar
+markings and numbering are used for changes to annotations.
+
+77.a/3
+          To be honest: The paragraph number is considered part of the
+          paragraph; when a paragraph is moved to a different paragraph
+          number, it is marked as changed even if the contents have not
+          changed.
+
+
+File: aarm2012.info,  Node: 0.99,  Prev: 0.2,  Up: Front Matter
+
+0.99
+====
+
+========== INTERNATIONAL STANDARD   ISO/IEC 8652:2012(E)
+
+==========  
+
+Information technology -- Programming
+Languages -- Ada
+
+ 
+
+
+File: aarm2012.info,  Node: 1,  Next: 2,  Prev: Front Matter,  Up: Top
+
+1 General
+*********
+
+2.a/3
+          Discussion: This Annotated Ada Reference Manual (AARM)
+          contains the entire text of the third edition of the Ada
+          Reference Manual (the Ada 2012 RM), plus certain annotations.
+          The annotations give a more in-depth analysis of the language.
+          They describe the reason for each nonobvious rule, and point
+          out interesting ramifications of the rules and interactions
+          among the rules (interesting to language lawyers, that is).
+          Differences between Ada 83, Ada 95, Ada 2005, and Ada 2012 are
+          listed.  (The text you are reading now is an annotation.)
+
+2.b/3
+          The AARM stresses detailed correctness and uniformity over
+          readability and understandability.  We're not trying to make
+          the language "appear" simple here; on the contrary, we're
+          trying to expose hidden complexities, so we can more easily
+          detect language bugs.  The Ada 2012 RM, on the other hand, is
+          intended to be a more readable document for programmers.
+
+2.c
+          The annotations in the AARM are as follows:
+
+2.d/3
+             * Text that is logically redundant is shown [in square
+               brackets, like this].  Technically, such text could be
+               written as a Note in the Ada 2012 RM (and the Ada 95 and
+               2005 RMs before it), since it is really a theorem that
+               can be proven from the nonredundant rules of the
+               language.  We use the square brackets instead when it
+               seems to make the Ada 2012 RM more readable.
+
+2.e
+             * The rules of the language (and some AARM-only text) are
+               categorized, and placed under certain sub-headings that
+               indicate the category.  For example, the distinction
+               between Name Resolution Rules and Legality Rules is
+               particularly important, as explained in *note 8.6::.
+
+2.f
+             * Text under the following sub-headings appears in both
+               documents:
+
+2.g
+                       * The unlabeled text at the beginning of each
+                         clause or subclause,
+
+2.h
+                       * Syntax,
+
+2.i
+                       * Name Resolution Rules,
+
+2.j
+                       * Legality Rules,
+
+2.k
+                       * Static Semantics,
+
+2.l
+                       * Post-Compilation Rules,
+
+2.m
+                       * Dynamic Semantics,
+
+2.n
+                       * Bounded (Run-Time) Errors,
+
+2.o
+                       * Erroneous Execution,
+
+2.p
+                       * Implementation Requirements,
+
+2.q
+                       * Documentation Requirements,
+
+2.r
+                       * Metrics,
+
+2.s
+                       * Implementation Permissions,
+
+2.t
+                       * Implementation Advice,
+
+2.u
+                       * NOTES,
+
+2.v
+                       * Examples.
+
+2.w/3
+             * Text under the following sub-headings does not appear in
+               the Ada 2012 RM:
+
+2.x
+                       * Language Design Principles,
+
+2.y
+                       * Inconsistencies With Ada 83,
+
+2.z
+                       * Incompatibilities With Ada 83,
+
+2.aa
+                       * Extensions to Ada 83,
+
+2.bb/2
+                       * Wording Changes from Ada 83,
+
+2.bb.1/2
+                       * Inconsistencies With Ada 95,
+
+2.bb.2/2
+                       * Incompatibilities With Ada 95,
+
+2.bb.3/2
+                       * Extensions to Ada 95,
+
+2.bb.4/3
+                       * Wording Changes from Ada 95,
+
+2.bb.5/3
+                       * Inconsistencies With Ada 2005,
+
+2.bb.6/3
+                       * Incompatibilities With Ada 2005,
+
+2.bb.7/3
+                       * Extensions to Ada 2005,
+
+2.bb.8/3
+                       * Wording Changes from Ada 2005.
+
+2.cc
+             * The AARM also includes the following kinds of
+               annotations.  These do not necessarily annotate the
+               immediately preceding rule, although they often do.
+
+2.dd
+          Reason: An explanation of why a certain rule is necessary, or
+          why it is worded in a certain way.
+
+2.ee
+          Ramification: An obscure ramification of the rules that is of
+          interest only to language lawyers.  (If a ramification of the
+          rules is of interest to programmers, then it appears under
+          NOTES.)
+
+2.ff
+          Proof: An informal proof explaining how a given Note or
+          [marked-as-redundant] piece of text follows from the other
+          rules of the language.
+
+2.gg
+          Implementation Note: A hint about how to implement a feature,
+          or a particular potential pitfall that an implementer needs to
+          be aware of.
+
+2.hh
+          Change: Change annotations are not used in this version.
+          Changes from previous versions have been removed.  Changes in
+          this version are marked with versioned paragraph numbers, as
+          explained in the "Corrigendum Changes" clause of the
+          "Introduction".
+
+2.ii
+          Discussion: Other annotations not covered by the above.
+
+2.jj
+          To be honest: A rule that is considered logically necessary to
+          the definition of the language, but which is so obscure or
+          pedantic that only a language lawyer would care.  These are
+          the only annotations that could be considered part of the
+          language definition.
+
+2.kk
+          Glossary entry: The text of a Glossary entry -- this text will
+          also appear in *note Annex N::, "*note Annex N:: Glossary".
+
+2.ll/3
+          Discussion: In general, the Ada 2012 RM text appears in the
+          normal font, whereas AARM-only text appears in a smaller font.
+          Notes also appear in the smaller font, as recommended by
+          ISO/IEC style guidelines.  Ada examples are also usually
+          printed in a smaller font.
+
+2.mm
+          If you have trouble finding things, be sure to use the index.
+          Each defined term appears there, and also in italics, like
+          this.  Syntactic categories defined in BNF are also indexed.
+
+2.nn
+          A definition marked "[distributed]" is the main definition for
+          a term whose complete definition is given in pieces
+          distributed throughout the document.  The pieces are marked
+          "[partial]" or with a phrase explaining what cases the partial
+          definition applies to.
+
+* Menu:
+
+* 1.1 ::      Scope
+* 1.2 ::      Normative References
+* 1.3 ::      Terms and Definitions
+
+
+File: aarm2012.info,  Node: 1.1,  Next: 1.2,  Up: 1
+
+1.1 Scope
+=========
+
+1/3
+{AI05-0299-1AI05-0299-1} This International Standard specifies the form
+and meaning of programs written in Ada.  Its purpose is to promote the
+portability of Ada programs to a variety of computing systems.
+
+2/3
+{AI05-0299-1AI05-0299-1} Ada is a programming language designed to
+support the construction of long-lived, highly reliable software
+systems.  The language includes facilities to define packages of related
+types, objects, and operations.  The packages may be parameterized and
+the types may be extended to support the construction of libraries of
+reusable, adaptable software components.  The operations may be
+implemented as subprograms using conventional sequential control
+structures, or as entries that include synchronization of concurrent
+threads of control as part of their invocation.  Ada supports
+object-oriented programming by providing classes and interfaces,
+inheritance, polymorphism of variables and methods, and generic units.
+The language treats modularity in the physical sense as well, with a
+facility to support separate compilation.
+
+3/3
+{AI05-0269-1AI05-0269-1} {AI05-0299-1AI05-0299-1} The language provides
+rich support for real-time, concurrent programming, and includes
+facilities for multicore and multiprocessor programming.  Errors can be
+signaled as exceptions and handled explicitly.  The language also covers
+systems programming; this requires precise control over the
+representation of data and access to system-dependent properties.
+Finally, a predefined environment of standard packages is provided,
+including facilities for, among others, input-output, string
+manipulation, numeric elementary functions, and random number
+generation, and definition and use of containers.
+
+* Menu:
+
+* 1.1.1 ::    Extent
+* 1.1.2 ::    Structure
+* 1.1.3 ::    Conformity of an Implementation with the Standard
+* 1.1.4 ::    Method of Description and Syntax Notation
+* 1.1.5 ::    Classification of Errors
+
+
+File: aarm2012.info,  Node: 1.1.1,  Next: 1.1.2,  Up: 1.1
+
+1.1.1 Extent
+------------
+
+1
+This International Standard specifies:
+
+2
+   * The form of a program written in Ada;
+
+3
+   * The effect of translating and executing such a program;
+
+4
+   * The manner in which program units may be combined to form Ada
+     programs;
+
+5
+   * The language-defined library units that a conforming implementation
+     is required to supply;
+
+6
+   * The permissible variations within the standard, and the manner in
+     which they are to be documented;
+
+7
+   * Those violations of the standard that a conforming implementation
+     is required to detect, and the effect of attempting to translate or
+     execute a program containing such violations;
+
+8
+   * Those violations of the standard that a conforming implementation
+     is not required to detect.
+
+9
+This International Standard does not specify:
+
+10
+   * The means whereby a program written in Ada is transformed into
+     object code executable by a processor;
+
+11
+   * The means whereby translation or execution of programs is invoked
+     and the executing units are controlled;
+
+12
+   * The size or speed of the object code, or the relative execution
+     speed of different language constructs;
+
+13
+   * The form or contents of any listings produced by implementations;
+     in particular, the form or contents of error or warning messages;
+
+14
+   * The effect of unspecified execution.
+
+15
+   * The size of a program or program unit that will exceed the capacity
+     of a particular conforming implementation.
+
+
+File: aarm2012.info,  Node: 1.1.2,  Next: 1.1.3,  Prev: 1.1.1,  Up: 1.1
+
+1.1.2 Structure
+---------------
+
+1/3
+{AI05-0299-1AI05-0299-1} This International Standard contains thirteen
+clauses, fifteen annexes, and an index.
+
+1.a/3
+          Discussion: {AI05-0299-1AI05-0299-1} What Ada 83 called a
+          "chapter" and Ada 95 (and Ada 2005) called a "section" is
+          called a "clause" in this Standard.  Similarly, what Ada 83
+          called a "section" and Ada 95 (and Ada 2005) called a "clause"
+          is called a "subclause" in this Standard.  Confused yet?  This
+          terminology is out of our hands; it is (and was) forced by
+          ever-changing ISO rules for drafting Standards.
+
+2
+The core of the Ada language consists of:
+
+3/3
+   * {AI05-0299-1AI05-0299-1} Clauses 1 through 13
+
+4
+   * *note Annex A::, "*note Annex A:: Predefined Language Environment"
+
+5
+   * *note Annex B::, "*note Annex B:: Interface to Other Languages"
+
+6
+   * *note Annex J::, "*note Annex J:: Obsolescent Features"
+
+7
+The following Specialized Needs Annexes define features that are needed
+by certain application areas:
+
+8
+   * *note Annex C::, "*note Annex C:: Systems Programming"
+
+9
+   * *note Annex D::, "*note Annex D:: Real-Time Systems"
+
+10
+   * *note Annex E::, "*note Annex E:: Distributed Systems"
+
+11
+   * *note Annex F::, "*note Annex F:: Information Systems"
+
+12
+   * *note Annex G::, "*note Annex G:: Numerics"
+
+13
+   * *note Annex H::, "*note Annex H:: High Integrity Systems"
+
+14
+The core language and the Specialized Needs Annexes are normative,
+except that the material in each of the items listed below is
+informative:
+
+15
+   * Text under a NOTES or Examples heading.
+
+16/3
+   * {AI05-0299-1AI05-0299-1} Each subclause whose title starts with the
+     word "Example" or "Examples".
+
+17
+All implementations shall conform to the core language.  In addition, an
+implementation may conform separately to one or more Specialized Needs
+Annexes.
+
+18
+The following Annexes are informative:
+
+19
+   * *note Annex K::, "*note Annex K:: Language-Defined Aspects and
+     Attributes"
+
+20
+   * *note Annex L::, "*note Annex L:: Language-Defined Pragmas"
+
+21/3
+   * {AI05-0004-1AI05-0004-1} *note Annex M::, "*note Annex M:: Summary
+     of Documentation Requirements"
+
+22
+   * *note Annex N::, "*note Annex N:: Glossary"
+
+23
+   * *note Annex P::, "*note Annex P:: Syntax Summary"
+
+23.1/3
+   * {AI05-0262-1AI05-0262-1} *note Annex Q::, "*note Annex Q::
+     Language-Defined Entities"
+
+23.a
+          Discussion: The idea of the Specialized Needs Annexes is that
+          implementations can choose to target certain application
+          areas.  For example, an implementation specifically targeted
+          to embedded machines might support the application-specific
+          features for Real-time Systems, but not the
+          application-specific features for Information Systems.
+
+23.b
+          The Specialized Needs Annexes extend the core language only in
+          ways that users, implementations, and standards bodies are
+          allowed to extend the language; for example, via additional
+          library units, attributes, representation items (see *note
+          13.1::), pragmas, and constraints on semantic details that are
+          left unspecified by the core language.  Many implementations
+          already provide much of the functionality defined by
+          Specialized Needs Annexes; our goal is to increase uniformity
+          among implementations by defining standard ways of providing
+          the functionality.
+
+23.c/2
+          {AI95-00114-01AI95-00114-01} We recommend that the
+          certification procedures allow implementations to certify the
+          core language, plus any set of the Specialized Needs Annexes.
+          We recommend that implementations not be allowed to certify a
+          portion of one of the Specialized Needs Annexes, although
+          implementations can, of course, provide uncertified support
+          for such portions.  We have designed the Specialized Needs
+          Annexes assuming that this recommendation is followed.  Thus,
+          our decisions about what to include and what not to include in
+          those annexes are based on the assumption that each annex is
+          certified in an "all-or-nothing" manner.
+
+23.d
+          An implementation may, of course, support extensions that are
+          different from (but possibly related to) those defined by one
+          of the Specialized Needs Annexes.  We recommend that, where
+          appropriate, implementations do this by adding library units
+          that are children of existing language-defined library
+          packages.
+
+23.e
+          An implementation should not provide extensions that conflict
+          with those defined in the Specialized Needs Annexes, in the
+          following sense: Suppose an implementation supports a certain
+          error-free program that uses only functionality defined in the
+          core and in the Specialized Needs Annexes.  The implementation
+          should ensure that that program will still be error free in
+          some possible full implementation of all of the Specialized
+          Needs Annexes, and that the semantics of the program will not
+          change.  For example, an implementation should not provide a
+          package with the same name as one defined in one of the
+          Specialized Needs Annexes, but that behaves differently, even
+          if that implementation does not claim conformance to that
+          Annex.
+
+23.f
+          Note that the Specialized Needs Annexes do not conflict with
+          each other; it is the intent that a single implementation can
+          conform to all of them.
+
+24/3
+{AI05-0299-1AI05-0299-1} Each section is divided into subclauses that
+have a common structure.  Each clause and subclause first introduces its
+subject.  After the introductory text, text is labeled with the
+following headings:
+
+                     _Language Design Principles_
+
+24.a
+          These are not rules of the language, but guiding principles or
+          goals used in defining the rules of the language.  In some
+          cases, the goal is only partially met; such cases are
+          explained.
+
+24.b/3
+          {AI05-0005-1AI05-0005-1} This is not part of the definition of
+          the language, and does not appear in the Ada 2012 RM.
+
+                               _Syntax_
+
+25
+     Syntax rules (indented).
+
+                        _Name Resolution Rules_
+
+26/3
+{AI05-0299-1AI05-0299-1} Compile-time rules that are used in name
+resolution, including overload resolution.
+
+26.a
+          Discussion: These rules are observed at compile time.  (We say
+          "observed" rather than "checked," because these rules are not
+          individually checked.  They are really just part of the
+          Legality Rules in Clause *note 8:: that require exactly one
+          interpretation of each constituent of a complete context.)
+          The only rules used in overload resolution are the Syntax
+          Rules and the Name Resolution Rules.
+
+26.b
+          When dealing with nonoverloadable declarations it sometimes
+          makes no semantic difference whether a given rule is a Name
+          Resolution Rule or a Legality Rule, and it is sometimes
+          difficult to decide which it should be.  We generally make a
+          given rule a Name Resolution Rule only if it has to be.  For
+          example, "The name, if any, in a raise_statement shall be the
+          name of an exception."  is under "Legality Rules."
+
+                           _Legality Rules_
+
+27
+Rules that are enforced at compile time.  A construct is legal if it
+obeys all of the Legality Rules.
+
+27.a
+          Discussion: These rules are not used in overload resolution.
+
+27.b
+          Note that run-time errors are always attached to exceptions;
+          for example, it is not "illegal" to divide by zero, it just
+          raises an exception.
+
+                          _Static Semantics_
+
+28
+A definition of the compile-time effect of each construct.
+
+28.a
+          Discussion: The most important compile-time effects represent
+          the effects on the symbol table associated with declarations
+          (implicit or explicit).  In addition, we use this heading as a
+          bit of a grab bag for equivalences, package specifications,
+          etc.  For example, this is where we put statements like
+          so-and-so is equivalent to such-and-such.  (We ought to try to
+          really mean it when we say such things!)  Similarly,
+          statements about magically-generated implicit declarations go
+          here.  These rules are generally written as statements of fact
+          about the semantics, rather than as a
+          you-shall-do-such-and-such sort of thing.
+
+                       _Post-Compilation Rules_
+
+29
+Rules that are enforced before running a partition.  A partition is
+legal if its compilation units are legal and it obeys all of the
+Post-Compilation Rules.
+
+29.a
+          Discussion: It is not specified exactly when these rules are
+          checked, so long as they are checked for any given partition
+          before that partition starts running.  An implementation may
+          choose to check some such rules at compile time, and reject
+          compilation_units accordingly.  Alternatively, an
+          implementation may check such rules when the partition is
+          created (usually known as "link time"), or when the partition
+          is mapped to a particular piece of hardware (but before the
+          partition starts running).
+
+                          _Dynamic Semantics_
+
+30
+A definition of the run-time effect of each construct.
+
+30.a
+          Discussion: This heading describes what happens at run time.
+          Run-time checks, which raise exceptions upon failure, are
+          described here.  Each item that involves a run-time check is
+          marked with the name of the check -- these are the same check
+          names that are used in a pragma Suppress.  Principle: Every
+          check should have a name, usable in a pragma Suppress.
+
+                      _Bounded (Run-Time) Errors_
+
+31
+Situations that result in bounded (run-time) errors (see *note 1.1.5::).
+
+31.a
+          Discussion: The "bounds" of each such error are described here
+          -- that is, we characterize the set of all possible behaviors
+          that can result from a bounded error occurring at run time.
+
+                         _Erroneous Execution_
+
+32
+Situations that result in erroneous execution (see *note 1.1.5::).
+
+                     _Implementation Requirements_
+
+33
+Additional requirements for conforming implementations.
+
+33.a
+          Discussion: ...as opposed to rules imposed on the programmer.
+          An example might be, "The smallest representable duration,
+          Duration'Small, shall not be greater than twenty
+          milliseconds."
+
+33.b
+          It's really just an issue of how the rule is worded.  We could
+          write the same rule as "The smallest representable duration is
+          an implementation-defined value less than or equal to 20
+          milliseconds" and then it would be under "Static Semantics."
+
+                     _Documentation Requirements_
+
+34
+Documentation requirements for conforming implementations.
+
+34.a
+          Discussion: These requirements are beyond those that are
+          implicitly specified by the phrase "implementation defined".
+          The latter require documentation as well, but we don't repeat
+          these cases under this heading.  Usually this heading is used
+          for when the description of the documentation requirement is
+          longer and does not correspond directly to one, narrow
+          normative sentence.
+
+                               _Metrics_
+
+35
+Metrics that are specified for the time/space properties of the
+execution of certain language constructs.
+
+                     _Implementation Permissions_
+
+36
+Additional permissions given to the implementer.
+
+36.a
+          Discussion: For example, "The implementation is allowed to
+          impose further restrictions on the record aggregates allowed
+          in code statements."  When there are restrictions on the
+          permission, those restrictions are given here also.  For
+          example, "An implementation is allowed to restrict the kinds
+          of subprograms that are allowed to be main subprograms.
+          However, it shall support at least parameterless procedures."
+          -- we don't split this up between here and "Implementation
+          Requirements."
+
+                        _Implementation Advice_
+
+37
+Optional advice given to the implementer.  The word "should" is used to
+indicate that the advice is a recommendation, not a requirement.  It is
+implementation defined whether or not a given recommendation is obeyed.
+
+37.a/2
+          Implementation defined: Whether or not each recommendation
+          given in Implementation Advice is followed -- see *note M.3::,
+          "*note M.3:: Implementation Advice" for a listing.
+
+37.b/1
+          Discussion: The advice generally shows the intended
+          implementation, but the implementer is free to ignore it.  The
+          implementer is the sole arbiter of whether or not the advice
+          has been obeyed, if not, whether the reason is a good one, and
+          whether the required documentation is sufficient.  It would be
+          wrong for the ACATS to enforce any of this advice.
+
+37.c
+          For example, "Whenever possible, the implementation should
+          choose a value no greater than fifty microseconds for the
+          smallest representable duration, Duration'Small."
+
+37.d
+          We use this heading, for example, when the rule is so low
+          level or implementation-oriented as to be untestable.  We also
+          use this heading when we wish to encourage implementations to
+          behave in a certain way in most cases, but we do not wish to
+          burden implementations by requiring the behavior.
+
+     NOTES
+
+38
+     1  Notes emphasize consequences of the rules described in the
+     (sub)clause or elsewhere.  This material is informative.
+
+                              _Examples_
+
+39
+Examples illustrate the possible forms of the constructs described.
+This material is informative.
+
+39.a
+          Discussion:  
+
+          The next three headings list all language changes between Ada
+          83 and Ada 95.  Language changes are any change that changes
+          the set of text strings that are legal Ada programs, or
+          changes the meaning of any legal program.  Wording changes,
+          such as changes in terminology, are not language changes.
+          Each language change falls into one of the following three
+          categories:
+
+                     _Inconsistencies With Ada 83_
+
+39.b
+          This heading lists all of the upward inconsistencies between
+          Ada 83 and Ada 95.  Upward inconsistencies are situations in
+          which a legal Ada 83 program is a legal Ada 95 program with
+          different semantics.  This type of upward incompatibility is
+          the worst type for users, so we only tolerate it in rare
+          situations.
+
+39.c
+          (Note that the semantics of a program is not the same thing as
+          the behavior of the program.  Because of Ada's indeterminacy,
+          the "semantics" of a given feature describes a set of
+          behaviors that can be exhibited by that feature.  The set can
+          contain more than one allowed behavior.  Thus, when we ask
+          whether the semantics changes, we are asking whether the set
+          of behaviors changes.)
+
+39.d/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 95, Ada 2005, or Ada 2012 RM.
+
+                    _Incompatibilities With Ada 83_
+
+39.e
+          This heading lists all of the upward incompatibilities between
+          Ada 83 and Ada 95, except for the ones listed under
+          "Inconsistencies With Ada 83" above.  These are the situations
+          in which a legal Ada 83 program is illegal in Ada 95.  We do
+          not generally consider a change that turns erroneous execution
+          into an exception, or into an illegality, to be upwardly
+          incompatible.
+
+39.f/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 95, Ada 2005, or Ada 2012 RM.
+
+                        _Extensions to Ada 83_
+
+39.g
+          This heading is used to list all upward compatible language
+          changes; that is, language extensions.  These are the
+          situations in which a legal Ada 95 program is not a legal Ada
+          83 program.  The vast majority of language changes fall into
+          this category.
+
+39.h/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 95, Ada 2005, or Ada 2012 RM.
+
+39.i
+           
+
+          As explained above, the next heading does not represent any
+          language change:
+
+                     _Wording Changes from Ada 83_
+
+39.j/2
+          This heading lists some of the nonsemantic changes between the
+          Ada 83 RM and the Ada 95 RM. It is incomplete; we have not
+          attempted to list all wording changes, but only the
+          "interesting" ones.
+
+39.k/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 95, Ada 2005, or Ada 2012 RM.
+
+39.l/2
+          Discussion:  
+
+          The next three headings list all language changes between Ada
+          95 and Ada 2005 (the language defined by the Ada 95 standard
+          plus Technical Corrigendum 1 plus Amendment 1).  Each language
+          change falls into one of the following three categories:
+
+                     _Inconsistencies With Ada 95_
+
+39.m/2
+          This heading lists all of the upward inconsistencies between
+          Ada 95 and Ada 2005.  Upward inconsistencies are situations in
+          which a legal Ada 95 program is a legal Ada 2005 program with
+          different semantics.
+
+39.n/3
+          {AI05-0005-1AI05-0005-1} Inconsistencies marked with
+          Corrigendum: are corrections to the original Ada 95 definition
+          introduced by Corrigendum 1.  Inconsistencies marked with
+          Amendment Correction: are corrections to the original Ada 95
+          definition added by Amendment 1.  Formally, these are
+          inconsistencies caused by Ada Issues classified as Binding
+          Interpretations; implementations of Ada 95 are supposed to
+          follow these corrections, not the original flawed language
+          definition.  Thus, these strictly speaking are not
+          inconsistencies between Ada 95 and Ada 2005.  Practically,
+          however, they very well may be, as early Ada 95
+          implementations might not follow the recommendation.
+          Inconsistencies so marked are not portable between Ada 95
+          implementations, while usually Ada 2005 will have more clearly
+          defined behavior.  Therefore, we document these for
+          completeness.
+
+39.o/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2005 or Ada 2012 RM.
+
+                    _Incompatibilities With Ada 95_
+
+39.p/2
+          This heading lists all of the upward incompatibilities between
+          Ada 95 and Ada 2005, except for the ones listed under
+          "Inconsistencies With Ada 95" above.  These are the situations
+          in which a legal Ada 95 program is illegal in Ada 2005.
+
+39.q/3
+          {AI05-0005-1AI05-0005-1} As with inconsistencies,
+          incompatibilities marked with Corrigendum: are corrections to
+          the original Ada 95 definition introduced by Corrigendum 1.
+          Incompatibilities marked with Amendment Correction: are
+          corrections to the original Ada 95 definition added by
+          Amendment 1.  Formally, these are incompatibilities caused by
+          Ada Issues classified as Binding Interpretations;
+          implementations of Ada 95 are supposed to follow these
+          corrections, not the original flawed language definition.
+          Thus, these strictly speaking are not incompatibilities
+          between Ada 95 and Ada 2005.  Practically, however, they very
+          well may be, as early Ada 95 implementations might not follow
+          the recommendation.  Therefore, some Ada 95 implementations
+          may be able to compile the examples, while others might not.
+          In contrast, Ada 2005 compilers will have consistent behavior.
+          Therefore, we document these for completeness.
+
+39.r/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2005 or Ada 2012 RM.
+
+                        _Extensions to Ada 95_
+
+39.s/2
+          This heading is used to list all upward compatible language
+          changes; that is, language extensions.  These are the
+          situations in which a legal Ada 2005 program is not a legal
+          Ada 95 program.  The vast majority of language changes fall
+          into this category.
+
+39.t/3
+          {AI05-0005-1AI05-0005-1} As with incompatibilities, extensions
+          marked with Corrigendum: are corrections to the original Ada
+          95 definition introduced by Corrigendum 1.  Extensions marked
+          with Amendment Correction: are corrections to the original Ada
+          95 definition added by Amendment 1.  Formally, these are
+          extensions allowed by Ada Issues classified as Binding
+          Interpretations.  As corrections, implementations of Ada 95
+          are allowed to implement these extensions.  Thus, these
+          strictly speaking are not extensions of Ada 95; they're part
+          of Ada 95.  Practically, however, they very well may be
+          extensions, as early Ada 95 implementations might not
+          implement the extension.  Therefore, some Ada 95
+          implementations may be able to compile the examples, while
+          others might not.  In contrast, Ada 2005 compilers will always
+          support the extensions.  Therefore, we document these for
+          completeness.
+
+39.u/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2005 or Ada 2012 RM.
+
+39.v/2
+           
+
+          As explained above, the next heading does not represent any
+          language change:
+
+                     _Wording Changes from Ada 95_
+
+39.w/2
+          This heading lists some of the nonsemantic changes between the
+          Ada 95 RM and the Ada 2005 RM. This heading lists only
+          "interesting" changes (for instance, editorial corrections are
+          not listed).  Changes which come from Technical Corrigendum 1
+          are marked Corrigendum; unmarked changes come from Amendment
+          1.
+
+39.x/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2005 or Ada 2012 RM.
+
+39.y/3
+          Discussion:  
+
+          The next three headings list all language changes between Ada
+          2005 (the language defined by the Ada 95 standard plus
+          Technical Corrigendum 1 plus Amendment 1) and Ada 2012 (the
+          language defined by the third edition of the Standard).  Each
+          language change falls into one of the following three
+          categories:
+
+                    _Inconsistencies With Ada 2005_
+
+39.z/3
+          This heading lists all of the upward inconsistencies between
+          Ada 2005 and Ada 2012.  Upward inconsistencies are situations
+          in which a legal Ada 2005 program is a legal Ada 2012 program
+          with different semantics.
+
+39.aa/3
+          Inconsistencies marked with Correction: are corrections to the
+          original Ada 2005 definition added by the third edition of the
+          Standard.  Formally, these are inconsistencies caused by Ada
+          Issues classified as Binding Interpretations; implementations
+          of Ada 2005 are supposed to follow these corrections, not the
+          original flawed language definition.  Thus, these strictly
+          speaking are not inconsistencies between Ada 2005 and Ada
+          2012.  Practically, however, they very well may be, as early
+          Ada 2005 implementations might not follow the recommendation.
+          Inconsistencies so marked are not portable between Ada 2005
+          implementations, while usually Ada 2012 will have more clearly
+          defined behavior.  Therefore, we document these for
+          completeness.
+
+39.bb/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2012 RM.
+
+                   _Incompatibilities With Ada 2005_
+
+39.cc/3
+          This heading lists all of the upward incompatibilities between
+          Ada 2005 and Ada 2012, except for the ones listed under
+          "Inconsistencies With Ada 2005" above.  These are the
+          situations in which a legal Ada 2005 program is illegal in Ada
+          2012.
+
+39.dd/3
+          As with inconsistencies, incompatibilities marked with
+          Correction: are corrections to the original Ada 2005
+          definition added by the third edition.  Formally, these are
+          incompatibilities caused by Ada Issues classified as Binding
+          Interpretations; implementations of Ada 2005 are supposed to
+          follow these corrections, not the original flawed language
+          definition.  Thus, these strictly speaking are not
+          incompatibilities between Ada 2005 and Ada 2012.  Practically,
+          however, they very well may be, as early Ada 2005
+          implementations might not follow the recommendation.
+          Therefore, some Ada 2005 implementations may be able to
+          compile the examples, while others might not.  In contrast,
+          Ada 2012 compilers will have consistent behavior.  Therefore,
+          we document these for completeness.
+
+39.ee/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2012 RM.
+
+                       _Extensions to Ada 2005_
+
+39.ff/3
+          This heading is used to list all upward compatible language
+          changes; that is, language extensions.  These are the
+          situations in which a legal Ada 2012 program is not a legal
+          Ada 2005 program.  The vast majority of language changes fall
+          into this category.
+
+39.gg/3
+          As with incompatibilities, extensions marked with Correction:
+          are corrections to the original Ada 2005 definition added by
+          the third edition.  Formally, these are extensions allowed by
+          Ada Issues classified as Binding Interpretations.  As
+          corrections, implementations of Ada 2005 (and sometimes Ada
+          95) are allowed to implement these extensions.  Thus, these
+          strictly speaking are not extensions of Ada 2005; they're part
+          of Ada 2005.  Practically, however, they very well may be
+          extensions, as early Ada 2005 implementations might not
+          implement the extension.  Therefore, some Ada 2005
+          implementations may be able to compile the examples, while
+          others might not.  In contrast, Ada 2012 compilers will always
+          support the extensions.  Therefore, we document these for
+          completeness.
+
+39.hh/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2012 RM.
+
+39.ii/3
+           
+
+          As explained above, the next heading does not represent any
+          language change:
+
+                    _Wording Changes from Ada 2005_
+
+39.jj/3
+          This heading lists some of the nonsemantic changes between the
+          Ada 2005 RM and the Ada 2012 RM. This heading lists only
+          "interesting" changes (for instance, editorial corrections are
+          not listed).  Items marked Correction: come from Ada Issues
+          classified as Binding Interpretations and strictly speaking
+          belong to Ada 2005; other items only belong to Ada 2012.
+
+39.kk/3
+          This is not part of the definition of the language, and does
+          not appear in the Ada 2012 RM.
+
+
+File: aarm2012.info,  Node: 1.1.3,  Next: 1.1.4,  Prev: 1.1.2,  Up: 1.1
+
+1.1.3 Conformity of an Implementation with the Standard
+-------------------------------------------------------
+
+                     _Implementation Requirements_
+
+1
+A conforming implementation shall:
+
+1.a
+          Discussion: The implementation is the software and hardware
+          that implements the language.  This includes compiler, linker,
+          operating system, hardware, etc.
+
+1.b
+          We first define what it means to "conform" in general --
+          basically, the implementation has to properly implement the
+          normative rules given throughout the standard.  Then we define
+          what it means to conform to a Specialized Needs Annex -- the
+          implementation must support the core features plus the
+          features of that Annex.  Finally, we define what it means to
+          "conform to the Standard" -- this requires support for the
+          core language, and allows partial (but not conflicting)
+          support for the Specialized Needs Annexes.
+
+2
+   * Translate and correctly execute legal programs written in Ada,
+     provided that they are not so large as to exceed the capacity of
+     the implementation;
+
+3
+   * Identify all programs or program units that are so large as to
+     exceed the capacity of the implementation (or raise an appropriate
+     exception at run time);
+
+3.a
+          Implementation defined: Capacity limitations of the
+          implementation.
+
+4
+   * Identify all programs or program units that contain errors whose
+     detection is required by this International Standard;
+
+4.a
+          Discussion: Note that we no longer use the term "rejection" of
+          programs or program units.  We require that programs or
+          program units with errors or that exceed some capacity limit
+          be "identified".  The way in which errors or capacity problems
+          are reported is not specified.
+
+4.b
+          An implementation is allowed to use standard error-recovery
+          techniques.  We do not disallow such techniques from being
+          used across compilation_unit or compilation boundaries.
+
+4.c
+          See also the Implementation Requirements of *note 10.2::,
+          which disallow the execution of illegal partitions.
+
+5
+   * Supply all language-defined library units required by this
+     International Standard;
+
+5.a
+          Implementation Note: An implementation cannot add to or modify
+          the visible part of a language-defined library unit, except
+          where such permission is explicitly granted, unless such
+          modifications are semantically neutral with respect to the
+          client compilation units of the library unit.  An
+          implementation defines the contents of the private part and
+          body of language-defined library units.
+
+5.b
+          An implementation can add with_clauses and use_clauses, since
+          these modifications are semantically neutral to clients.  (The
+          implementation might need with_clauses in order to implement
+          the private part, for example.)  Similarly, an implementation
+          can add a private part even in cases where a private part is
+          not shown in the standard.  Explicit declarations can be
+          provided implicitly or by renaming, provided the changes are
+          semantically neutral.
+
+5.c
+          Wherever in the standard the text of a language-defined
+          library unit contains an italicized phrase starting with
+          "implementation-defined", the implementation's version will
+          replace that phrase with some implementation-defined text that
+          is syntactically legal at that place, and follows any other
+          applicable rules.
+
+5.d
+          Note that modifications are permitted, even if there are other
+          tools in the environment that can detect the changes (such as
+          a program library browser), so long as the modifications make
+          no difference with respect to the static or dynamic semantics
+          of the resulting programs, as defined by the standard.
+
+6
+   * Contain no variations except those explicitly permitted by this
+     International Standard, or those that are impossible or impractical
+     to avoid given the implementation's execution environment;
+
+6.a
+          Implementation defined: Variations from the standard that are
+          impractical to avoid given the implementation's execution
+          environment.
+
+6.b
+          Reason: The "impossible or impractical" wording comes from
+          AI-325.  It takes some judgement and common sense to interpret
+          this.  Restricting compilation units to less than 4 lines is
+          probably unreasonable, whereas restricting them to less than 4
+          billion lines is probably reasonable (at least given today's
+          technology).  We do not know exactly where to draw the line,
+          so we have to make the rule vague.
+
+7
+   * Specify all such variations in the manner prescribed by this
+     International Standard.
+
+8
+The external effect of the execution of an Ada program is defined in
+terms of its interactions with its external environment.  The following
+are defined as external interactions:
+
+9
+   * Any interaction with an external file (see *note A.7::);
+
+10
+   * The execution of certain code_statements (see *note 13.8::); which
+     code_statements cause external interactions is implementation
+     defined.
+
+10.a
+          Implementation defined: Which code_statements cause external
+          interactions.
+
+11
+   * Any call on an imported subprogram (see *note Annex B::), including
+     any parameters passed to it;
+
+12
+   * Any result returned or exception propagated from a main subprogram
+     (see *note 10.2::) or an exported subprogram (see *note Annex B::)
+     to an external caller;
+
+12.a
+          Discussion: By "result returned" we mean to include function
+          results and values returned in [in] out parameters.
+
+12.a.1/1
+          {8652/00948652/0094} {AI95-00119-01AI95-00119-01} The lack of
+          a result from a program that does not terminate is also
+          included here.
+
+13
+   * [Any read or update of an atomic or volatile object (see *note
+     C.6::);]
+
+14
+   * The values of imported and exported objects (see *note Annex B::)
+     at the time of any other interaction with the external environment.
+
+14.a/3
+          To be honest: {AI05-0229-1AI05-0229-1} Also other uses of
+          imported and exported entities, as defined by the
+          implementation, if the implementation supports such importing
+          or exporting.
+
+15
+A conforming implementation of this International Standard shall produce
+for the execution of a given Ada program a set of interactions with the
+external environment whose order and timing are consistent with the
+definitions and requirements of this International Standard for the
+semantics of the given program.
+
+15.a
+          Ramification: There is no need to produce any of the "internal
+          effects" defined for the semantics of the program -- all of
+          these can be optimized away -- so long as an appropriate
+          sequence of external interactions is produced.
+
+15.b
+          Discussion: See also *note 11.6:: which specifies various
+          liberties associated with optimizations in the presence of
+          language-defined checks, that could change the external
+          effects that might be produced.  These alternative external
+          effects are still consistent with the standard, since *note
+          11.6:: is part of the standard.
+
+15.c
+          Note also that we only require "an appropriate sequence of
+          external interactions" rather than "the same sequence..."  An
+          optimizer may cause a different sequence of external
+          interactions to be produced than would be produced without the
+          optimizer, so long as the new sequence still satisfies the
+          requirements of the standard.  For example, optimization might
+          affect the relative rate of progress of two concurrent tasks,
+          thereby altering the order in which two external interactions
+          occur.
+
+15.d/2
+          Note that the Ada 83 RM explicitly mentions the case of an
+          "exact effect" of a program, but since so few programs have
+          their effects defined that exactly, we don't even mention this
+          "special" case.  In particular, almost any program that uses
+          floating point or tasking has to have some level of
+          inexactness in the specification of its effects.  And if one
+          includes aspects of the timing of the external interactions in
+          the external effect of the program (as is appropriate for a
+          real-time language), no "exact effect" can be specified.  For
+          example, if two external interactions initiated by a single
+          task are separated by a "delay 1.0;" then the language rules
+          imply that the two external interactions have to be separated
+          in time by at least one second, as defined by the clock
+          associated with the delay_relative_statement.  This in turn
+          implies that the time at which an external interaction occurs
+          is part of the characterization of the external interaction,
+          at least in some cases, again making the specification of the
+          required "exact effect" impractical.
+
+16
+An implementation that conforms to this Standard shall support each
+capability required by the core language as specified.  In addition, an
+implementation that conforms to this Standard may conform to one or more
+Specialized Needs Annexes (or to none).  Conformance to a Specialized
+Needs Annex means that each capability required by the Annex is provided
+as specified.
+
+16.a
+          Discussion: The last sentence defines what it means to say
+          that an implementation conforms to a Specialized Needs Annex,
+          namely, only by supporting all capabilities required by the
+          Annex.
+
+17/3
+{AI05-0229-1AI05-0229-1} An implementation conforming to this
+International Standard may provide additional aspects, attributes,
+library units, and pragmas.  However, it shall not provide any aspect,
+attribute, library unit, or pragma having the same name as an aspect,
+attribute, library unit, or pragma (respectively) specified in a
+Specialized Needs Annex unless the provided construct is either as
+specified in the Specialized Needs Annex or is more limited in
+capability than that required by the Annex.  A program that attempts to
+use an unsupported capability of an Annex shall either be identified by
+the implementation before run time or shall raise an exception at run
+time.
+
+17.a
+          Discussion: The last sentence of the preceding paragraph
+          defines what an implementation is allowed to do when it does
+          not "conform" to a Specialized Needs Annex.  In particular,
+          the sentence forbids implementations from providing a
+          construct with the same name as a corresponding construct in a
+          Specialized Needs Annex but with a different syntax (e.g., an
+          extended syntax) or quite different semantics.  The phrase
+          concerning "more limited in capability" is intended to give
+          permission to provide a partial implementation, such as not
+          implementing a subprogram in a package or having a restriction
+          not permitted by an implementation that conforms to the Annex.
+          For example, a partial implementation of the package
+          Ada.Decimal might have Decimal.Max_Decimal_Digits as 15
+          (rather than the required 18).  This allows a partial
+          implementation to grow to a fully conforming implementation.
+
+17.b
+          A restricted implementation might be restricted by not
+          providing some subprograms specified in one of the packages
+          defined by an Annex.  In this case, a program that tries to
+          use the missing subprogram will usually fail to compile.
+          Alternatively, the implementation might declare the subprogram
+          as abstract, so it cannot be called.  Alternatively, a
+          subprogram body might be implemented just to raise
+          Program_Error.  The advantage of this approach is that a
+          program to be run under a fully conforming Annex
+          implementation can be checked syntactically and semantically
+          under an implementation that only partially supports the
+          Annex.  Finally, an implementation might provide a package
+          declaration without the corresponding body, so that programs
+          can be compiled, but partitions cannot be built and executed.
+
+17.c
+          To ensure against wrong answers being delivered by a partial
+          implementation, implementers are required to raise an
+          exception when a program attempts to use an unsupported
+          capability and this can be detected only at run time.  For
+          example, a partial implementation of Ada.Decimal might require
+          the length of the Currency string to be 1, and hence, an
+          exception would be raised if a subprogram were called in the
+          package Edited_Output with a length greater than 1.
+
+                     _Documentation Requirements_
+
+18
+Certain aspects of the semantics are defined to be either implementation
+defined or unspecified.  In such cases, the set of possible effects is
+specified, and the implementation may choose any effect in the set.
+Implementations shall document their behavior in implementation-defined
+situations, but documentation is not required for unspecified
+situations.  The implementation-defined characteristics are summarized
+in *note M.2::.
+
+18.a
+          Discussion: We used to use the term "implementation dependent"
+          instead of "unspecified".  However, that sounded too much like
+          "implementation defined".  Furthermore, the term "unspecified"
+          is used in the ANSI C and POSIX standards for this purpose, so
+          that is another advantage.  We also use "not specified" and
+          "not specified by the language" as synonyms for "unspecified."
+          The documentation requirement is the only difference between
+          implementation defined and unspecified.
+
+18.b
+          Note that the "set of possible effects" can be "all imaginable
+          effects", as is the case with erroneous execution.
+
+19
+The implementation may choose to document implementation-defined
+behavior either by documenting what happens in general, or by providing
+some mechanism for the user to determine what happens in a particular
+case.
+
+19.a
+          Discussion: For example, if the standard says that library
+          unit elaboration order is implementation defined, the
+          implementation might describe (in its user's manual) the
+          algorithm it uses to determine the elaboration order.  On the
+          other hand, the implementation might provide a command that
+          produces a description of the elaboration order for a
+          partition upon request from the user.  It is also acceptable
+          to provide cross references to existing documentation (for
+          example, a hardware manual), where appropriate.
+
+19.b
+          Note that dependence of a program on implementation-defined or
+          unspecified functionality is not defined to be an error; it
+          might cause the program to be less portable, however.
+
+19.c/2
+          Documentation Requirement: The behavior of implementations in
+          implementation-defined situations shall be documented -- see
+          *note M.2::, "*note M.2:: Implementation-Defined
+          Characteristics" for a listing.
+
+                        _Implementation Advice_
+
+20
+If an implementation detects the use of an unsupported Specialized Needs
+Annex feature at run time, it should raise Program_Error if feasible.
+
+20.a.1/2
+          Implementation Advice: Program_Error should be raised when an
+          unsupported Specialized Needs Annex feature is used at run
+          time.
+
+20.a
+          Reason: The reason we don't require Program_Error is that
+          there are situations where other exceptions might make sense.
+          For example, if the Real Time Systems Annex requires that the
+          range of System.Priority include at least 30 values, an
+          implementation could conform to the Standard (but not to the
+          Annex) if it supported only 12 values.  Since the rules of the
+          language require Constraint_Error to be raised for
+          out-of-range values, we cannot require Program_Error to be
+          raised instead.
+
+21
+If an implementation wishes to provide implementation-defined extensions
+to the functionality of a language-defined library unit, it should
+normally do so by adding children to the library unit.
+
+21.a.1/2
+          Implementation Advice: Implementation-defined extensions to
+          the functionality of a language-defined library unit should be
+          provided by adding children to the library unit.
+
+21.a
+          Implementation Note: If an implementation has support code
+          ("run-time system code") that is needed for the execution of
+          user-defined code, it can put that support code in child
+          packages of System.  Otherwise, it has to use some trick to
+          avoid polluting the user's namespace.  It is important that
+          such tricks not be available to user-defined code (not in the
+          standard mode, at least) -- that would defeat the purpose.
+
+     NOTES
+
+22
+     2  The above requirements imply that an implementation conforming
+     to this Standard may support some of the capabilities required by a
+     Specialized Needs Annex without supporting all required
+     capabilities.
+
+22.a
+          Discussion: A conforming implementation can partially support
+          a Specialized Needs Annex.  Such an implementation does not
+          conform to the Annex, but it does conform to the Standard.
+
+
+File: aarm2012.info,  Node: 1.1.4,  Next: 1.1.5,  Prev: 1.1.3,  Up: 1.1
+
+1.1.4 Method of Description and Syntax Notation
+-----------------------------------------------
+
+1
+The form of an Ada program is described by means of a context-free
+syntax together with context-dependent requirements expressed by
+narrative rules.
+
+2
+The meaning of Ada programs is described by means of narrative rules
+defining both the effects of each construct and the composition rules
+for constructs.
+
+3
+The context-free syntax of the language is described using a simple
+variant of Backus-Naur Form.  In particular:
+
+4
+   * Lower case words in a sans-serif font, some containing embedded
+     underlines, are used to denote syntactic categories, for example:
+
+5
+          case_statement
+
+6
+   * Boldface words are used to denote reserved words, for example:
+
+7
+          array
+
+8
+   * Square brackets enclose optional items.  Thus the two following
+     rules are equivalent.
+
+9/2
+          {AI95-00433-01AI95-00433-01}
+          simple_return_statement ::= return [expression];
+          simple_return_statement ::= return; | return expression;
+
+10
+   * Curly brackets 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.
+
+11
+          term ::= factor {multiplying_operator factor}
+          term ::= factor | term multiplying_operator factor
+
+12
+   * A vertical line separates alternative items unless it occurs
+     immediately after an opening curly bracket, in which case it stands
+     for itself:
+
+13
+          constraint ::= scalar_constraint | composite_constraint
+          discrete_choice_list ::= discrete_choice {| discrete_choice}
+
+14
+   * 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 subtype_name and task_name are both
+     equivalent to name alone.
+
+14.a
+          Discussion: The grammar given in this International Standard
+          is not LR(1).  In fact, it is ambiguous; the ambiguities are
+          resolved by the overload resolution rules (see *note 8.6::).
+
+14.b
+          We often use "if" to mean "if and only if" in definitions.
+          For example, if we define "photogenic" by saying, "A type is
+          photogenic if it has the following properties...," we mean
+          that a type is photogenic if and only if it has those
+          properties.  It is usually clear from the context, and adding
+          the "and only if" seems too cumbersome.
+
+14.c
+          When we say, for example, "a declarative_item of a
+          declarative_part", we are talking about a declarative_item
+          immediately within that declarative_part.  When we say "a
+          declarative_item in, or within, a declarative_part", we are
+          talking about a declarative_item anywhere in the
+          declarative_part, possibly deeply nested within other
+          declarative_parts.  (This notation doesn't work very well for
+          names, since the name "of" something also has another
+          meaning.)
+
+14.d
+          When we refer to the name of a language-defined entity (for
+          example, Duration), we mean the language-defined entity even
+          in programs where the declaration of the language-defined
+          entity is hidden by another declaration.  For example, when we
+          say that the expected type for the expression of a
+          delay_relative_statement is Duration, we mean the
+          language-defined type Duration that is declared in Standard,
+          not some type Duration the user might have declared.
+
+14.1/3
+{AI95-00285-01AI95-00285-01} {AI05-0004-1AI05-0004-1}
+{AI05-0262-1AI05-0262-1} The delimiters, compound delimiters, reserved
+words, and numeric_literals are exclusively made of the characters whose
+code point is between 16#20# and 16#7E#, inclusively.  The special
+characters for which names are defined in this International Standard
+(see *note 2.1::) belong to the same range.  [For example, the character
+E in the definition of exponent is the character whose name is "LATIN
+CAPITAL LETTER E", not "GREEK CAPITAL LETTER EPSILON".]
+
+14.e/2
+          Discussion: This just means that programs can be written in
+          plain ASCII characters; no characters outside of the 7-bit
+          range are required.
+
+14.2/3
+{AI95-00395-01AI95-00395-01} {AI05-0227-1AI05-0227-1}
+{AI05-0299-1AI05-0299-1} When this International Standard mentions the
+conversion of some character or sequence of characters to upper case, it
+means the character or sequence of characters obtained by using simple
+upper case mapping, as defined by documents referenced in the note in
+Clause 1 of ISO/IEC 10646:2011.
+
+14.e.1/3
+          This paragraph was deleted.
+
+15
+A syntactic category is a nonterminal in the grammar defined in BNF
+under "Syntax."  Names of syntactic categories are set in a different
+font, like_this.
+
+16
+A construct is a piece of text (explicit or implicit) that is an
+instance of a syntactic category defined under "Syntax".
+
+16.a
+          Ramification: For example, an expression is a construct.  A
+          declaration is a construct, whereas the thing declared by a
+          declaration is an "entity."
+
+16.b
+          Discussion: "Explicit" and "implicit" don't mean exactly what
+          you might think they mean: The text of an instance of a
+          generic is considered explicit, even though it does not appear
+          explicitly (in the nontechnical sense) in the program text,
+          and even though its meaning is not defined entirely in terms
+          of that text.
+
+17
+A constituent of a construct is the construct itself, or any construct
+appearing within it.
+
+18
+Whenever the run-time semantics defines certain actions to happen in an
+arbitrary order, this means that the implementation shall arrange for
+these actions to occur in a way that is equivalent to some sequential
+order, following the rules that result from that sequential order.  When
+evaluations are defined to happen in an arbitrary order, with conversion
+of the results to some subtypes, or with some run-time checks, the
+evaluations, conversions, and checks may be arbitrarily interspersed, so
+long as each expression is evaluated before converting or checking its
+value.  [Note that the effect of a program can depend on the order
+chosen by the implementation.  This can happen, for example, if two
+actual parameters of a given call have side effects.]
+
+18.a
+          Discussion: Programs will be more portable if their external
+          effect does not depend on the particular order chosen by an
+          implementation.
+
+18.b
+          Ramification: Additional reordering permissions are given in
+          *note 11.6::, "*note 11.6:: Exceptions and Optimization".
+
+18.c
+          There is no requirement that the implementation always choose
+          the same order in a given kind of situation.  In fact, the
+          implementation is allowed to choose a different order for two
+          different executions of the same construct.  However, we
+          expect most implementations will behave in a relatively
+          predictable manner in most situations.
+
+18.d
+          Reason: The "sequential order" wording is intended to allow
+          the programmer to rely on "benign" side effects.  For example,
+          if F is a function that returns a unique integer by
+          incrementing some global and returning the result, a call such
+          as P(F, F) is OK if the programmer cares only that the two
+          results of F are unique; the two calls of F cannot be executed
+          in parallel, unless the compiler can prove that parallel
+          execution is equivalent to some sequential order.
+
+     NOTES
+
+19
+     3  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:
+
+20
+          if_statement ::=
+              if condition then
+                sequence_of_statements
+             {elsif condition then
+                sequence_of_statements}
+             [else
+                sequence_of_statements]
+              end if;
+
+21
+     4  The line breaks and indentation in the syntax rules indicate the
+     recommended line breaks and indentation in the corresponding
+     constructs.  The preferred places for other line breaks are after
+     semicolons.
+
+                     _Wording Changes from Ada 95_
+
+21.a/2
+          {AI95-00285-01AI95-00285-01} We now explicitly say that the
+          lexical elements of the language (with a few exceptions) are
+          made up of characters in the lower half of the Latin-1
+          character set.  This is needed to avoid confusion given the
+          new capability to use most ISO 10646 characters in identifiers
+          and strings.
+
+21.b/2
+          {AI95-00395-01AI95-00395-01} We now explicitly define what the
+          Standard means by upper case, as there are many possibilities
+          for ISO 10646 characters.
+
+21.c/2
+          {AI95-00433-01AI95-00433-01} The example for square brackets
+          has been changed as there is no longer a return_statement
+          syntax rule.
+
+                    _Wording Changes from Ada 2005_
+
+21.d/3
+          {AI05-0227-1AI05-0227-1} Correction: Upper case is defined by
+          "simple upper case mapping", because "full case folding" is a
+          mapping (mostly) to lower case.
+
+
+File: aarm2012.info,  Node: 1.1.5,  Prev: 1.1.4,  Up: 1.1
+
+1.1.5 Classification of Errors
+------------------------------
+
+                     _Implementation Requirements_
+
+1
+The language definition classifies errors into several different
+categories:
+
+2
+   * Errors that are required to be detected prior to run time by every
+     Ada implementation;
+
+3
+     These errors correspond to any violation of a rule given in this
+     International Standard, other than those listed below.  In
+     particular, violation of any rule that uses the terms shall,
+     allowed, permitted, legal, or illegal 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.
+
+4
+     The rules are further classified as either compile time rules, or
+     post compilation rules, depending on whether a violation has to be
+     detected at the time a compilation unit is submitted to the
+     compiler, or may be postponed until the time a compilation unit is
+     incorporated into a partition of a program.
+
+4.a
+          Ramification: See, for example, *note 10.1.3::, "*note
+          10.1.3:: Subunits of Compilation Units", for some errors that
+          are detected only after compilation.  Implementations are
+          allowed, but not required, to detect post compilation rules at
+          compile time when possible.
+
+5
+   * Errors that are required to be detected at run time by the
+     execution of an Ada program;
+
+6
+     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 such an error
+     situation is certain to arise in every execution of a construct,
+     then an implementation is allowed (although not required) to report
+     this fact at compilation time.]
+
+7
+   * Bounded errors;
+
+8
+     The language rules define certain kinds of errors that need not be
+     detected either prior to or during run time, but if not detected,
+     the range of possible effects shall be bounded.  The errors of this
+     category are called bounded errors.  The possible effects of a
+     given bounded error are specified for each such error, but in any
+     case one possible effect of a bounded error is the raising of the
+     exception Program_Error.
+
+9
+   * Erroneous execution.
+
+10
+     In addition to bounded errors, the language rules define certain
+     kinds of errors as leading to erroneous execution.  Like bounded
+     errors, the implementation need not detect such errors either prior
+     to or during run time.  Unlike bounded errors, there is no
+     language-specified bound on the possible effect of erroneous
+     execution; the effect is in general not predictable.
+
+10.a
+          Ramification: Executions are erroneous, not programs or parts
+          of programs.  Once something erroneous happens, the execution
+          of the entire program is erroneous from that point on, and
+          potentially before given possible reorderings permitted by
+          *note 11.6:: and elsewhere.  We cannot limit it to just one
+          partition, since partitions are not required to live in
+          separate address spaces.  (But implementations are encouraged
+          to limit it as much as possible.)
+
+10.b
+          Suppose a program contains a pair of things that will be
+          executed "in an arbitrary order."  It is possible that one
+          order will result in something sensible, whereas the other
+          order will result in erroneous execution.  If the
+          implementation happens to choose the first order, then the
+          execution is not erroneous.  This may seem odd, but it is not
+          harmful.
+
+10.c
+          Saying that something is erroneous is semantically equivalent
+          to saying that the behavior is unspecified.  However,
+          "erroneous" has a slightly more disapproving flavor.
+
+                     _Implementation Permissions_
+
+11
+[ An implementation may provide nonstandard modes of operation.
+Typically these modes would be selected by a pragma or by a command line
+switch when the compiler is invoked.  When operating in a nonstandard
+mode, the implementation may reject compilation_units that do not
+conform to additional requirements associated with the mode, such as an
+excessive number of warnings or violation of coding style guidelines.
+Similarly, in a nonstandard mode, the implementation may apply special
+optimizations or alternative algorithms that are only meaningful for
+programs that satisfy certain criteria specified by the implementation.  
+In any case, an implementation shall support a standard mode that
+conforms to the requirements of this International Standard; in
+particular, in the standard mode, all legal compilation_units shall be
+accepted.]
+
+11.a
+          Discussion: These permissions are designed to authorize
+          explicitly the support for alternative modes.  Of course,
+          nothing we say can prevent them anyway, but this (redundant)
+          paragraph is designed to indicate that such alternative modes
+          are in some sense "approved" and even encouraged where they
+          serve the specialized needs of a given user community, so long
+          as the standard mode, designed to foster maximum portability,
+          is always available.
+
+                        _Implementation Advice_
+
+12
+If an implementation detects a bounded error or erroneous execution, it
+should raise Program_Error.
+
+12.a.1/2
+          Implementation Advice: If a bounded error or erroneous
+          execution is detected, Program_Error should be raised.
+
+                     _Wording Changes from Ada 83_
+
+12.a
+          Some situations that are erroneous in Ada 83 are no longer
+          errors at all.  For example, depending on the parameter
+          passing mechanism when unspecified is possibly nonportable,
+          but not erroneous.
+
+12.b
+          Other situations that are erroneous in Ada 83 are changed to
+          be bounded errors.  In particular, evaluating an uninitialized
+          scalar variable is a bounded error.  The possible results are
+          to raise Program_Error (as always), or to produce a
+          machine-representable value (which might not be in the subtype
+          of the variable).  Violating a Range_Check or Overflow_Check
+          raises Constraint_Error, even if the value came from an
+          uninitialized variable.  This means that optimizers can no
+          longer "assume" that all variables are initialized within
+          their subtype's range.  Violating a check that is suppressed
+          remains erroneous.
+
+12.c
+          The "incorrect order dependences" category of errors is
+          removed.  All such situations are simply considered potential
+          nonportabilities.  This category was removed due to the
+          difficulty of defining what it means for two executions to
+          have a "different effect."  For example, if a function with a
+          side effect is called twice in a single expression, it is not
+          in principle possible for the compiler to decide whether the
+          correctness of the resulting program depends on the order of
+          execution of the two function calls.  A compile time warning
+          might be appropriate, but raising of Program_Error at run time
+          would not be.
+
+
+File: aarm2012.info,  Node: 1.2,  Next: 1.3,  Prev: 1.1,  Up: 1
+
+1.2 Normative References
+========================
+
+1/3
+{AI05-0299-1AI05-0299-1} The following documents, in whole or in part,
+are normatively referenced in this document and are indispensable for
+its application.  For dated references, only the edition cited applies.
+For undated references, the latest edition of the referenced document
+(including any amendments) applies.
+
+1.1/3
+{AI05-0127-2AI05-0127-2} {AI05-0299-1AI05-0299-1} ISO 639-3:2007, Codes
+for the representation of names of languages -- Part 3: Alpha-3 code for
+comprehensive coverage of languages.
+
+2
+ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character
+set for information interchange.
+
+3/2
+{AI95-00415-01AI95-00415-01} ISO/IEC 1539-1:2004, Information technology
+-- Programming languages -- Fortran -- Part 1: Base language.
+
+4/2
+{AI95-00415-01AI95-00415-01} ISO/IEC 1989:2002, Information technology
+-- Programming languages -- COBOL.
+
+4.1/3
+{AI05-0127-2AI05-0127-2} {AI05-0299-1AI05-0299-1} ISO/IEC 3166-1:2006,
+Codes for the representation of names of countries and their
+subdivisions -- Part 1: Country Codes.
+
+5
+ISO/IEC 6429:1992, Information technology -- Control functions for coded
+graphic character sets.
+
+5.1/2
+{AI95-00351-01AI95-00351-01} ISO 8601:2004, Data elements and
+interchange formats -- Information interchange -- Representation of
+dates and times.
+
+6/3
+{AI05-0299-1AI05-0299-1} ISO/IEC 8859-1:1998, Information technology --
+8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet
+No.  1.
+
+7/3
+{AI95-00415-01AI95-00415-01} {AI05-0266-1AI05-0266-1} ISO/IEC 9899:2011,
+Information technology -- Programming languages -- C.
+
+8/3
+{8652/00018652/0001} {AI95-00124-01AI95-00124-01}
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} ISO/IEC
+10646:2011, Information technology -- Universal Multiple-Octet Coded
+Character Set (UCS).
+
+8.a.1/2
+          This paragraph was deleted.{8652/00018652/0001}
+          {AI95-00124-01AI95-00124-01} {AI95-00285-01AI95-00285-01}
+
+9/3
+{AI95-00376-01AI95-00376-01} {AI05-0266-1AI05-0266-1} ISO/IEC
+14882:2011, Information technology -- Programming languages -- C++.
+
+10/2
+{AI95-00285-01AI95-00285-01} ISO/IEC TR 19769:2004, Information
+technology -- Programming languages, their environments and system
+software interfaces -- Extensions for the programming language C to
+support new character data types.
+
+10.a
+          Discussion: POSIX, Portable Operating System Interface (POSIX)
+          -- Part 1: System Application Program Interface (API) [C
+          Language], The Institute of Electrical and Electronics
+          Engineers, 1990.
+
+                     _Wording Changes from Ada 95_
+
+10.b/2
+          {AI95-00285-01AI95-00285-01} {AI95-00376-01AI95-00376-01}
+          {AI95-00415-01AI95-00415-01} Updated references to the most
+          recent versions of these standards.  Added C++ and time
+          standards.  Added C character set technical report.
+
+                    _Wording Changes from Ada 2005_
+
+10.c/3
+          {AI05-0127-2AI05-0127-2} Added language and country code
+          standards for locale support.
+
+10.d/3
+          {AI05-0266-1AI05-0266-1} Updated references to the most recent
+          versions of these standards.
+
+
+File: aarm2012.info,  Node: 1.3,  Prev: 1.2,  Up: 1
+
+1.3 Terms and Definitions
+=========================
+
+1/2
+{AI95-00415-01AI95-00415-01} Terms are defined throughout this
+International Standard, indicated by italic type.  Terms explicitly
+defined in this International Standard are not to be presumed to refer
+implicitly to similar terms defined elsewhere.  Mathematical terms not
+defined in this International Standard are to be interpreted according
+to the CRC Concise Encyclopedia of Mathematics, Second Edition.  Other
+terms not defined in this International Standard are to be interpreted
+according to the Webster's Third New International Dictionary of the
+English Language.  Informal descriptions of some terms are also given in
+*note Annex N::, "*note Annex N:: Glossary".  
+
+1.a
+          Discussion: The index contains an entry for every defined
+          term.
+
+1.a.1/2
+          {AI95-00415-01AI95-00415-01} The contents of the CRC Concise
+          Encyclopedia of Mathematics, Second Edition can be accessed on
+          http://www.mathworld.com (http://www.mathworld.com).  The ISBN
+          number of the book is ISBN 1584883472.
+
+1.b
+          Glossary entry: Each term defined in *note Annex N:: is marked
+          like this.
+
+1.c/3
+          Discussion: Here are some AARM-only definitions: The Ada
+          Rapporteur Group (ARG) interprets the Ada Reference Manual.  
+          An Ada Issue (AI) is a numbered ruling from the ARG. Ada
+          Issues created for Ada 83 are denoted as "AI83", while Ada
+          Issues created for Ada 95 are denoted as "AI95" in this
+          document.  Similarly, Ada Issues created for Ada 2005 are
+          denoted as "AI05" The Ada Commentary Integration Document
+          (ACID) is an edition of the Ada 83 RM in which clearly marked
+          insertions and deletions indicate the effect of integrating
+          the approved AIs.  The Uniformity Rapporteur Group (URG)
+          issued recommendations intended to increase uniformity across
+          Ada implementations.  The functions of the URG have been
+          assumed by the ARG. A Uniformity Issue (UI) was a numbered
+          recommendation from the URG. A Defect Report and Response is
+          an official query to WG9 about an error in the standard.
+          Defect Reports are processed by the ARG, and are referenced
+          here by their ISO numbers: 8652/nnnn.  Most changes to the Ada
+          95 standard include reference(s) to the Defect Report(s) that
+          prompted the change.  The Ada Conformity Assessment Test Suite
+          (ACATS) is a set of tests intended to check the conformity of
+          Ada implementations to this standard.  This set of tests was
+          previously known as the Ada Compiler Validation Capability
+          (ACVC).
+
+
+File: aarm2012.info,  Node: 2,  Next: 3,  Prev: 1,  Up: Top
+
+2 Lexical Elements
+******************
+
+1/3
+{AI05-0299-1AI05-0299-1} [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 clause.  Pragmas, which provide certain information
+for the compiler, are also described in this clause.]
+
+* Menu:
+
+* 2.1 ::      Character Set
+* 2.2 ::      Lexical Elements, Separators, and Delimiters
+* 2.3 ::      Identifiers
+* 2.4 ::      Numeric Literals
+* 2.5 ::      Character Literals
+* 2.6 ::      String Literals
+* 2.7 ::      Comments
+* 2.8 ::      Pragmas
+* 2.9 ::      Reserved Words
+
+
+File: aarm2012.info,  Node: 2.1,  Next: 2.2,  Up: 2
+
+2.1 Character Set
+=================
+
+1/3
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+{AI05-0266-1AI05-0266-1} The character repertoire for the text of an Ada
+program consists of the entire coding space described by the ISO/IEC
+10646:2011 Universal Multiple-Octet Coded Character Set.  This coding
+space is organized in planes, each plane comprising 65536 characters.  
+
+1.a/2
+          This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+1.b/2
+          This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+1.c/3
+          Discussion: {AI95-00285-01AI95-00285-01}
+          {AI05-0266-1AI05-0266-1} It is our intent to follow the
+          terminology of ISO/IEC 10646:2011 where appropriate, and to
+          remain compatible with the character classifications defined
+          in *note A.3::, "*note A.3:: Character Handling".
+
+                               _Syntax_
+
+     Paragraphs 2 and 3 were deleted.
+
+3.1/3
+     {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+     {AI05-0266-1AI05-0266-1} A character is defined by this
+     International Standard for each cell in the coding space described
+     by ISO/IEC 10646:2011, regardless of whether or not ISO/IEC
+     10646:2011 allocates a character to that cell.
+
+                          _Static Semantics_
+
+4/3
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+{AI05-0079-1AI05-0079-1} {AI05-0262-1AI05-0262-1}
+{AI05-0266-1AI05-0266-1} The coded representation for characters is
+implementation defined [(it need not be a representation defined within
+ISO/IEC 10646:2011)].  A character whose relative code point in its
+plane is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a
+program.  The only characters allowed outside of comments are those in
+categories other_format, format_effector, and graphic_character.
+
+4.a
+          Implementation defined: The coded representation for the text
+          of an Ada program.
+
+4.b/2
+          Ramification: {AI95-00285-01AI95-00285-01} Note that this rule
+          doesn't really have much force, since the implementation can
+          represent characters in the source in any way it sees fit.
+          For example, an implementation could simply define that what
+          seems to be an other_private_use character is actually a
+          representation of the space character.
+
+4.1/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1}
+{AI05-0299-1AI05-0299-1} The semantics of an Ada program whose text is
+not in Normalization Form KC (as defined by Clause 21 of ISO/IEC
+10646:2011) is implementation defined.
+
+4.c/2
+          Implementation defined: The semantics of an Ada program whose
+          text is not in Normalization Form KC.
+
+5/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1}
+{AI05-0299-1AI05-0299-1} The description of the language definition in
+this International Standard uses the character properties General
+Category, Simple Uppercase Mapping, Uppercase Mapping, and Special Case
+Condition of the documents referenced by the note in Clause 1 of ISO/IEC
+10646:2011.  The actual set of graphic symbols used by an implementation
+for the visual representation of the text of an Ada program is not
+specified.  
+
+6/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} Characters are
+categorized as follows:
+
+6.a/3
+          Discussion: {AI05-0005-1AI05-0005-1} {AI05-0262-1AI05-0262-1}
+          {AI05-0266-1AI05-0266-1} Our character classification
+          considers that the cells not allocated in ISO/IEC 10646:2011
+          are graphic characters, except for those whose relative code
+          point in their plane is 16#FFFE# or 16#FFFF#.  This seems to
+          provide the best compatibility with future versions of ISO/IEC
+          10646, as future characters can already be used in Ada
+          character and string literals.
+
+7/2
+
+               This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+8/2
+{AI95-00285-01AI95-00285-01} letter_uppercase
+               Any character whose General Category is defined to be
+               "Letter, Uppercase".
+
+9/2
+{AI95-00285-01AI95-00285-01} letter_lowercase
+               Any character whose General Category is defined to be
+               "Letter, Lowercase".
+
+9.a/1
+          This paragraph was deleted.{8652/00018652/0001}
+          {AI95-00124-01AI95-00124-01}
+
+9.1/2
+{AI95-00285-01AI95-00285-01} letter_titlecase
+               Any character whose General Category is defined to be
+               "Letter, Titlecase".
+
+9.2/2
+{AI95-00285-01AI95-00285-01} letter_modifier
+               Any character whose General Category is defined to be
+               "Letter, Modifier".
+
+9.3/2
+{AI95-00285-01AI95-00285-01} letter_other
+               Any character whose General Category is defined to be
+               "Letter, Other".
+
+9.4/2
+{AI95-00285-01AI95-00285-01} mark_non_spacing
+               Any character whose General Category is defined to be
+               "Mark, Non-Spacing".
+
+9.5/2
+{AI95-00285-01AI95-00285-01} mark_spacing_combining
+               Any character whose General Category is defined to be
+               "Mark, Spacing Combining".
+
+10/2
+{AI95-00285-01AI95-00285-01} number_decimal
+               Any character whose General Category is defined to be
+               "Number, Decimal".
+
+10.1/2
+{AI95-00285-01AI95-00285-01} number_letter
+               Any character whose General Category is defined to be
+               "Number, Letter".
+
+10.2/2
+{AI95-00285-01AI95-00285-01} punctuation_connector
+               Any character whose General Category is defined to be
+               "Punctuation, Connector".
+
+10.3/2
+{AI95-00285-01AI95-00285-01} other_format
+               Any character whose General Category is defined to be
+               "Other, Format".
+
+11/2
+{AI95-00285-01AI95-00285-01} separator_space
+               Any character whose General Category is defined to be
+               "Separator, Space".
+
+12/2
+{AI95-00285-01AI95-00285-01} separator_line
+               Any character whose General Category is defined to be
+               "Separator, Line".
+
+12.1/2
+{AI95-00285-01AI95-00285-01} separator_paragraph
+               Any character whose General Category is defined to be
+               "Separator, Paragraph".
+
+13/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} format_effector
+               The characters whose code points are 16#09# (CHARACTER
+               TABULATION), 16#0A# (LINE FEED), 16#0B# (LINE
+               TABULATION), 16#0C# (FORM FEED), 16#0D# (CARRIAGE
+               RETURN), 16#85# (NEXT LINE), and the characters in
+               categories separator_line and separator_paragraph.  
+
+13.a/2
+          Discussion: ISO/IEC 10646:2003 does not define the names of
+          control characters, but rather refers to the names defined by
+          ISO/IEC 6429:1992.  These are the names that we use here.
+
+13.1/2
+{AI95-00285-01AI95-00285-01} other_control
+               Any character whose General Category is defined to be
+               "Other, Control", and which is not defined to be a
+               format_effector.
+
+13.2/2
+{AI95-00285-01AI95-00285-01} other_private_use
+               Any character whose General Category is defined to be
+               "Other, Private Use".
+
+13.3/2
+{AI95-00285-01AI95-00285-01} other_surrogate
+               Any character whose General Category is defined to be
+               "Other, Surrogate".
+
+14/3
+{AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+{AI05-0262-1AI05-0262-1} graphic_character
+               Any character that is not in the categories
+               other_control, other_private_use, other_surrogate,
+               format_effector, and whose relative code point in its
+               plane is neither 16#FFFE# nor 16#FFFF#.
+
+14.a/2
+          This paragraph was deleted.
+
+14.b/2
+          Discussion: {AI95-00285-01AI95-00285-01} We considered basing
+          the definition of lexical elements on Annex A of ISO/IEC TR
+          10176 (4th edition), which lists the characters which should
+          be supported in identifiers for all programming languages, but
+          we finally decided against this option.  Note that it is not
+          our intent to diverge from ISO/IEC TR 10176, except to the
+          extent that ISO/IEC TR 10176 itself diverges from ISO/IEC
+          10646:2003 (which is the case at the time of this writing
+          [January 2005]).
+
+14.c/2
+          More precisely, we intend to align strictly with ISO/IEC
+          10646:2003.  It must be noted that ISO/IEC TR 10176 is a
+          Technical Report while ISO/IEC 10646:2003 is a Standard.  If
+          one has to make a choice, one should conform with the Standard
+          rather than with the Technical Report.  And, it turns out that
+          one must make a choice because there are important differences
+          between the two:
+
+14.d/2
+             * ISO/IEC TR 10176 is still based on ISO/IEC 10646:2000
+               while ISO/IEC 10646:2003 has already been published for a
+               year.  We cannot afford to delay the adoption of our
+               amendment until ISO/IEC TR 10176 has been revised.
+
+14.e/2
+             * There are considerable differences between the two
+               editions of ISO/IEC 10646, notably in supporting
+               characters beyond the BMP (this might be significant for
+               some languages, e.g.  Korean).
+
+14.f/2
+             * ISO/IEC TR 10176 does not define case conversion tables,
+               which are essential for a case-insensitive language like
+               Ada.  To get case conversion tables, we would have to
+               reference either ISO/IEC 10646:2003 or Unicode, or we
+               would have to invent our own.
+
+14.g/2
+          For the purpose of defining the lexical elements of the
+          language, we need character properties like categorization, as
+          well as case conversion tables.  These are mentioned in
+          ISO/IEC 10646:2003 as useful for implementations, with a
+          reference to Unicode.  Machine-readable tables are available
+          on the web at URLs:
+
+14.h/2
+               http://www.unicode.org/Public/4.0-Update/UnicodeData-4.0.0.txt 
(http://www.unicode.org/Public/4.0-Update/UnicodeData-4.0.0.txt)
+               http://www.unicode.org/Public/4.0-Update/CaseFolding-4.0.0.txt 
(http://www.unicode.org/Public/4.0-Update/CaseFolding-4.0.0.txt)
+
+14.i/2
+          with an explanatory document found at URL:
+
+14.j/2
+               http://www.unicode.org/Public/4.0-Update/UCD-4.0.0.html 
(http://www.unicode.org/Public/4.0-Update/UCD-4.0.0.html)
+
+14.k/2
+          The actual text of the standard only makes specific references
+          to the corresponding clauses of ISO/IEC 10646:2003, not to
+          Unicode.
+
+15/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} The following
+names are used when referring to certain characters (the first name is
+that given in ISO/IEC 10646:2011): 
+
+15.a/3
+          Discussion: {AI95-00285-01AI95-00285-01}
+          {AI05-0266-1AI05-0266-1} This table serves to show the
+          correspondence between ISO/IEC 10646:2011 names and the
+          graphic symbols (glyphs) used in this International Standard.
+          These are the characters that play a special role in the
+          syntax of Ada.
+
+  graphic symbol   name                      graphic symbol   name
+         "         quotation mark                   :         colon
+         #         number sign                      ;         semicolon
+         &         ampersand                        <         less-than sign
+         '         apostrophe, tick                 =         equals sign
+         (         left parenthesis                 >         greater-than sign
+         )         right parenthesis                _         low line, 
underline
+         *         asterisk, multiply               |         vertical line
+         +         plus sign                        /         solidus, divide
+         ,         comma                            !         exclamation point
+         -         hyphen-minus, minus              %         percent sign
+         .         full stop, dot, point
+
+                     _Implementation Requirements_
+
+16/3
+{AI05-0286-1AI05-0286-1} An Ada implementation shall accept Ada source
+code in UTF-8 encoding, with or without a BOM (see *note A.4.11::),
+where every character is represented by its code point.  The character
+pair CARRIAGE RETURN/LINE FEED (code points 16#0D# 16#0A#) signifies a
+single end of line (see *note 2.2::); every other occurrence of a
+format_effector other than the character whose code point position is
+16#09# (CHARACTER TABULATION) also signifies a single end of line.
+
+16.a/3
+          Reason: {AI05-0079-1AI05-0079-1} {AI05-0286-1AI05-0286-1} This
+          is simply requiring that an Ada implementation be able to
+          directly process the ACATS, which is provided in the described
+          format.  Note that files that only contain characters with
+          code points in the first 128 (which is the majority of the
+          ACATS) are represented in the same way in both UTF-8 and in
+          "plain" string format.  The ACATS includes a BOM in files that
+          have any characters with code points greater than 127.  Note
+          that the BOM contains characters not legal in Ada source code,
+          so an implementation can use that to automatically distinguish
+          between files formatted as plain Latin-1 strings and UTF-8
+          with BOM.
+
+16.b/3
+          We allow line endings to be both represented as the pair CR LF
+          (as in Windows and the ACATS), and as single format_effector
+          characters (usually LF, as in Linux), in order that files
+          created by standard tools on most operating systems will meet
+          the standard format.  We specify how many line endings each
+          represent so that compilers use the same line numbering for
+          standard source files.
+
+16.c/3
+          This requirement increases portability by having a format that
+          is accepted by all Ada compilers.  Note that implementations
+          can support other source representations, including structured
+          representations like a parse tree.
+
+                     _Implementation Permissions_
+
+17/3
+{AI95-00285-01AI95-00285-01} {AI05-0266-1AI05-0266-1} The categories
+defined above, as well as case mapping and folding, may be based on an
+implementation-defined version of ISO/IEC 10646 (2003 edition or later).
+
+17.b/3
+          Ramification: The exact categories, case mapping, and case
+          folding chosen affects identifiers, the result of
+          '[[Wide_]Wide_]Image, and packages Wide_Characters.Handling
+          and Wide_Wide_Characters.Handling.
+
+17.c/3
+          Discussion: This permission allows implementations to upgrade
+          to using a newer character set standard whenever that makes
+          sense, rather than having to wait for the next Ada Standard.
+          But the character set standard used cannot be older than
+          ISO/IEC 10646:2003 (which is essentially similar to Unicode
+          4.0).
+
+     NOTES
+
+18/2
+     1  {AI95-00285-01AI95-00285-01} The characters in categories
+     other_control, other_private_use, and other_surrogate are only
+     allowed in comments.
+
+19.a/3
+          This paragraph was deleted.{AI05-0286-1AI05-0286-1}
+
+                        _Extensions to Ada 83_
+
+19.b
+          Ada 95 allows 8-bit and 16-bit characters, as well as
+          implementation-specified character sets.
+
+                     _Wording Changes from Ada 83_
+
+19.c/3
+          {AI95-00285-01AI95-00285-01} {AI05-0299-1AI05-0299-1} The
+          syntax rules in this subclause are modified to remove the
+          emphasis on basic characters vs.  others.  (In this day and
+          age, there is no need to point out that you can write programs
+          without using (for example) lower case letters.)  In
+          particular, character (representing all characters usable
+          outside comments) is added, and basic_graphic_character,
+          other_special_character, and basic_character are removed.
+          Special_character is expanded to include Ada 83's
+          other_special_character, as well as new 8-bit characters not
+          present in Ada 83.  Ada 2005 removes special_character
+          altogether; we want to stick to ISO/IEC 10646:2003 character
+          classifications.  Note that the term "basic letter" is used in
+          *note A.3::, "*note A.3:: Character Handling" to refer to
+          letters without diacritical marks.
+
+19.d/2
+          {AI95-00285-01AI95-00285-01} Character names now come from
+          ISO/IEC 10646:2003.
+
+19.e/2
+          This paragraph was deleted.{AI95-00285-01AI95-00285-01}
+
+                        _Extensions to Ada 95_
+
+19.f/2
+          {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+          Program text can use most characters defined by
+          ISO-10646:2003.  This subclause has been rewritten to use the
+          categories defined in that Standard.  This should ease
+          programming in languages other than English.
+
+                    _Inconsistencies With Ada 2005_
+
+19.g/3
+          {AI05-0299-1AI05-0299-1} {AI05-0266-1AI05-0266-1} An
+          implementation is allowed (but not required) to use a newer
+          character set standard to determine the categories, case
+          mapping, and case folding.  Doing so will change the results
+          of attributes '[[Wide_]Wide_]Image and the packages
+          [Wide_]Wide_Characters.Handling in the case of a few rarely
+          used characters.  (This also could make some identifiers
+          illegal, for characters that are no longer classified as
+          letters.)  This is unlikely to be a problem in practice.
+          Moreover, truly portable Ada 2012 programs should avoid using
+          in these contexts any characters that would have different
+          classifications in any character set standards issued since
+          10646:2003 (since the compiler can use any such standard as
+          the basis for its classifications).
+
+                    _Wording Changes from Ada 2005_
+
+19.h/3
+          {AI05-0079-1AI05-0079-1} Correction: Clarified that only
+          characters in the categories defined here are allowed in the
+          source of an Ada program.  This was clear in Ada 95, but
+          Amendment 1 dropped the wording instead of correcting it.
+
+19.i/3
+          {AI05-0286-1AI05-0286-1} A standard source representation is
+          defined that all compilers are expected to process.  Since
+          this is the same format as the ACATS, it seems unlikely that
+          there are any implementations that don't meet this
+          requirement.  Moreover, other representations are still
+          permitted, and the "impossible or impractical" loophole (see
+          *note 1.1.3::) can be invoked for any implementations that
+          cannot directly process the ACATS.
+
+
+File: aarm2012.info,  Node: 2.2,  Next: 2.3,  Prev: 2.1,  Up: 2
+
+2.2 Lexical Elements, Separators, and Delimiters
+================================================
+
+                          _Static Semantics_
+
+1
+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 formed from a sequence of characters, and is
+either a delimiter, an identifier, a reserved word, a numeric_literal, a
+character_literal, a string_literal, or a comment.  The meaning of a
+program depends only on the particular sequences of lexical elements
+that form its compilations, excluding comments.
+
+2/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The text of a
+compilation is divided into lines.  In general, the representation for
+an end of line is implementation defined.  However, a sequence of one or
+more format_effectors other than the character whose code point is
+16#09# (CHARACTER TABULATION) signifies at least one end of line.
+
+2.a
+          Implementation defined: The representation for an end of line.
+
+3/2
+{AI95-00285-01AI95-00285-01} [In some cases an explicit separator is
+required to separate adjacent lexical elements.]  A separator is any of
+a separator_space, a format_effector, or the end of a line, as follows:
+
+4/2
+   * {AI95-00285-01AI95-00285-01} A separator_space is a separator
+     except within a comment, a string_literal, or a character_literal.
+
+5/3
+   * {AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The character
+     whose code point is 16#09# (CHARACTER TABULATION) is a separator
+     except within a comment.
+
+6
+   * The end of a line is always a separator.
+
+7
+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, a reserved word,
+or a numeric_literal and an adjacent identifier, reserved word, or
+numeric_literal.
+
+7.1/3
+{AI05-0079-1AI05-0079-1} One or more other_format characters are allowed
+anywhere that a separator is[; any such characters have no effect on the
+meaning of an Ada program].
+
+8/2
+{AI95-00285-01AI95-00285-01} A delimiter is either one of the following
+characters:
+
+9
+     &    '    (    )    *    +    ,    -    .    /    :    ;    <    =    >   
 |
+
+10
+or one of the following compound delimiters each composed of two
+adjacent special characters
+
+11
+     =>    ..    **    :=    /=    >=    <=    <<    >>    <>
+
+12
+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.
+
+13
+The following names are used when referring to compound delimiters:
+
+     delimiter  name=> 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
+                     _Implementation Requirements_
+
+14
+An implementation shall support lines of at least 200 characters in
+length, not counting any characters used to signify the end of a line.
+An implementation shall support lexical elements of at least 200
+characters in length.  The maximum supported line length and lexical
+element length are implementation defined.
+
+14.a
+          Implementation defined: Maximum supported line length and
+          lexical element length.
+
+14.b
+          Discussion: From URG recommendation.
+
+                     _Wording Changes from Ada 95_
+
+14.c/3
+          {AI95-00285-01AI95-00285-01} {AI05-0299-1AI05-0299-1} The
+          wording was updated to use the new character categories
+          defined in the preceding subclause.
+
+                       _Extensions to Ada 2005_
+
+14.d/3
+          {AI05-0079-1AI05-0079-1} Correction: Clarified that
+          other_format characters are allowed anywhere that separators
+          are allowed.  This was intended in Ada 2005, but didn't
+          actually make it into the wording.
+
+
+File: aarm2012.info,  Node: 2.3,  Next: 2.4,  Prev: 2.2,  Up: 2
+
+2.3 Identifiers
+===============
+
+1
+Identifiers are used as names.
+
+                               _Syntax_
+
+2/2
+     {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+     identifier ::=
+        identifier_start {identifier_start | identifier_extend}
+
+3/2
+     {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+     identifier_start ::=
+          letter_uppercase
+        | letter_lowercase
+        | letter_titlecase
+        | letter_modifier
+        | letter_other
+        | number_letter
+
+3.1/3
+     {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+     {AI05-0091-1AI05-0091-1} identifier_extend ::=
+          mark_non_spacing
+        | mark_spacing_combining
+        | number_decimal
+        | punctuation_connector
+
+4/3
+     {AI95-00395-01AI95-00395-01} {AI05-0091-1AI05-0091-1} An identifier
+     shall not contain two consecutive characters in category
+     punctuation_connector, or end with a character in that category.
+
+4.a/3
+          Reason: This rule was stated in the syntax in Ada 95, but that
+          has gotten too complex in Ada 2005.
+
+                          _Static Semantics_
+
+5/3
+{AI95-00285-01AI95-00285-01} {AI05-0091-1AI05-0091-1}
+{AI05-0227-1AI05-0227-1} {AI05-0266-1AI05-0266-1}
+{AI05-0299-1AI05-0299-1} Two identifiers are considered the same if they
+consist of the same sequence of characters after applying
+locale-independent simple case folding, as defined by documents
+referenced in the note in Clause 1 of ISO/IEC 10646:2011.
+
+5.a/3
+          Discussion: {AI05-0227-1AI05-0227-1} Simple case folding is a
+          mapping to lower case, so this is matching the defining (lower
+          case) version of a reserved word.  We could have mentioned
+          case folding of the reserved words, but as that is an identity
+          function, it would have no effect.
+
+5.a.1/3
+          {AI05-0227-1AI05-0227-1} The "documents referenced" means
+          Unicode.  Note that simple case folding is supposed to be
+          compatible between Unicode versions, so the Unicode version
+          used doesn't matter.
+
+5.3/3
+{AI95-00395-01AI95-00395-01} {AI05-0091-1AI05-0091-1}
+{AI05-0227-1AI05-0227-1} After applying simple case folding, an
+identifier shall not be identical to a reserved word.
+
+5.b/3
+          Implementation Note: We match the reserved words after
+          applying case folding so that the rules for identifiers and
+          reserved words are the same.  Since a compiler usually will
+          lexically process identifiers and reserved words the same way
+          (often with the same code), this will prevent a lot of
+          headaches.
+
+5.c/3
+          Ramification: {AI05-0227-1AI05-0227-1} The rules for reserved
+          words differ in one way: they define case conversion on
+          letters rather than sequences.  This means that it is possible
+          that there exist some unusual sequences that are neither
+          identifiers nor reserved words.  We are not aware of any such
+          sequences so long as we use simple case folding (as opposed to
+          full case folding), but we have defined the rules in case any
+          are introduced in future character set standards.  This
+          originally was a problem when converting to upper case: "if"
+          and "acce�" have upper case conversions of "IF" and "ACCESS"
+          respectively.  We would not want these to be treated as
+          reserved words.  But neither of these cases exist when using
+          simple case folding.
+
+                     _Implementation Permissions_
+
+6
+In a nonstandard mode, an implementation may support other upper/lower
+case equivalence rules for identifiers[, to accommodate local
+conventions].
+
+6.a/3
+          Discussion: {AI95-00285-01AI95-00285-01}
+          {AI05-0227-1AI05-0227-1} For instance, in most languages, the
+          simple case folded equivalent of LATIN CAPITAL LETTER I (an
+          upper case letter without a dot above) is LATIN SMALL LETTER I
+          (a lower case letter with a dot above).  In Turkish, though,
+          LATIN CAPITAL LETTER I and LATIN CAPITAL LETTER I WITH DOT
+          ABOVE are two distinct letters, so the case folded equivalent
+          of LATIN CAPITAL LETTER I is LATIN SMALL LETTER DOTLESS I, and
+          the case folded equivalent of LATIN CAPITAL LETTER I WITH DOT
+          ABOVE is LATIN SMALL LETTER I. Take for instance the following
+          identifier (which is the name of a city on the Tigris river in
+          Eastern Anatolia):
+
+6.b/3
+               DIYARBAKIR -- The first i is dotted, the second isn't.
+
+6.c/3
+          A Turkish reader would expect that the above identifier is
+          equivalent to:
+
+6.d/3
+               diyarbakir
+
+6.d.1/3
+          However, locale-independent simple case folding (and thus Ada)
+          maps this to:
+
+6.d.2/3
+               dIyarbakir
+
+6.e/3
+          which is different from any of the following identifiers:
+
+6.f/2
+               diyarbakir
+               diyarbakir
+               diyarbakir
+               diyarbakir
+
+6.f.1/3
+          including the "correct" matching identifier for Turkish.
+          Upper case conversion (used in '[Wide_]Wide_Image) introduces
+          additional problems.
+
+6.g/3
+          An implementation targeting the Turkish market is allowed (in
+          fact, expected) to provide a nonstandard mode where case
+          folding is appropriate for Turkish.
+
+6.j/2
+          Lithuanian and Azeri are two other languages that present
+          similar idiosyncrasies.
+
+     NOTES
+
+6.1/2
+     2  {AI95-00285-01AI95-00285-01} Identifiers differing only in the
+     use of corresponding upper and lower case letters are considered
+     the same.
+
+                              _Examples_
+
+7
+Examples of identifiers:
+
+8/2
+     {AI95-00433-01AI95-00433-01} Count      X    Get_Symbol   Ethelyn   Marion
+     Snobol_4   X1   Page_Count   Store_Next_Item
+     [Unicode 928][Unicode 955][Unicode 940][Unicode 964][Unicode 969][Unicode 
957]      -- Plato
+     [Unicode 1063][Unicode 1072][Unicode 1081][Unicode 1082][Unicode 
1086][Unicode 1074][Unicode 1089][Unicode 1082][Unicode 1080][Unicode 1081]  -- 
Tchaikovsky
+     [Unicode 952]  [Unicode 966]        -- Angles
+
+                     _Wording Changes from Ada 83_
+
+8.a
+          We no longer include reserved words as identifiers.  This is
+          not a language change.  In Ada 83, identifier included
+          reserved words.  However, this complicated several other rules
+          (for example, regarding implementation-defined attributes and
+          pragmas, etc.).  We now explicitly allow certain reserved
+          words for attribute designators, to make up for the loss.
+
+8.b
+          Ramification: Because syntax rules are relevant to overload
+          resolution, it means that if it looks like a reserved word, it
+          is not an identifier.  As a side effect, implementations
+          cannot use reserved words as implementation-defined attributes
+          or pragma names.
+
+                        _Extensions to Ada 95_
+
+8.c/2
+          {AI95-00285-01AI95-00285-01} An identifier can use any letter
+          defined by ISO-10646:2003, along with several other
+          categories.  This should ease programming in languages other
+          than English.
+
+                   _Incompatibilities With Ada 2005_
+
+8.d/3
+          {AI05-0091-1AI05-0091-1} Correction: other_format characters
+          were removed from identifiers as the Unicode recommendations
+          have changed.  This change can only affect programs written
+          for the original Ada 2005, so there should be few such
+          programs.
+
+8.e/3
+          {AI05-0227-1AI05-0227-1} Correction: We now specify simple
+          case folding rather than full case folding.  That potentially
+          could change identifier equivalence, although it is more
+          likely that identifiers that are considered the same in
+          original Ada 2005 will now be considered different.  This
+          change was made because the original Ada 2005 definition was
+          incompatible (and even inconsistent in unusual cases) with the
+          Ada 95 identifier equivalence rules.  As such, the Ada 2005
+          rules were rarely fully implemented, and in any case, only Ada
+          2005 identifiers containing wide characters could be affected.
+
+
+File: aarm2012.info,  Node: 2.4,  Next: 2.5,  Prev: 2.3,  Up: 2
+
+2.4 Numeric Literals
+====================
+
+1
+There are two kinds 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.
+
+                               _Syntax_
+
+2
+     numeric_literal ::= decimal_literal | based_literal
+
+     NOTES
+
+3
+     3  The type of an integer literal is universal_integer.  The type
+     of a real literal is universal_real.
+
+* Menu:
+
+* 2.4.1 ::    Decimal Literals
+* 2.4.2 ::    Based Literals
+
+
+File: aarm2012.info,  Node: 2.4.1,  Next: 2.4.2,  Up: 2.4
+
+2.4.1 Decimal Literals
+----------------------
+
+1
+A decimal_literal is a numeric_literal in the conventional decimal
+notation (that is, the base is ten).
+
+                               _Syntax_
+
+2
+     decimal_literal ::= numeral [.numeral] [exponent]
+
+3
+     numeral ::= digit {[underline] digit}
+
+4
+     exponent ::= E [+] numeral | E - numeral
+
+4.1/2
+     {AI95-00285-01AI95-00285-01} digit ::=
+     0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
+
+5
+     An exponent for an integer literal shall not have a minus sign.
+
+5.a
+          Ramification: Although this rule is in this subclause, it
+          applies also to the next subclause.
+
+                          _Static Semantics_
+
+6
+An underline character in a numeric_literal does not affect its meaning.
+The letter E of an exponent can be written either in lower case or in
+upper case, with the same meaning.
+
+6.a
+          Ramification: Although these rules are in this subclause, they
+          apply also to the next subclause.
+
+7
+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.
+
+                              _Examples_
+
+8
+Examples of decimal literals:
+
+9
+     12        0      1E6    123_456    --  integer literals
+
+     12.0      0.0    0.456  3.14159_26 --  real literals
+
+                     _Wording Changes from Ada 83_
+
+9.a
+          We have changed the syntactic category name integer to be
+          numeral.  We got this idea from ACID. It avoids the confusion
+          between this and integers.  (Other places don't offer similar
+          confusions.  For example, a string_literal is different from a
+          string.)
+
+
+File: aarm2012.info,  Node: 2.4.2,  Prev: 2.4.1,  Up: 2.4
+
+2.4.2 Based Literals
+--------------------
+
+1
+[ A based_literal is a numeric_literal expressed in a form that
+specifies the base explicitly.]
+
+                               _Syntax_
+
+2
+     based_literal ::=
+        base # based_numeral [.based_numeral] # [exponent]
+
+3
+     base ::= numeral
+
+4
+     based_numeral ::=
+        extended_digit {[underline] extended_digit}
+
+5
+     extended_digit ::= digit | A | B | C | D | E | F
+
+                           _Legality Rules_
+
+6
+The base (the numeric value of the decimal numeral preceding the first
+#) shall be at least two and at most sixteen.  The extended_digits A
+through F represent the digits ten through fifteen, respectively.  The
+value of each extended_digit of a based_literal shall be less than the
+base.
+
+                          _Static Semantics_
+
+7
+The conventional meaning of based notation is assumed.  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.  The base and the exponent, if any, are
+in decimal notation.
+
+8
+The extended_digits A through F can be written either in lower case or
+in upper case, with the same meaning.
+
+                              _Examples_
+
+9
+Examples of based literals:
+
+10
+     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_1110#E11  --  real literals of value 4095.0
+
+                     _Wording Changes from Ada 83_
+
+10.a
+          The rule about which letters are allowed is now encoded in
+          BNF, as suggested by Mike Woodger.  This is clearly more
+          readable.
+
+
+File: aarm2012.info,  Node: 2.5,  Next: 2.6,  Prev: 2.4,  Up: 2
+
+2.5 Character Literals
+======================
+
+1
+[A character_literal is formed by enclosing a graphic character between
+two apostrophe characters.]
+
+                               _Syntax_
+
+2
+     character_literal ::= 'graphic_character'
+
+     NOTES
+
+3
+     4  A character_literal is an enumeration literal of a character
+     type.  See *note 3.5.2::.
+
+                              _Examples_
+
+4
+Examples of character literals:
+
+5/2
+     {AI95-00433-01AI95-00433-01} 'A'     '*'     '''     ' '
+     'L'     '[Unicode 1051]'     '[Unicode 923]'    -- Various els.
+     '[Unicode 8734]'     '[Unicode 1488]'            -- Big numbers - 
infinity and aleph.
+
+                     _Wording Changes from Ada 83_
+
+5.a/3
+          {AI05-0299-1AI05-0299-1} The definitions of the values of
+          literals are in Clauses 3 and 4, rather than here, since it
+          requires knowledge of types.
+
+
+File: aarm2012.info,  Node: 2.6,  Next: 2.7,  Prev: 2.5,  Up: 2
+
+2.6 String Literals
+===================
+
+1
+[A string_literal is formed by a sequence of graphic characters
+(possibly none) enclosed between two quotation marks used as string
+brackets.  They are used to represent operator_symbols (see *note
+6.1::), values of a string type (see *note 4.2::), and array
+subaggregates (see *note 4.3.3::).  ]
+
+                               _Syntax_
+
+2
+     string_literal ::= "{string_element}"
+
+3
+     string_element ::= "" | non_quotation_mark_graphic_character
+
+4
+     A string_element is either a pair of quotation marks (""), or a
+     single graphic_character other than a quotation mark.
+
+                          _Static Semantics_
+
+5
+The sequence of characters of a string_literal is formed from the
+sequence of string_elements between the bracketing quotation marks, in
+the given order, with a string_element that is "" becoming a single
+quotation mark in the sequence of characters, and any other
+string_element being reproduced in the sequence.
+
+6
+A null string literal is a string_literal with no string_elements
+between the quotation marks.
+
+     NOTES
+
+7
+     5  An end of line cannot appear in a string_literal.
+
+7.1/2
+     6  {AI95-00285-01AI95-00285-01} No transformation is performed on
+     the sequence of characters of a string_literal.
+
+                              _Examples_
+
+8
+Examples of string literals:
+
+9/2
+     {AI95-00433-01AI95-00433-01} "Message of the day:"
+
+     ""                    --  a null string literal
+     " "   "A"   """"      --  three string literals of length 1
+
+     "Characters such as $, %, and } are allowed in string literals"
+     "Archimedes said ""[Unicode 917][Unicode 973][Unicode 961][Unicode 
951][Unicode 954][Unicode 945]"""
+     "Volume of cylinder (PIr�h) = "
+
+                     _Wording Changes from Ada 83_
+
+9.a
+          The wording has been changed to be strictly lexical.  No
+          mention is made of string or character values, since
+          string_literals are also used to represent operator_symbols,
+          which don't have a defined value.
+
+9.b
+          The syntax is described differently.
+
+                     _Wording Changes from Ada 95_
+
+9.c/2
+          {AI95-00285-01AI95-00285-01} We explicitly say that the
+          characters of a string_literal should be used as is.  In
+          particular, no normalization or folding should be performed on
+          a string_literal.
+
+
+File: aarm2012.info,  Node: 2.7,  Next: 2.8,  Prev: 2.6,  Up: 2
+
+2.7 Comments
+============
+
+1
+A comment starts with two adjacent hyphens and extends up to the end of
+the line.
+
+                               _Syntax_
+
+2
+     comment ::= --{non_end_of_line_character}
+
+3
+     A comment may appear on any line of a program.
+
+                          _Static Semantics_
+
+4
+The presence or absence of comments has no influence on whether a
+program is legal or illegal.  Furthermore, comments do not influence the
+meaning of a program; their sole purpose is the enlightenment of the
+human reader.
+
+                              _Examples_
+
+5
+Examples of comments:
+
+6
+     --  the last sentence above echoes the Algol 68 report 
+
+     end;  --  processing of Line is complete 
+
+     --  a long comment may be split onto
+     --  two or more consecutive lines   
+
+     ----------------  the first two hyphens start the comment  
+
+
+File: aarm2012.info,  Node: 2.8,  Next: 2.9,  Prev: 2.7,  Up: 2
+
+2.8 Pragmas
+===========
+
+1
+A pragma is a compiler directive.  There are language-defined pragmas
+that give instructions for optimization, listing control, etc.  An
+implementation may support additional (implementation-defined) pragmas.
+
+                     _Language Design Principles_
+
+1.a/3
+          {AI05-0100-1AI05-0100-1} {AI05-0163-1AI05-0163-1} In general,
+          if all pragmas are treated as unrecognized pragmas, the
+          program should remain both syntactically and semantically
+          legal.  There are a few exceptions to this general principle
+          (for example, pragma Import can eliminate the need for a
+          completion), but the principle remains, and is strictly true
+          at the syntactic level.  Certainly any implementation-defined
+          pragmas should obey this principle both syntactically and
+          semantically, so that if the pragmas are not recognized by
+          some other implementation, the program will remain legal.
+
+                               _Syntax_
+
+2
+     pragma ::=
+        pragma identifier [(pragma_argument_association {, 
+     pragma_argument_association})];
+
+3/3
+     {AI05-0290-1AI05-0290-1} pragma_argument_association ::=
+          [pragma_argument_identifier =>] name
+        | [pragma_argument_identifier =>] expression
+        | pragma_argument_aspect_mark =>  name
+        | pragma_argument_aspect_mark =>  expression
+
+4/3
+     {AI05-0290-1AI05-0290-1} In a pragma, any
+     pragma_argument_associations without a pragma_argument_identifier
+     or pragma_argument_aspect_mark shall precede any associations with
+     a pragma_argument_identifier or pragma_argument_aspect_mark.
+
+5
+     Pragmas are only allowed at the following places in a program:
+
+6
+        * After a semicolon delimiter, but not within a formal_part or
+          discriminant_part.
+
+7/3
+        * {AI05-0100-1AI05-0100-1} {AI05-0163-1AI05-0163-1} At any place
+          where the syntax rules allow a construct defined by a
+          syntactic category whose name ends with "declaration", "item",
+          "statement", "clause", or "alternative", or one of the
+          syntactic categories variant or exception_handler; but not in
+          place of such a construct if the construct is required, or is
+          part of a list that is required to have at least one such
+          construct.
+
+7.1/3
+        * {AI05-0163-1AI05-0163-1} In place of a statement in a
+          sequence_of_statements.
+
+7.2/3
+        * {AI05-0100-1AI05-0100-1} At any place where a compilation_unit
+          is allowed.
+
+8
+     Additional syntax rules and placement restrictions exist for
+     specific pragmas.
+
+8.a
+          Discussion: The above rule is written in text, rather than in
+          BNF; the syntactic category pragma is not used in any BNF
+          syntax rule.
+
+8.b
+          Ramification: A pragma is allowed where a
+          generic_formal_parameter_declaration is allowed.
+
+9
+The name of a pragma is the identifier following the reserved word
+pragma.  The name or expression of a pragma_argument_association is a
+pragma argument.
+
+9.a/2
+          To be honest: {AI95-00284-02AI95-00284-02} For compatibility
+          with Ada 83, the name of a pragma may also be "interface",
+          which is not an identifier (because it is a reserved word).
+          See *note J.12::.
+
+10/3
+{AI05-0272-1AI05-0272-1} An identifier specific to a pragma is an
+identifier or reserved word that is used in a pragma argument with
+special meaning for that pragma.
+
+10.a
+          To be honest: Whenever the syntax rules for a given pragma
+          allow "identifier" as an argument of the pragma, that
+          identifier is an identifier specific to that pragma.
+
+10.b/3
+          {AI05-0272-1AI05-0272-1} In a few cases, a reserved word is
+          allowed as "an identifier specific to a pragma".  Even in
+          these cases, the syntax still is written as identifier (the
+          reserved word(s) are not shown).  For example, the restriction
+          No_Use_Of_Attribute (see *note 13.12.1::) allows the reserved
+          words which can be attribute designators, but the syntax for a
+          restriction does not include these reserved words.
+
+                          _Static Semantics_
+
+11
+If an implementation does not recognize the name of a pragma, then it
+has no effect on the semantics of the program.  Inside such a pragma,
+the only rules that apply are the Syntax Rules.
+
+11.a
+          To be honest: This rule takes precedence over any other rules
+          that imply otherwise.
+
+11.b
+          Ramification: Note well: this rule applies only to pragmas
+          whose name is not recognized.  If anything else is wrong with
+          a pragma (at compile time), the pragma is illegal.  This is
+          true whether the pragma is language defined or implementation
+          defined.
+
+11.c
+          For example, an expression in an unrecognized pragma does not
+          cause freezing, even though the rules in *note 13.14::, "*note
+          13.14:: Freezing Rules" say it does; the above rule overrules
+          those other rules.  On the other hand, an expression in a
+          recognized pragma causes freezing, even if this makes
+          something illegal.
+
+11.d
+          For another example, an expression that would be ambiguous is
+          not illegal if it is inside an unrecognized pragma.
+
+11.e
+          Note, however, that implementations have to recognize pragma
+          Inline(Foo) and freeze things accordingly, even if they choose
+          to never do inlining.
+
+11.f
+          Obviously, the contradiction needs to be resolved one way or
+          the other.  The reasons for resolving it this way are: The
+          implementation is simple -- the compiler can just ignore the
+          pragma altogether.  The interpretation of constructs appearing
+          inside implementation-defined pragmas is implementation
+          defined.  For example: "pragma Mumble(X);".  If the current
+          implementation has never heard of Mumble, then it doesn't know
+          whether X is a name, an expression, or an identifier specific
+          to the pragma Mumble.
+
+11.g
+          To be honest: The syntax of individual pragmas overrides the
+          general syntax for pragma.
+
+11.h
+          Ramification: Thus, an identifier specific to a pragma is not
+          a name, syntactically; if it were, the visibility rules would
+          be invoked, which is not what we want.
+
+11.i/3
+          {AI05-0229-1AI05-0229-1} This also implies that named
+          associations do not allow one to give the arguments in an
+          arbitrary order -- the order given in the syntax rule for each
+          individual pragma must be obeyed.  However, it is generally
+          possible to leave out earlier arguments when later ones are
+          given; for example, this is allowed by the syntax rule for
+          pragma Import (see *note J.15.5::, "*note J.15.5:: Interfacing
+          Pragmas").  As for subprogram calls, positional notation
+          precedes named notation.
+
+11.j
+          Note that Ada 83 had no pragmas for which the order of named
+          associations mattered, since there was never more than one
+          argument that allowed named associations.
+
+11.k
+          To be honest: The interpretation of the arguments of
+          implementation-defined pragmas is implementation defined.
+          However, the syntax rules have to be obeyed.
+
+                          _Dynamic Semantics_
+
+12
+Any pragma that appears at the place of an executable construct is
+executed.  Unless otherwise specified for a particular pragma, this
+execution consists of the evaluation of each evaluable pragma argument
+in an arbitrary order.
+
+12.a
+          Ramification: For a pragma that appears at the place of an
+          elaborable construct, execution is elaboration.
+
+12.b
+          An identifier specific to a pragma is neither a name nor an
+          expression -- such identifiers are not evaluated (unless an
+          implementation defines them to be evaluated in the case of an
+          implementation-defined pragma).
+
+12.c
+          The "unless otherwise specified" part allows us (and
+          implementations) to make exceptions, so a pragma can contain
+          an expression that is not evaluated.  Note that pragmas in
+          type_definitions may contain expressions that depend on
+          discriminants.
+
+12.d
+          When we wish to define a pragma with some run-time effect, we
+          usually make sure that it appears in an executable context;
+          otherwise, special rules are needed to define the run-time
+          effect and when it happens.
+
+                     _Implementation Requirements_
+
+13
+The implementation shall give a warning message for an unrecognized
+pragma name.
+
+13.a
+          Ramification: An implementation is also allowed to have modes
+          in which a warning message is suppressed, or in which the
+          presence of an unrecognized pragma is a compile-time error.
+
+                     _Implementation Permissions_
+
+14
+An implementation may provide implementation-defined pragmas; the name
+of an implementation-defined pragma shall differ from those of the
+language-defined pragmas.
+
+14.a
+          Implementation defined: Implementation-defined pragmas.
+
+14.b
+          Ramification: The semantics of implementation-defined pragmas,
+          and any associated rules (such as restrictions on their
+          placement or arguments), are, of course, implementation
+          defined.  Implementation-defined pragmas may have run-time
+          effects.
+
+15
+An implementation may ignore an unrecognized pragma even if it violates
+some of the Syntax Rules, if detecting the syntax error is too complex.
+
+15.a
+          Reason: Many compilers use extra post-parsing checks to
+          enforce the syntax rules, since the Ada syntax rules are not
+          LR(k) (for any k).  (The grammar is ambiguous, in fact.)  This
+          paragraph allows them to ignore an unrecognized pragma,
+          without having to perform such post-parsing checks.
+
+                        _Implementation Advice_
+
+16/3
+{AI05-0163-1AI05-0163-1} Normally, implementation-defined pragmas should
+have no semantic effect for error-free programs; that is, if the
+implementation-defined pragmas in a working program are replaced with
+unrecognized pragmas, the program should still be legal, and should
+still have the same semantics.
+
+16.a.1/2
+          Implementation Advice: Implementation-defined pragmas should
+          have no semantic effect for error-free programs.
+
+16.a
+          Ramification: Note that "semantics" is not the same as
+          "effect;" as explained in *note 1.1.3::, the semantics defines
+          a set of possible effects.
+
+16.b
+          Note that adding a pragma to a program might cause an error
+          (either at compile time or at run time).  On the other hand,
+          if the language-specified semantics for a feature are in part
+          implementation defined, it makes sense to support pragmas that
+          control the feature, and that have real semantics; thus, this
+          paragraph is merely a recommendation.
+
+17
+Normally, an implementation should not define pragmas that can make an
+illegal program legal, except as follows:
+
+18/3
+   * {AI05-0229-1AI05-0229-1} A pragma used to complete a declaration;
+
+18.a/3
+          Discussion: {AI05-0229-1AI05-0229-1} There are no
+          language-defined pragmas which can be completions; pragma
+          Import was defined this way in Ada 95 and Ada 2005, but in Ada
+          2012 pragma Import just sets aspect Import which disallows
+          having any completion.
+
+19
+   * A pragma used to configure the environment by adding, removing, or
+     replacing library_items.
+
+19.a.1/2
+          Implementation Advice: Implementation-defined pragmas should
+          not make an illegal program legal, unless they complete a
+          declaration or configure the library_items in an environment.
+
+19.a
+          Ramification: For example, it is OK to support Interface,
+          System_Name, Storage_Unit, and Memory_Size pragmas for upward
+          compatibility reasons, even though all of these pragmas can
+          make an illegal program legal.  (The latter three can affect
+          legality in a rather subtle way: They affect the value of
+          named numbers in System, and can therefore affect the legality
+          in cases where static expressions are required.)
+
+19.b
+          On the other hand, adding implementation-defined pragmas to a
+          legal program can make it illegal.  For example, a common kind
+          of implementation-defined pragma is one that promises some
+          property that allows more efficient code to be generated.  If
+          the promise is a lie, it is best if the user gets an error
+          message.
+
+                    _Incompatibilities With Ada 83_
+
+19.c
+          In Ada 83, "bad" pragmas are ignored.  In Ada 95, they are
+          illegal, except in the case where the name of the pragma
+          itself is not recognized by the implementation.
+
+                        _Extensions to Ada 83_
+
+19.d
+          Implementation-defined pragmas may affect the legality of a
+          program.
+
+                     _Wording Changes from Ada 83_
+
+19.e
+          Implementation-defined pragmas may affect the run-time
+          semantics of the program.  This was always true in Ada 83
+          (since it was not explicitly forbidden by RM83), but it was
+          not clear, because there was no definition of "executing" or
+          "elaborating" a pragma.
+
+                       _Extensions to Ada 2005_
+
+19.f/3
+          {AI05-0163-1AI05-0163-1} Correction: Allow pragmas in place of
+          a statement, even if there are no other statements in a
+          sequence_of_statements.
+
+19.g/3
+          {AI05-0272-1AI05-0272-1} Identifiers specific to a pragma can
+          be reserved words.
+
+19.h/3
+          {AI05-0290-1AI05-0290-1} Pragma arguments can be identified
+          with aspect_marks; this allows identifier'Class in this
+          context.  As usual, this is only allowed if specifically
+          allowed by a particular pragma.
+
+                    _Wording Changes from Ada 2005_
+
+19.i/3
+          {AI05-0100-1AI05-0100-1} Correction: Clarified where pragmas
+          are (and are not) allowed.
+
+                               _Syntax_
+
+20
+     The forms of List, Page, and Optimize pragmas are as follows:
+
+21
+       pragma List(identifier);
+
+22
+       pragma Page;
+
+23
+       pragma Optimize(identifier);
+
+24
+     [Other pragmas are defined throughout this International Standard,
+     and are summarized in *note Annex L::.]
+
+24.a
+          Ramification: The language-defined pragmas are supported by
+          every implementation, although "supporting" some of them (for
+          example, Inline) requires nothing more than checking the
+          arguments, since they act only as advice to the
+          implementation.
+
+                          _Static Semantics_
+
+25
+A pragma 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.
+
+26
+A pragma Page 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).
+
+27
+A pragma Optimize takes one of the identifiers Time, Space, or Off as
+the single argument.  This pragma is allowed anywhere a pragma is
+allowed, and it applies until the end of the immediately enclosing
+declarative region, or for a pragma at the place of a compilation_unit,
+to the end of the compilation.  It gives advice to the implementation as
+to whether time or space is the primary optimization criterion, or that
+optional optimizations should be turned off.  [It is implementation
+defined how this advice is followed.]
+
+27.a
+          Implementation defined: Effect of pragma Optimize.
+
+27.b
+          Discussion: For example, a compiler might use Time vs.  Space
+          to control whether generic instantiations are implemented with
+          a macro-expansion model, versus a shared-generic-body model.
+
+27.c
+          We don't define what constitutes an "optimization" -- in fact,
+          it cannot be formally defined in the context of Ada.  One
+          compiler might call something an optional optimization,
+          whereas another compiler might consider that same thing to be
+          a normal part of code generation.  Thus, the programmer cannot
+          rely on this pragma having any particular portable effect on
+          the generated code.  Some compilers might even ignore the
+          pragma altogether.
+
+                              _Examples_
+
+28
+Examples of pragmas:
+
+29/3
+     {AI95-00433-01AI95-00433-01} {AI05-0229-1AI05-0229-1} pragma List(Off); 
-- turn off listing generation
+     pragma Optimize(Off); -- turn off optional optimizations
+     pragma Pure(Rational_Numbers); -- set categorization for package
+     pragma Assert(Exists(File_Name),
+                   Message => "Nonexistent file"); -- assert file exists
+
+                        _Extensions to Ada 83_
+
+29.a
+          The Optimize pragma now allows the identifier Off to request
+          that normal optimization be turned off.
+
+29.b
+          An Optimize pragma may appear anywhere pragmas are allowed.
+
+                     _Wording Changes from Ada 83_
+
+29.c
+          We now describe the pragmas Page, List, and Optimize here, to
+          act as examples, and to remove the normative material from
+          *note Annex L::, "*note Annex L:: Language-Defined Pragmas",
+          so it can be entirely an informative annex.
+
+                     _Wording Changes from Ada 95_
+
+29.d/2
+          {AI95-00433-01AI95-00433-01} Updated the example of named
+          pragma parameters, because the second parameter of pragma
+          Suppress is obsolescent.
+
+                    _Wording Changes from Ada 2005_
+
+29.e/3
+          {AI05-0229-1AI05-0229-1} Updated the example of pragmas,
+          because both pragmas Inline and Import are obsolescent.
+
+
+File: aarm2012.info,  Node: 2.9,  Prev: 2.8,  Up: 2
+
+2.9 Reserved Words
+==================
+
+                               _Syntax_
+
+1/1
+     This paragraph was deleted.
+
+2/3
+     {AI95-00284-02AI95-00284-02} {AI95-00395-01AI95-00395-01}
+     {AI05-0091-1AI05-0091-1} The following are the reserved words.
+     Within a program, some or all of the letters of a reserved word may
+     be in upper case.
+
+2.a
+          Discussion: Reserved words have special meaning in the syntax.
+          In addition, certain reserved words are used as attribute
+          names.
+
+2.b
+          The syntactic category identifier no longer allows reserved
+          words.  We have added the few reserved words that are legal
+          explicitly to the syntax for attribute_reference.  Allowing
+          identifier to include reserved words has been a source of
+          confusion for some users, and differs from the way they are
+          treated in the C and Pascal language definitions.
+
+abort      else        new          return
+abs        elsif       not          reverse
+abstract   end         null
+accept     entry                    select
+access     exception   of           separate
+aliased    exit        or           some
+all                    others       subtype
+and        for         out          synchronized
+array      function    overriding
+at                                  tagged
+           generic     package      task
+begin      goto        pragma       terminate
+body                   private      then
+           if          procedure    type
+case       in          protected
+constant   interface                until
+           is          raise        use
+declare                range
+delay      limited     record       when
+delta      loop        rem          while
+digits                 renames      with
+do         mod         requeue
+                                    xor
+
+     NOTES
+
+3
+     7  The reserved words appear in lower case boldface in this
+     International Standard, except when used in the designator of an
+     attribute (see *note 4.1.4::).  Lower case boldface is also used
+     for a reserved word in a string_literal used as an operator_symbol.
+     This is merely a convention -- programs may be written in whatever
+     typeface is desired and available.
+
+                    _Incompatibilities With Ada 83_
+
+3.a
+          The following words are not reserved in Ada 83, but are
+          reserved in Ada 95: abstract, aliased, protected, requeue,
+          tagged, until.
+
+                     _Wording Changes from Ada 83_
+
+3.b/3
+          {AI05-0299-1AI05-0299-1} The subclause entitled "Allowed
+          Replacements of Characters" has been moved to *note Annex J::,
+          "*note Annex J:: Obsolescent Features".
+
+                    _Incompatibilities With Ada 95_
+
+3.c/2
+          {AI95-00284-02AI95-00284-02} The following words are not
+          reserved in Ada 95, but are reserved in Ada 2005: interface,
+          overriding, synchronized.  A special allowance is made for
+          pragma Interface (see *note J.12::).  Uses of these words as
+          identifiers will need to be changed, but we do not expect them
+          to be common.
+
+                     _Wording Changes from Ada 95_
+
+3.d/2
+          {AI95-00395-01AI95-00395-01} The definition of upper case
+          equivalence has been modified to allow identifiers using all
+          of the characters of ISO 10646.  This change has no effect on
+          the character sequences that are reserved words, but does make
+          some unusual sequences of characters illegal.
+
+                   _Incompatibilities With Ada 2005_
+
+3.e/3
+          {AI05-0091-1AI05-0091-1} Correction: Removed other_format
+          characters from reserved words in order to be compatible with
+          the latest Unicode recommendations.  This change can only
+          affect programs written for original Ada 2005, and there is
+          little reason to put other_format characters into reserved
+          words in the first place, so there should be very few such
+          programs.
+
+3.f/3
+          {AI05-0176-1AI05-0176-1} The following word is not reserved in
+          Ada 2005, but is reserved in Ada 2012: some.  Uses of this
+          word as an identifier will need to be changed, but we do not
+          expect them to be common.
+
+
+File: aarm2012.info,  Node: 3,  Next: 4,  Prev: 2,  Up: Top
+
+3 Declarations and Types
+************************
+
+1/3
+{AI05-0299-1AI05-0299-1} This clause describes the types in the language
+and the rules for declaring constants, variables, and named numbers.
+
+* Menu:
+
+* 3.1 ::      Declarations
+* 3.2 ::      Types and Subtypes
+* 3.3 ::      Objects and Named Numbers
+* 3.4 ::      Derived Types and Classes
+* 3.5 ::      Scalar Types
+* 3.6 ::      Array Types
+* 3.7 ::      Discriminants
+* 3.8 ::      Record Types
+* 3.9 ::      Tagged Types and Type Extensions
+* 3.10 ::     Access Types
+* 3.11 ::     Declarative Parts
+
+
+File: aarm2012.info,  Node: 3.1,  Next: 3.2,  Up: 3
+
+3.1 Declarations
+================
+
+1
+The language defines several kinds of named entities that are declared
+by declarations.  The entity's name is defined by the declaration,
+usually by a defining_identifier (*note 3.1: S0022.), but sometimes by a
+defining_character_literal (*note 3.5.1: S0040.) or
+defining_operator_symbol (*note 6.1: S0171.).
+
+2
+There are several forms of declaration.  A basic_declaration is a form
+of declaration defined as follows.
+
+                               _Syntax_
+
+3/3
+     {AI95-00348-01AI95-00348-01} {AI05-0177-1AI05-0177-1}
+     basic_declaration ::=
+          type_declaration   | subtype_declaration
+        | object_declaration   | number_declaration
+        | subprogram_declaration   | abstract_subprogram_declaration
+        | null_procedure_declaration   | expression_function_declaration
+        | package_declaration   | renaming_declaration
+        | exception_declaration   | generic_declaration
+        | generic_instantiation
+
+4
+     defining_identifier ::= identifier
+
+                          _Static Semantics_
+
+5
+A declaration is a language construct that associates a name with (a
+view of) an entity.  A declaration may appear explicitly in the program
+text (an explicit declaration), or may be supposed to occur at a given
+place in the text as a consequence of the semantics of another construct
+(an implicit declaration).
+
+5.a
+          Discussion: An implicit declaration generally declares a
+          predefined or inherited operation associated with the
+          definition of a type.  This term is used primarily when
+          allowing explicit declarations to override implicit
+          declarations, as part of a type declaration.
+
+6/3
+{AI95-00318-02AI95-00318-02} {AI05-0255-1AI05-0255-1}
+{AI05-0277-1AI05-0277-1} Each of the following is defined to be a
+declaration: any basic_declaration (*note 3.1: S0021.); an
+enumeration_literal_specification (*note 3.5.1: S0039.); a
+discriminant_specification (*note 3.7: S0062.); a component_declaration
+(*note 3.8: S0070.); a loop_parameter_specification (*note 5.5: S0158.);
+an iterator_specification (*note 5.5.2: S0159.); a
+parameter_specification (*note 6.1: S0175.); a subprogram_body (*note
+6.3: S0177.); an extended_return_object_declaration (*note 6.5: S0185.);
+an entry_declaration (*note 9.5.2: S0218.); an entry_index_specification
+(*note 9.5.2: S0224.); a choice_parameter_specification (*note 11.2:
+S0267.); a generic_formal_parameter_declaration (*note 12.1: S0274.).
+
+6.a
+          Discussion: This list (when basic_declaration is expanded out)
+          contains all syntactic categories that end in "_declaration"
+          or "_specification", except for program unit _specifications.
+          Moreover, it contains subprogram_body.  A subprogram_body is a
+          declaration, whether or not it completes a previous
+          declaration.  This is a bit strange, subprogram_body is not
+          part of the syntax of basic_declaration or
+          library_unit_declaration.  A renaming-as-body is considered a
+          declaration.  An accept_statement is not considered a
+          declaration.  Completions are sometimes declarations, and
+          sometimes not.
+
+7
+All declarations contain a definition for a view of an entity.  A view
+consists of an identification of the entity (the entity of the view),
+plus view-specific characteristics that affect the use of the entity
+through that view (such as mode of access to an object, formal parameter
+names and defaults for a subprogram, or visibility to components of a
+type).  In most cases, a declaration also contains the definition for
+the entity itself (a renaming_declaration is an example of a declaration
+that does not define a new entity, but instead defines a view of an
+existing entity (see *note 8.5::)).
+
+7.a/2
+          Glossary entry: A view of an entity reveals some or all of the
+          properties of the entity.  A single entity may have multiple
+          views.
+
+7.b
+          Discussion: Most declarations define a view (of some entity)
+          whose view-specific characteristics are unchanging for the
+          life of the view.  However, subtypes are somewhat unusual in
+          that they inherit characteristics from whatever view of their
+          type is currently visible.  Hence, a subtype is not a view of
+          a type; it is more of an indirect reference.  By contrast, a
+          private type provides a single, unchanging (partial) view of
+          its full type.
+
+7.1/3
+{AI05-0080-1AI05-0080-1} When it is clear from context, the term object
+is used in place of view of an object.  Similarly, the terms type and
+subtype are used in place of view of a type and view of a subtype,
+respectively.
+
+7.c/3
+          Discussion: Rules interpreted at compile time generally refer
+          to views of entities, rather than the entities themselves.
+          This is necessary to preserve privacy; characteristics that
+          are not visible should not be used in compile-time rules.
+          Thus, Static Semantics and Legality Rules generally implicitly
+          have "view of".  Legality Rules that need to look into the
+          private part are the exception to this interpretation.
+
+7.d/3
+          On the other hand, run-time rules can work either way, so
+          "view of" should not be assumed in Dynamic Semantics rules.
+
+8
+For each declaration, the language rules define a certain region of text
+called the scope of the declaration (see *note 8.2::).  Most
+declarations 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 declaration, the view it defines, and the
+associated entity; these places are defined by the visibility rules (see
+*note 8.3::).  At such places the identifier is said to be a name of the
+entity (the direct_name or selector_name); the name is said to denote
+the declaration, the view, and the associated entity (see *note 8.6::).
+The declaration is said to declare the name, the view, and in most
+cases, the entity itself.
+
+9
+As an alternative to an identifier, an enumeration literal can be
+declared with a character_literal as its name (see *note 3.5.1::), and a
+function can be declared with an operator_symbol as its name (see *note
+6.1::).
+
+10
+The syntax rules use the terms defining_identifier,
+defining_character_literal (*note 3.5.1: S0040.), and
+defining_operator_symbol (*note 6.1: S0171.) for the defining occurrence
+of a name; these are collectively called defining names.  The terms
+direct_name and selector_name are used for usage occurrences of
+identifiers, character_literals, and operator_symbols.  These are
+collectively called usage names.
+
+10.a
+          To be honest: The terms identifier, character_literal, and
+          operator_symbol are used directly in contexts where the normal
+          visibility rules do not apply (such as the identifier that
+          appears after the end of a task_body).  Analogous conventions
+          apply to the use of designator, which is the collective term
+          for identifier and operator_symbol.
+
+                          _Dynamic Semantics_
+
+11
+The process by which a construct achieves its run-time effect is called
+execution.  This process is also called elaboration for declarations and
+evaluation for expressions.  One of the terms execution, elaboration, or
+evaluation is defined by this International Standard for each construct
+that has a run-time effect.
+
+11.a
+          Glossary entry: The process by which a construct achieves its
+          run-time effect is called execution.  Execution of a
+          declaration is also called elaboration.  Execution of an
+          expression is also called evaluation.
+
+11.b
+          To be honest: The term elaboration is also used for the
+          execution of certain constructs that are not declarations, and
+          the term evaluation is used for the execution of certain
+          constructs that are not expressions.  For example,
+          subtype_indications are elaborated, and ranges are evaluated.
+
+11.c
+          For bodies, execution and elaboration are both explicitly
+          defined.  When we refer specifically to the execution of a
+          body, we mean the explicit definition of execution for that
+          kind of body, not its elaboration.
+
+11.d
+          Discussion: Technically, "the execution of a declaration" and
+          "the elaboration of a declaration" are synonymous.  We use the
+          term "elaboration" of a construct when we know the construct
+          is elaborable.  When we are talking about more arbitrary
+          constructs, we use the term "execution".  For example, we use
+          the term "erroneous execution", to refer to any erroneous
+          execution, including erroneous elaboration or evaluation.
+
+11.e
+          When we explicitly define evaluation or elaboration for a
+          construct, we are implicitly defining execution of that
+          construct.
+
+11.f
+          We also use the term "execution" for things like statements,
+          which are executable, but neither elaborable nor evaluable.
+          We considered using the term "execution" only for
+          nonelaborable, nonevaluable constructs, and defining the term
+          "action" to mean what we have defined "execution" to mean.  We
+          rejected this idea because we thought three terms that mean
+          the same thing was enough -- four would be overkill.  Thus,
+          the term "action" is used only informally in the standard
+          (except where it is defined as part of a larger term, such as
+          "protected action").
+
+11.f.1/2
+          Glossary entry: The process by which a declaration achieves
+          its run-time effect is called elaboration.  Elaboration is one
+          of the forms of execution.
+
+11.f.2/2
+          Glossary entry: The process by which an expression achieves
+          its run-time effect is called evaluation.  Evaluation is one
+          of the forms of execution.
+
+11.g
+          To be honest: A construct is elaborable if elaboration is
+          defined for it.  A construct is evaluable if evaluation is
+          defined for it.  A construct is executable if execution is
+          defined for it.
+
+11.h
+          Discussion: Don't confuse "elaborable" with "preelaborable"
+          (defined in *note 10.2.1::).
+
+11.i/2
+          {AI95-00114-01AI95-00114-01} Evaluation of an evaluable
+          construct produces a result that is either a value, a
+          denotation, or a range.  The following are evaluable:
+          expression; name prefix; range; entry_index_specification; and
+          possibly discrete_range.  The last one is curious -- RM83 uses
+          the term "evaluation of a discrete_range," but never defines
+          it.  One might presume that the evaluation of a discrete_range
+          consists of the evaluation of the range or the
+          subtype_indication, depending on what it is.  But
+          subtype_indications are not evaluated; they are elaborated.
+
+11.j
+          Intuitively, an executable construct is one that has a defined
+          run-time effect (which may be null).  Since execution includes
+          elaboration and evaluation as special cases, all elaborable
+          and all evaluable constructs are also executable.  Hence, most
+          constructs in Ada are executable.  An important exception is
+          that the constructs inside a generic unit are not executable
+          directly, but rather are used as a template for (generally)
+          executable constructs in instances of the generic.
+
+     NOTES
+
+12
+     1  At compile time, the declaration of an entity declares the
+     entity.  At run time, the elaboration of the declaration creates
+     the entity.
+
+12.a
+          Ramification: Syntactic categories for declarations are named
+          either entity_declaration (if they include a trailing
+          semicolon) or entity_specification (if not).
+
+12.b
+          The various kinds of named entities that can be declared are
+          as follows: an object (including components and parameters), a
+          named number, a type (the name always refers to its first
+          subtype), a subtype, a subprogram (including enumeration
+          literals and operators), a single entry, an entry family, a
+          package, a protected or task unit (which corresponds to either
+          a type or a single object), an exception, a generic unit, a
+          label, and the name of a statement.
+
+12.c
+          Identifiers are also associated with names of pragmas,
+          arguments to pragmas, and with attributes, but these are not
+          user-definable.
+
+                     _Wording Changes from Ada 83_
+
+12.d
+          The syntax rule for defining_identifier is new.  It is used
+          for the defining occurrence of an identifier.  Usage
+          occurrences use the direct_name or selector_name syntactic
+          categories.  Each occurrence of an identifier (or
+          simple_name), character_literal, or operator_symbol in the Ada
+          83 syntax rules is handled as follows in Ada 95:
+
+12.e
+             * It becomes a defining_identifier,
+               defining_character_literal, or defining_operator_symbol
+               (or some syntactic category composed of these), to
+               indicate a defining occurrence;
+
+12.f/3
+             * {AI05-0299-1AI05-0299-1} It becomes a direct_name, in
+               usage occurrences where the usage is required (in Clause
+               *note 8::) to be directly visible;
+
+12.g/3
+             * {AI05-0299-1AI05-0299-1} It becomes a selector_name, in
+               usage occurrences where the usage is required (in Clause
+               *note 8::) to be visible but not necessarily directly
+               visible;
+
+12.h
+             * It remains an identifier, character_literal, or
+               operator_symbol, in cases where the visibility rules do
+               not apply (such as the designator that appears after the
+               end of a subprogram_body).
+
+12.i
+          For declarations that come in "two parts" (program unit
+          declaration plus body, private or incomplete type plus full
+          type, deferred constant plus full constant), we consider both
+          to be defining occurrences.  Thus, for example, the syntax for
+          package_body uses defining_identifier after the reserved word
+          body, as opposed to direct_name.
+
+12.j
+          The defining occurrence of a statement name is in its implicit
+          declaration, not where it appears in the program text.
+          Considering the statement name itself to be the defining
+          occurrence would complicate the visibility rules.
+
+12.k
+          The phrase "visible by selection" is not used in Ada 95.  It
+          is subsumed by simply "visible" and the Name Resolution Rules
+          for selector_names.
+
+12.l/3
+          {AI05-0299-1AI05-0299-1} (Note that in Ada 95, a declaration
+          is visible at all places where one could have used a
+          selector_name, not just at places where a selector_name was
+          actually used.  Thus, the places where a declaration is
+          directly visible are a subset of the places where it is
+          visible.  See Clause *note 8:: for details.)
+
+12.m
+          We use the term "declaration" to cover _specifications that
+          declare (views of) objects, such as parameter_specifications.
+          In Ada 83, these are referred to as a "form of declaration,"
+          but it is not entirely clear that they are considered simply
+          "declarations."
+
+12.n/3
+          {AI05-0299-1AI05-0299-1} RM83 contains an incomplete
+          definition of "elaborated" in this subclause: it defines
+          "elaborated" for declarations, declarative_parts,
+          declarative_items and compilation_units, but "elaboration" is
+          defined elsewhere for various other constructs.  To make
+          matters worse, Ada 95 has a different set of elaborable
+          constructs.  Instead of correcting the list, it is more
+          maintainable to refer to the term "elaborable," which is
+          defined in a distributed manner.
+
+12.o
+          RM83 uses the term "has no other effect" to describe an
+          elaboration that doesn't do anything except change the state
+          from not-yet-elaborated to elaborated.  This was a confusing
+          wording, because the answer to "other than what?"  was to be
+          found many pages away.  In Ada 95, we change this wording to
+          "has no effect" (for things that truly do nothing at run
+          time), and "has no effect other than to establish that
+          so-and-so can happen without failing the Elaboration_Check"
+          (for things where it matters).
+
+12.p
+          We make it clearer that the term "execution" covers
+          elaboration and evaluation as special cases.  This was implied
+          in RM83.  For example, "erroneous execution" can include any
+          execution, and RM83-9.4(3) has, "The task designated by any
+          other task object depends on the master whose execution
+          creates the task object;" the elaboration of the master's
+          declarative_part is doing the task creation.
+
+                     _Wording Changes from Ada 95_
+
+12.q/2
+          {AI95-00318-02AI95-00318-02} Added extended_return_statement
+          to the list of declarations.
+
+12.r/2
+          {AI95-00348-01AI95-00348-01} Added null procedures (see *note
+          6.7::) to the syntax.
+
+                    _Wording Changes from Ada 2005_
+
+12.s/3
+          {AI05-0177-1AI05-0177-1} Added expression functions (see *note
+          6.8::) to the syntax.
+
+
+File: aarm2012.info,  Node: 3.2,  Next: 3.3,  Prev: 3.1,  Up: 3
+
+3.2 Types and Subtypes
+======================
+
+                          _Static Semantics_
+
+1
+A type is characterized by a set of values, and a set of primitive
+operations which implement the fundamental aspects of its semantics.  An
+object of a given type is a run-time entity that contains (has) a value
+of the type.
+
+1.a/2
+          Glossary entry: Each object has a type.  A type has an
+          associated set of values, and a set of primitive operations
+          which implement the fundamental aspects of its semantics.
+          Types are grouped into categories.  Most language-defined
+          categories of types are also classes of types.
+
+1.b/3
+          Glossary entry: A subtype is a type together with optional
+          constraints, null exclusions, and predicates, which constrain
+          the values of the subtype to satisfy certain conditions.  The
+          values of a subtype are a subset of the values of its type.
+
+2/2
+{AI95-00442-01AI95-00442-01} Types are grouped into categories of types.
+There exist several language-defined categories of types (see NOTES
+below), reflecting the similarity of their values and primitive
+operations.  [Most categories of types form classes of types.]
+Elementary types are those whose values are logically indivisible; 
+composite types are those whose values are composed of component values.
+
+2.a/2
+          Proof: {AI95-00442-01AI95-00442-01} The formal definition of
+          category and class is found in *note 3.4::.
+
+2.b/2
+          Glossary entry: A class is a set of types that is closed under
+          derivation, which means that if a given type is in the class,
+          then all types derived from that type are also in the class.
+          The set of types of a class share common properties, such as
+          their primitive operations.
+
+2.b.1/2
+          Glossary entry: A category of types is a set of types with one
+          or more common properties, such as primitive operations.  A
+          category of types that is closed under derivation is also
+          known as a class.
+
+2.c
+          Glossary entry: An elementary type does not have components.
+
+2.d/2
+          Glossary entry: A composite type may have components.
+
+2.e
+          Glossary entry: A scalar type is either a discrete type or a
+          real type.
+
+2.f
+          Glossary entry: An access type has values that designate
+          aliased objects.  Access types correspond to "pointer types"
+          or "reference types" in some other languages.
+
+2.g
+          Glossary entry: A discrete type is either an integer type or
+          an enumeration type.  Discrete types may be used, for example,
+          in case_statements and as array indices.
+
+2.h
+          Glossary entry: A real type has values that are approximations
+          of the real numbers.  Floating point and fixed point types are
+          real types.
+
+2.i
+          Glossary entry: Integer types comprise the signed integer
+          types and the modular types.  A signed integer type has a base
+          range that includes both positive and negative numbers, and
+          has operations that may raise an exception when the result is
+          outside the base range.  A modular type has a base range whose
+          lower bound is zero, and has operations with "wraparound"
+          semantics.  Modular types subsume what are called "unsigned
+          types" in some other languages.
+
+2.j
+          Glossary entry: An enumeration type is defined by an
+          enumeration of its values, which may be named by identifiers
+          or character literals.
+
+2.k
+          Glossary entry: A character type is an enumeration type whose
+          values include characters.
+
+2.l
+          Glossary entry: A record type is a composite type consisting
+          of zero or more named components, possibly of different types.
+
+2.m
+          Glossary entry: A record extension is a type that extends
+          another type by adding additional components.
+
+2.n
+          Glossary entry: An array type is a composite type whose
+          components are all of the same type.  Components are selected
+          by indexing.
+
+2.o/2
+          Glossary entry: A task type is a composite type used to
+          represent active entities which execute concurrently and which
+          can communicate via queued task entries.  The top-level task
+          of a partition is called the environment task.
+
+2.p/2
+          Glossary entry: A protected type is a composite type whose
+          components are accessible only through one of its protected
+          operations which synchronize concurrent access by multiple
+          tasks.
+
+2.q/2
+          Glossary entry: A private type gives a view of a type that
+          reveals only some of its properties.  The remaining properties
+          are provided by the full view given elsewhere.  Private types
+          can be used for defining abstractions that hide unnecessary
+          details from their clients.
+
+2.r/2
+          Glossary entry: A private extension is a type that extends
+          another type, with the additional properties hidden from its
+          clients.
+
+2.s/2
+          Glossary entry: An incomplete type gives a view of a type that
+          reveals only some of its properties.  The remaining properties
+          are provided by the full view given elsewhere.  Incomplete
+          types can be used for defining recursive data structures.
+
+3
+The elementary types are the scalar types (discrete and real) and the
+access types (whose values provide access to objects or subprograms).  
+Discrete types are either integer types or are defined by enumeration of
+their values (enumeration types).  Real types are either floating point
+types or fixed point types.
+
+4/2
+{AI95-00251-01AI95-00251-01} {AI95-00326-01AI95-00326-01} The composite
+types are the record types, record extensions, array types, interface
+types, task types, and protected types.
+
+4.a/2
+          This paragraph was deleted.{AI95-00442-01AI95-00442-01}
+
+4.1/2
+{AI95-00326-01AI95-00326-01} There can be multiple views of a type with
+varying sets of operations.  [An incomplete type represents an
+incomplete view (see *note 3.10.1::) of a type with a very restricted
+usage, providing support for recursive data structures.  A private type
+or private extension represents a partial view (see *note 7.3::) of a
+type, providing support for data abstraction.  The full view (see *note
+3.2.1::) of a type represents its complete definition.]  An incomplete
+or partial view is considered a composite type[, even if the full view
+is not].
+
+4.b/3
+          Proof: {AI05-0299-1AI05-0299-1} The real definitions of the
+          views are in the referenced subclauses.
+
+5/2
+{AI95-00326-01AI95-00326-01} Certain composite types (and views thereof)
+have special components called discriminants whose values affect the
+presence, constraints, or initialization of other components.
+Discriminants can be thought of as parameters of the type.
+
+6/2
+{AI95-00366-01AI95-00366-01} The term subcomponent is used in this
+International Standard in place of the term component to indicate either
+a component, or a component of another subcomponent.  Where other
+subcomponents are excluded, the term component is used instead.
+Similarly, a part of an object or value is used to mean the whole object
+or value, or any set of its subcomponents.  The terms component,
+subcomponent, and part are also applied to a type meaning the component,
+subcomponent, or part of objects and values of the type.
+
+6.a
+          Discussion: The definition of "part" here is designed to
+          simplify rules elsewhere.  By design, the intuitive meaning of
+          "part" will convey the correct result to the casual reader,
+          while this formalistic definition will answer the concern of
+          the compiler-writer.
+
+6.b
+          We use the term "part" when talking about the parent part,
+          ancestor part, or extension part of a type extension.  In
+          contexts such as these, the part might represent an empty set
+          of subcomponents (e.g.  in a null record extension, or a
+          nonnull extension of a null record).  We also use "part" when
+          specifying rules such as those that apply to an object with a
+          "controlled part" meaning that it applies if the object as a
+          whole is controlled, or any subcomponent is.
+
+7/2
+{AI95-00231-01AI95-00231-01} The set of possible values for an object of
+a given type can be subjected to a condition that is called a constraint
+(the case of a null constraint that specifies no restriction is also
+included)[; the rules for which values satisfy a given kind of
+constraint are given in *note 3.5:: for range_constraints, *note 3.6.1::
+for index_constraints, and *note 3.7.1:: for discriminant_constraints].
+The set of possible values for an object of an access type can also be
+subjected to a condition that excludes the null value (see *note
+3.10::).
+
+8/2
+{AI95-00231-01AI95-00231-01} {AI95-00415-01AI95-00415-01} A subtype of a
+given type is a combination of the type, a constraint on values of the
+type, and certain attributes specific to the subtype.  The given type is
+called the type of the subtype.  Similarly, the associated constraint is
+called the constraint of the subtype.   The set of values of a subtype
+consists of the values of its type that satisfy its constraint and any
+exclusion of the null value.  Such values belong to the subtype.  
+
+8.a
+          Discussion: We make a strong distinction between a type and
+          its subtypes.  In particular, a type is not a subtype of
+          itself.  There is no constraint associated with a type (not
+          even a null one), and type-related attributes are distinct
+          from subtype-specific attributes.
+
+8.b
+          Discussion: We no longer use the term "base type."  All types
+          were "base types" anyway in Ada 83, so the term was redundant,
+          and occasionally confusing.  In the RM95 we say simply "the
+          type of the subtype" instead of "the base type of the
+          subtype."
+
+8.c
+          Ramification: The value subset for a subtype might be empty,
+          and need not be a proper subset.
+
+8.d/2
+          To be honest: {AI95-00442-01AI95-00442-01} Any name of a
+          category of types (such as "discrete", "real", or "limited")
+          is also used to qualify its subtypes, as well as its objects,
+          values, declarations, and definitions, such as an "integer
+          type declaration" or an "integer value."  In addition, if a
+          term such as "parent subtype" or "index subtype" is defined,
+          then the corresponding term for the type of the subtype is
+          "parent type" or "index type."
+
+8.e
+          Discussion: We use these corresponding terms without
+          explicitly defining them, when the meaning is obvious.
+
+9
+A subtype is called an unconstrained subtype if its type has unknown
+discriminants, or if its type allows range, index, or discriminant
+constraints, but the subtype does not impose such a constraint;
+otherwise, the subtype is called a constrained subtype (since it has no
+unconstrained characteristics).
+
+9.a
+          Discussion: In an earlier version of Ada 9X, "constrained"
+          meant "has a nonnull constraint."  However, we changed to this
+          definition since we kept having to special case composite
+          non-array/nondiscriminated types.  It also corresponds better
+          to the (now obsolescent) attribute 'Constrained.
+
+9.b
+          For scalar types, "constrained" means "has a nonnull
+          constraint".  For composite types, in implementation terms,
+          "constrained" means that the size of all objects of the
+          subtype is the same, assuming a typical implementation model.
+
+9.c
+          Class-wide subtypes are always unconstrained.
+
+     NOTES
+
+10/2
+     2  {AI95-00442-01AI95-00442-01} Any set of types can be called a
+     "category" of types, and any set of types that is closed under
+     derivation (see *note 3.4::) can be called a "class" of types.
+     However, only certain categories and classes are used in the
+     description of the rules of the language -- generally those that
+     have their own particular set of primitive operations (see *note
+     3.2.3::), or that correspond to a set of types that are matched by
+     a given kind of generic formal type (see *note 12.5::).  The
+     following are examples of "interesting" language-defined classes:
+     elementary, scalar, discrete, enumeration, character, boolean,
+     integer, signed integer, modular, real, floating point, fixed
+     point, ordinary fixed point, decimal fixed point, numeric, access,
+     access-to-object, access-to-subprogram, composite, array, string,
+     (untagged) record, tagged, task, protected, nonlimited.  Special
+     syntax is provided to define types in each of these classes.  In
+     addition to these classes, the following are examples of
+     "interesting" language-defined categories: abstract, incomplete,
+     interface, limited, private, record.
+
+10.a
+          Discussion: A value is a run-time entity with a given type
+          which can be assigned to an object of an appropriate subtype
+          of the type.  An operation is a program entity that operates
+          on zero or more operands to produce an effect, or yield a
+          result, or both.
+
+10.b/2
+          Ramification: {AI95-00442-01AI95-00442-01} Note that a type's
+          category (and class) depends on the place of the reference --
+          a private type is composite outside and possibly elementary
+          inside.  It's really the view that is elementary or composite.
+          Note that although private types are composite, there are some
+          properties that depend on the corresponding full view -- for
+          example, parameter passing modes, and the constraint checks
+          that apply in various places.
+
+10.c/2
+          {AI95-00345-01AI95-00345-01} {AI95-00442-01AI95-00442-01}
+          Every property of types forms a category, but not every
+          property of types represents a class.  For example, the set of
+          all abstract types does not form a class, because this set is
+          not closed under derivation.  Similarly, the set of all
+          interface types does not form a class.
+
+10.d/2
+          {AI95-00442-01AI95-00442-01} The set of limited types does not
+          form a class (since nonlimited types can inherit from limited
+          interfaces), but the set of nonlimited types does.  The set of
+          tagged record types and the set of tagged private types do not
+          form a class (because each of them can be extended to create a
+          type of the other category); that implies that the set of
+          record types and the set of private types also do not form a
+          class (even though untagged record types and untagged private
+          types do form a class).  In all of these cases, we can talk
+          about the category of the type; for instance, we can talk
+          about the "category of limited types"..
+
+10.e/2
+          {AI95-00442-01AI95-00442-01} Normatively, the language-defined
+          classes are those that are defined to be inherited on
+          derivation by *note 3.4::; other properties either aren't
+          interesting or form categories, not classes.
+
+11/2
+     {AI95-00442-01AI95-00442-01} These language-defined categories are
+     organized like this:
+
+12/2
+          {AI95-00345-01AI95-00345-01} all types
+             elementary
+                scalar
+                   discrete
+                      enumeration
+                         character
+                         boolean
+                         other enumeration
+                      integer
+                         signed integer
+                         modular integer
+                   real
+                      floating point
+                      fixed point
+                         ordinary fixed point
+                         decimal fixed point
+                access
+                   access-to-object
+                   access-to-subprogram
+             composite
+                untagged
+                   array
+                      string
+                      other array
+                   record
+                   task
+                   protected
+                tagged (including interfaces)
+                   nonlimited tagged record
+                   limited tagged
+                      limited tagged record
+                      synchronized tagged
+                         tagged task
+                         tagged protected
+
+13/2
+     {AI95-00345-01AI95-00345-01} {AI95-00442-01AI95-00442-01} There are
+     other categories, such as "numeric" and "discriminated", which
+     represent other categorization dimensions, but do not fit into the
+     above strictly hierarchical picture.
+
+13.a.1/2
+          Discussion: {AI95-00345-01AI95-00345-01}
+          {AI95-00442-01AI95-00442-01} Note that this is also true for
+          some categories mentioned in the chart.  The category "task"
+          includes both untagged tasks and tagged tasks.  Similarly for
+          "protected", "limited", and "nonlimited" (note that limited
+          and nonlimited are not shown for untagged composite types).
+
+                     _Wording Changes from Ada 83_
+
+13.a/3
+          {AI05-0299-1AI05-0299-1} This subclause now precedes the
+          subclauses on objects and named numbers, to cut down on the
+          number of forward references.
+
+13.b
+          We have dropped the term "base type" in favor of simply "type"
+          (all types in Ada 83 were "base types" so it wasn't clear when
+          it was appropriate/necessary to say "base type").  Given a
+          subtype S of a type T, we call T the "type of the subtype S."
+
+                     _Wording Changes from Ada 95_
+
+13.c/2
+          {AI95-00231-01AI95-00231-01} Added a mention of null
+          exclusions when we're talking about constraints (these are not
+          constraints, but they are similar).
+
+13.d/2
+          {AI95-00251-01AI95-00251-01} Defined an interface type to be a
+          composite type.
+
+13.e/2
+          {AI95-00326-01AI95-00326-01} Revised the wording so that it is
+          clear that an incomplete view is similar to a partial view in
+          terms of the language.
+
+13.f/2
+          {AI95-00366-01AI95-00366-01} Added a definition of component
+          of a type, subcomponent of a type, and part of a type.  These
+          are commonly used in the standard, but they were not
+          previously defined.
+
+13.g/3
+          {AI95-00442-01AI95-00442-01} {AI05-0299-1AI05-0299-1} Reworded
+          most of this subclause to use category rather than class,
+          since so many interesting properties are not, strictly
+          speaking, classes.  Moreover, there was no normative
+          description of exactly which properties formed classes, and
+          which did not.  The real definition of class, along with a
+          list of properties, is now in *note 3.4::.
+
+* Menu:
+
+* 3.2.1 ::    Type Declarations
+* 3.2.2 ::    Subtype Declarations
+* 3.2.3 ::    Classification of Operations
+* 3.2.4 ::    Subtype Predicates
+
+
+File: aarm2012.info,  Node: 3.2.1,  Next: 3.2.2,  Up: 3.2
+
+3.2.1 Type Declarations
+-----------------------
+
+1
+A type_declaration declares a type and its first subtype.
+
+                               _Syntax_
+
+2
+     type_declaration ::=  full_type_declaration
+        | incomplete_type_declaration
+        | private_type_declaration
+        | private_extension_declaration
+
+3/3
+     {AI05-0183-1AI05-0183-1} full_type_declaration ::=
+          type defining_identifier [known_discriminant_part] is 
+     type_definition
+             [aspect_specification];
+        | task_type_declaration
+        | protected_type_declaration
+
+4/2
+     {AI95-00251-01AI95-00251-01} type_definition ::=
+          enumeration_type_definition   | integer_type_definition
+        | real_type_definition   | array_type_definition
+        | record_type_definition   | access_type_definition
+        | derived_type_definition   | interface_type_definition
+
+                           _Legality Rules_
+
+5
+A given type shall not have a subcomponent whose type is the given type
+itself.
+
+                          _Static Semantics_
+
+6
+The defining_identifier (*note 3.1: S0022.) of a type_declaration (*note
+3.2.1: S0023.) denotes the first subtype of the type.  The
+known_discriminant_part (*note 3.7: S0061.), if any, defines the
+discriminants of the type (see *note 3.7::, "*note 3.7::
+Discriminants").  The remainder of the type_declaration (*note 3.2.1:
+S0023.) defines the remaining characteristics of (the view of) the type.
+
+7/2
+{AI95-00230-01AI95-00230-01} A type defined by a type_declaration (*note
+3.2.1: S0023.) is a named type; such a type has one or more nameable
+subtypes.  Certain other forms of declaration also include type
+definitions as part of the declaration for an object.  The type defined
+by such a declaration is anonymous -- it has no nameable subtypes.  For
+explanatory purposes, this International Standard 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.
+For a named type whose first subtype is T, this International Standard
+sometimes refers to the type of T as simply "the type T".
+
+7.a/2
+          Ramification: {AI95-00230-01AI95-00230-01} The only
+          user-defined types that can be anonymous in the above sense
+          are array, access, task, and protected types.  An anonymous
+          array, task, or protected type can be defined as part of an
+          object_declaration.  An anonymous access type can be defined
+          as part of numerous other constructs.
+
+8/2
+{AI95-00230-01AI95-00230-01} {AI95-00326-01AI95-00326-01} A named type
+that is declared by a full_type_declaration (*note 3.2.1: S0024.), or an
+anonymous type that is defined by an access_definition or as part of
+declaring an object of the type, is called a full type.  The declaration
+of a full type also declares the full view of the type.  The
+type_definition (*note 3.2.1: S0025.), task_definition (*note 9.1:
+S0207.), protected_definition (*note 9.4: S0212.), or access_definition
+(*note 3.10: S0084.) that defines a full type is called a full type
+definition.  [Types declared by other forms of type_declaration (*note
+3.2.1: S0023.) are not separate types; they are partial or incomplete
+views of some full type.]
+
+8.a
+          To be honest: Class-wide, universal, and root numeric types
+          are full types.
+
+8.b/2
+          Reason: {AI95-00230-01AI95-00230-01} We need to mention
+          access_definition separately, as it may occur in renames,
+          which do not declare objects.
+
+9
+The definition of a type implicitly declares certain predefined
+operators that operate on the type, according to what classes the type
+belongs, as specified in *note 4.5::, "*note 4.5:: Operators and
+Expression Evaluation".
+
+9.a
+          Discussion: We no longer talk about the implicit declaration
+          of basic operations.  These are treated like an if_statement
+          -- they don't need to be declared, but are still applicable to
+          only certain classes of types.
+
+10
+The predefined types [(for example the types Boolean, Wide_Character,
+Integer, root_integer, and universal_integer)] are the types that are
+defined in [a predefined library package called] Standard[; this package
+also includes the [(implicit)] declarations of their predefined
+operators].  [The package Standard is described in *note A.1::.]
+
+10.a
+          Ramification: We use the term "predefined" to refer to
+          entities declared in the visible part of Standard, to
+          implicitly declared operators of a type whose semantics are
+          defined by the language, to Standard itself, and to the
+          "predefined environment".  We do not use this term to refer to
+          library packages other than Standard.  For example Text_IO is
+          a language-defined package, not a predefined package, and
+          Text_IO.Put_Line is not a predefined operation.
+
+                          _Dynamic Semantics_
+
+11
+The elaboration of a full_type_declaration consists of the elaboration
+of the full type definition.  Each elaboration of a full type definition
+creates a distinct type and its first subtype.
+
+11.a
+          Reason: The creation is associated with the type definition,
+          rather than the type declaration, because there are types that
+          are created by full type definitions that are not immediately
+          contained within a type declaration (e.g.  an array object
+          declaration, a singleton task declaration, etc.).
+
+11.b
+          Ramification: Any implicit declarations that occur immediately
+          following the full type definition are elaborated where they
+          (implicitly) occur.
+
+                              _Examples_
+
+12
+Examples of type definitions:
+
+13
+     (White, Red, Yellow, Green, Blue, Brown, Black)
+     range 1 .. 72
+     array(1 .. 10) of Integer
+
+14
+Examples of type declarations:
+
+15
+     type Color  is (White, Red, Yellow, Green, Blue, Brown, Black);
+     type Column is range 1 .. 72;
+     type Table  is array(1 .. 10) of Integer;
+
+     NOTES
+
+16
+     3  Each of the above examples declares a named type.  The
+     identifier given denotes the first subtype of the type.  Other
+     named subtypes of the type can be declared with
+     subtype_declarations (see *note 3.2.2::).  Although names do not
+     directly denote types, a phrase like "the type Column" is sometimes
+     used in this International Standard to refer to the type of Column,
+     where Column denotes the first subtype of the type.  For an example
+     of the definition of an anonymous type, see the declaration of the
+     array Color_Table in *note 3.3.1::; its type is anonymous -- it has
+     no nameable subtypes.
+
+                     _Wording Changes from Ada 83_
+
+16.a
+          The syntactic category full_type_declaration now includes task
+          and protected type declarations.
+
+16.b/3
+          {AI05-0299-1AI05-0299-1} We have generalized the concept of
+          first-named subtype (now called simply "first subtype") to
+          cover all kinds of types, for uniformity of description
+          elsewhere.  RM83 defined first-named subtype in Section 13.
+          We define first subtype here, because it is now a more
+          fundamental concept.  We renamed the term, because in Ada 95
+          some first subtypes have no name.
+
+16.c/2
+          {AI95-00230-01AI95-00230-01} We no longer elaborate
+          discriminant_parts, because there is nothing to do, and it was
+          complex to say that you only wanted to elaborate it once for a
+          private or incomplete type.  This is also consistent with the
+          fact that subprogram specifications are not elaborated
+          (neither in Ada 83 nor in Ada 95).  Note, however, that an
+          access_definition appearing in a discriminant_part is
+          elaborated at the full_type_declaration (for a nonlimited
+          type) or when an object with such a discriminant is created
+          (for a limited type).
+
+                     _Wording Changes from Ada 95_
+
+16.d/2
+          {AI95-00230-01AI95-00230-01} Added wording so that anonymous
+          access types are always full types, even if they appear in
+          renames.
+
+16.e/2
+          {AI95-00251-01AI95-00251-01} Added interface types (see *note
+          3.9.4::) to the syntax.
+
+16.f/2
+          {AI95-00326-01AI95-00326-01} Added a definition of full view,
+          so that all types have a well-defined full view.
+
+                       _Extensions to Ada 2005_
+
+16.g/3
+          {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+          be used in a full_type_declaration.  This is described in
+          *note 13.1.1::.
+
+
+File: aarm2012.info,  Node: 3.2.2,  Next: 3.2.3,  Prev: 3.2.1,  Up: 3.2
+
+3.2.2 Subtype Declarations
+--------------------------
+
+1
+A subtype_declaration declares a subtype of some previously declared
+type, as defined by a subtype_indication.
+
+                               _Syntax_
+
+2/3
+     {AI05-0183-1AI05-0183-1} subtype_declaration ::=
+        subtype defining_identifier is subtype_indication
+             [aspect_specification];
+
+3/2
+     {AI95-00231-01AI95-00231-01} subtype_indication ::=  [
+     null_exclusion] subtype_mark [constraint]
+
+4
+     subtype_mark ::= subtype_name
+
+4.a
+          Ramification: Note that name includes attribute_reference;
+          thus, S'Base can be used as a subtype_mark.
+
+4.b
+          Reason: We considered changing subtype_mark to subtype_name.
+          However, existing users are used to the word "mark," so we're
+          keeping it.
+
+5
+     constraint ::= scalar_constraint | composite_constraint
+
+6
+     scalar_constraint ::=
+          range_constraint | digits_constraint | delta_constraint
+
+7
+     composite_constraint ::=
+          index_constraint | discriminant_constraint
+
+                        _Name Resolution Rules_
+
+8
+A subtype_mark shall resolve to denote a subtype.  The type determined
+by a subtype_mark is the type of the subtype denoted by the
+subtype_mark.
+
+8.a/3
+          Ramification: {AI05-0005-1AI05-0005-1} Types are never
+          directly named; all subtype_marks denote subtypes -- possibly
+          an unconstrained (base) subtype, but never the type.  When we
+          use the term anonymous type we really mean a type with no
+          nameable subtypes.
+
+                          _Dynamic Semantics_
+
+9
+The elaboration of a subtype_declaration consists of the elaboration of
+the subtype_indication.  The elaboration of a subtype_indication creates
+a new subtype.  If the subtype_indication does not include a constraint,
+the new subtype has the same (possibly null) constraint as that denoted
+by the subtype_mark.  The elaboration of a subtype_indication that
+includes a constraint proceeds as follows:
+
+10
+   * The constraint is first elaborated.
+
+11
+   * A check is then made that the constraint is compatible with the
+     subtype denoted by the subtype_mark.
+
+11.a
+          Ramification: The checks associated with constraint
+          compatibility are all Range_Checks.  Discriminant_Checks and
+          Index_Checks are associated only with checks that a value
+          satisfies a constraint.
+
+12
+The condition imposed by a constraint is the condition obtained after
+elaboration of the constraint.  The rules defining compatibility are
+given for each form of constraint in the appropriate subclause.  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.
+
+12.a
+          To be honest: The condition imposed by a constraint is named
+          after it -- a range_constraint imposes a range constraint,
+          etc.
+
+12.b
+          Ramification: A range_constraint causes freezing of its type.
+          Other constraints do not.
+
+     NOTES
+
+13
+     4  A scalar_constraint may be applied to a subtype of an
+     appropriate scalar type (see *note 3.5::, *note 3.5.9::, and *note
+     J.3::), even if the subtype is already constrained.  On the other
+     hand, a composite_constraint may be applied to a composite subtype
+     (or an access-to-composite subtype) only if the composite subtype
+     is unconstrained (see *note 3.6.1:: and *note 3.7.1::).
+
+                              _Examples_
+
+14
+Examples of subtype declarations:
+
+15/2
+     {AI95-00433-01AI95-00433-01} subtype Rainbow   is Color range Red .. 
Blue;        --  see *note 3.2.1::
+     subtype Red_Blue  is Rainbow;
+     subtype Int       is Integer;
+     subtype Small_Int is Integer range -10 .. 10;
+     subtype Up_To_K   is Column range 1 .. K;            --  see *note 3.2.1::
+     subtype Square    is Matrix(1 .. 10, 1 .. 10);       --  see *note 3.6::
+     subtype Male      is Person(Sex => M);               --  see *note 
3.10.1::
+     subtype Binop_Ref is not null Binop_Ptr;             --  see *note 3.10::
+
+                    _Incompatibilities With Ada 83_
+
+15.a
+          In Ada 95, all range_constraints cause freezing of their type.
+          Hence, a type-related representation item for a scalar type
+          has to precede any range_constraints whose type is the scalar
+          type.
+
+                     _Wording Changes from Ada 83_
+
+15.b
+          Subtype_marks allow only subtype names now, since types are
+          never directly named.  There is no need for RM83-3.3.2(3),
+          which says a subtype_mark can denote both the type and the
+          subtype; in Ada 95, you denote an unconstrained (base) subtype
+          if you want, but never the type.
+
+15.c
+          The syntactic category type_mark is now called subtype_mark,
+          since it always denotes a subtype.
+
+                        _Extensions to Ada 95_
+
+15.d/2
+          {AI95-00231-01AI95-00231-01} An optional null_exclusion can be
+          used in a subtype_indication.  This is described in *note
+          3.10::.
+
+                       _Extensions to Ada 2005_
+
+15.e/3
+          {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+          be used in a subtype_declaration.  This is described in *note
+          13.1.1::.
+
+
+File: aarm2012.info,  Node: 3.2.3,  Next: 3.2.4,  Prev: 3.2.2,  Up: 3.2
+
+3.2.3 Classification of Operations
+----------------------------------
+
+                          _Static Semantics_
+
+1/2
+{AI95-00416-01AI95-00416-01} An operation operates on a type T if it
+yields a value of type T, if it has an operand whose expected type (see
+*note 8.6::) is T, or if it has an access parameter or access result
+type (see *note 6.1::) designating T. A predefined operator, or other
+language-defined operation such as assignment or a membership test, that
+operates on a type, is called a predefined operation of the type.  The
+primitive operations of a type are the predefined operations of the
+type, plus any user-defined primitive subprograms.
+
+1.a
+          Glossary entry: The primitive operations of a type are the
+          operations (such as subprograms) declared together with the
+          type declaration.  They are inherited by other types in the
+          same class of types.  For a tagged type, the primitive
+          subprograms are dispatching subprograms, providing run-time
+          polymorphism.  A dispatching subprogram may be called with
+          statically tagged operands, in which case the subprogram body
+          invoked is determined at compile time.  Alternatively, a
+          dispatching subprogram may be called using a dispatching call,
+          in which case the subprogram body invoked is determined at run
+          time.
+
+1.b
+          To be honest: Protected subprograms are not considered to be
+          "primitive subprograms," even though they are subprograms, and
+          they are inherited by derived types.
+
+1.c
+          Discussion: We use the term "primitive subprogram" in most of
+          the rest of the manual.  The term "primitive operation" is
+          used mostly in conceptual discussions.
+
+2
+The primitive subprograms of a specific type are defined as follows:
+
+3
+   * The predefined operators of the type (see *note 4.5::);
+
+4
+   * For a derived type, the inherited (see *note 3.4::) user-defined
+     subprograms;
+
+5
+   * For an enumeration type, the enumeration literals (which are
+     considered parameterless functions -- see *note 3.5.1::);
+
+6
+   * For a specific type declared immediately within a
+     package_specification, any subprograms (in addition to the
+     enumeration literals) that are explicitly declared immediately
+     within the same package_specification and that operate on the type;
+
+6.1/3
+   * {AI05-0128-1AI05-0128-1} For a specific type with an explicitly
+     declared primitive "=" operator whose result type is Boolean, the
+     corresponding "/=" operator (see *note 6.6::);
+
+7/2
+   * {AI95-00200-01AI95-00200-01} For a nonformal type, any subprograms
+     not covered above [that are explicitly declared immediately within
+     the same declarative region as the type] and that override (see
+     *note 8.3::) other implicitly declared primitive subprograms of the
+     type.
+
+7.a
+          Discussion: In Ada 83, only subprograms declared in the
+          visible part were "primitive" (i.e.  derivable).  In Ada 95,
+          mostly because of child library units, we include all
+          operations declared in the private part as well, and all
+          operations that override implicit declarations.
+
+7.b
+          Ramification: It is possible for a subprogram to be primitive
+          for more than one type, though it is illegal for a subprogram
+          to be primitive for more than one tagged type.  See *note
+          3.9::.
+
+7.c
+          Discussion: The order of the implicit declarations when there
+          are both predefined operators and inherited subprograms is
+          described in *note 3.4::, "*note 3.4:: Derived Types and
+          Classes".
+
+7.d/2
+          Ramification: {AI95-00200-01AI95-00200-01} Subprograms
+          declared in a generic package specification are never
+          primitive for a formal type, even if they happen to override
+          an operation of the formal type.  This includes formal
+          subprograms, which are never primitive operations (that's true
+          even for an abstract formal subprogram).
+
+8
+A primitive subprogram whose designator is an operator_symbol is called
+a primitive operator.
+
+                    _Incompatibilities With Ada 83_
+
+8.a
+          The attribute S'Base is no longer defined for nonscalar
+          subtypes.  Since this was only permitted as the prefix of
+          another attribute, and there are no interesting nonscalar
+          attributes defined for an unconstrained composite or access
+          subtype, this should not affect any existing programs.
+
+                        _Extensions to Ada 83_
+
+8.b
+          The primitive subprograms (derivable subprograms) include
+          subprograms declared in the private part of a package
+          specification as well, and those that override implicitly
+          declared subprograms, even if declared in a body.
+
+                     _Wording Changes from Ada 83_
+
+8.c
+          We have dropped the confusing term operation of a type in
+          favor of the more useful primitive operation of a type and the
+          phrase operates on a type.
+
+8.d
+          The description of S'Base has been moved to *note 3.5::,
+          "*note 3.5:: Scalar Types" because it is now defined only for
+          scalar types.
+
+                     _Wording Changes from Ada 95_
+
+8.e/2
+          {AI95-00200-01AI95-00200-01} Clarified that a formal
+          subprogram that happens to override a primitive operation of a
+          formal type is not a primitive operation (and thus not a
+          dispatching operation) of the formal type.
+
+8.f/2
+          {AI95-00416-01AI95-00416-01} Added wording to include access
+          result types in the kinds of operations that operate on a type
+          T.
+
+                    _Wording Changes from Ada 2005_
+
+8.g/3
+          {AI05-0128-1AI05-0128-1} Correction: The implicitly declared
+          "/=" for a primitive "=" operator is also primitive; this
+          makes it eligible to be made visible by a use type clause.
+
+
+File: aarm2012.info,  Node: 3.2.4,  Prev: 3.2.3,  Up: 3.2
+
+3.2.4 Subtype Predicates
+------------------------
+
+1/3
+{AI05-0153-3AI05-0153-3} {AI05-0269-1AI05-0269-1}
+{AI05-0299-1AI05-0299-1} The language-defined predicate aspects
+Static_Predicate and Dynamic_Predicate may be used to define properties
+of subtypes.  A predicate specification is an aspect_specification for
+one of the two predicate aspects.  General rules for aspects and
+aspect_specifications are found in Clause *note 13:: (*note 13.1:: and
+*note 13.1.1:: respectively).
+
+1.a/3
+          Aspect Description for Static_Predicate: Condition that must
+          hold true for objects of a given subtype; the subtype may be
+          static.
+
+1.b/3
+          Aspect Description for Dynamic_Predicate: Condition that must
+          hold true for objects of a given subtype; the subtype is not
+          static.
+
+                        _Name Resolution Rules_
+
+2/3
+{AI05-0153-3AI05-0153-3} The expected type for a predicate aspect
+expression is any boolean type.
+
+                          _Static Semantics_
+
+3/3
+{AI05-0153-3AI05-0153-3} A predicate specification may be given on a
+type_declaration or a subtype_declaration, and applies to the declared
+subtype.  In addition, predicate specifications apply to certain other
+subtypes:
+
+4/3
+   * For a (first) subtype defined by a derived type declaration, the
+     predicates of the parent subtype and the progenitor subtypes apply.
+
+5/3
+   * For a subtype created by a subtype_indication, the predicate of the
+     subtype denoted by the subtype_mark applies.
+
+6/3
+{AI05-0153-3AI05-0153-3} The predicate of a subtype consists of all
+predicate specifications that apply, and-ed together; if no predicate
+specifications apply, the predicate is True [(in particular, the
+predicate of a base subtype is True)].
+
+7/3
+{AI05-0290-1AI05-0290-1} Predicate checks are defined to be enabled or
+disabled for a given subtype as follows:
+
+8/3
+   * If a subtype is declared by a type_declaration or
+     subtype_declaration that includes a predicate specification, then:
+
+9/3
+        * if performing checks is required by the Static_Predicate
+          assertion policy (see *note 11.4.2::) and the declaration
+          includes a Static_Predicate specification, then predicate
+          checks are enabled for the subtype;
+
+10/3
+        * if performing checks is required by the Dynamic_Predicate
+          assertion policy (see *note 11.4.2::) and the declaration
+          includes a Dynamic_Predicate specification, then predicate
+          checks are enabled for the subtype;
+
+11/3
+        * otherwise, predicate checks are disabled for the subtype[,
+          regardless of whether predicate checking is enabled for any
+          other subtypes mentioned in the declaration];
+
+12/3
+   * If a subtype is defined by a derived type declaration that does not
+     include a predicate specification, then predicate checks are
+     enabled for the subtype if and only if predicate checks are enabled
+     for at least one of the parent subtype and the progenitor subtypes;
+
+13/3
+   * If a subtype is created by a subtype_indication other than in one
+     of the previous cases, then predicate checks are enabled for the
+     subtype if and only if predicate checks are enabled for the subtype
+     denoted by the subtype_mark;
+
+14/3
+   * Otherwise, predicate checks are disabled for the given subtype.
+
+14.a/3
+          Discussion: In this case, no predicate specifications can
+          apply to the subtype and so it doesn't typically matter
+          whether predicate checks are enabled.  This rule does make a
+          difference, however, when determining whether predicate checks
+          are enabled for another type when this type is one of multiple
+          progenitors.  See the "derived type declaration" wording
+          above.
+
+14.b/3
+          Even when predicate checks are disabled, a predicate cam
+          affect various Legality Rules, the results of membership
+          tests, the items in a for loop, and the result of the Valid
+          attribute.
+
+                           _Legality Rules_
+
+15/3
+{AI05-0153-3AI05-0153-3} {AI05-0269-1AI05-0269-1} The expression of a
+Static_Predicate specification shall be predicate-static; that is, one
+of the following:
+
+16/3
+   * a static expression;
+
+17/3
+   * a membership test whose simple_expression is the current instance,
+     and whose membership_choice_list meets the requirements for a
+     static membership test (see *note 4.9::);
+
+18/3
+   * a case_expression whose selecting_expression is the current
+     instance, and whose dependent_expressions are static expressions;
+
+19/3
+   * a call to a predefined equality or ordering operator, where one
+     operand is the current instance, and the other is a static
+     expression;
+
+20/3
+   * {AI05-0262-1AI05-0262-1} a call to a predefined boolean logical
+     operator, where each operand is predicate-static;
+
+21/3
+   * {AI05-0269-1AI05-0269-1} a short-circuit control form where both
+     operands are predicate-static; or
+
+22/3
+   * a parenthesized predicate-static expression.
+
+23/3
+{AI05-0262-1AI05-0262-1} A predicate shall not be specified for an
+incomplete subtype.
+
+23.a/3
+          Reason: The expression of such a predicate could not depend on
+          the properties of the value of the type (since it doesn't have
+          any), so it is useless and we don't want to require the added
+          complexity needed to support it.
+
+24/3
+{AI05-0287-1AI05-0287-1} If a predicate applies to a subtype, then that
+predicate shall not mention any other subtype to which the same
+predicate applies.
+
+24.a/3
+          Reason: This is intended to prevent recursive predicates,
+          which cause definitional problems for static predicates.
+          Inside of the predicate, the subtype name refers to the
+          current instance of the subtype, which is an object, so a
+          direct use of the subtype name cannot be recursive.  But other
+          subtypes naming the same type might:
+
+24.b/3
+                  type Really_Ugly is private;
+               private
+                  subtype Ugly is Really_Ugly;
+                  type Really_Ugly is new Integer
+                     with Static_Predicate => Really_Ugly not in Ugly; -- 
Illegal!
+
+25/3
+{AI05-0153-3AI05-0153-3} An index subtype, discrete_range of an
+index_constraint or slice, or a discrete_subtype_definition of a
+constrained_array_definition, entry_declaration, or
+entry_index_specification shall not denote a subtype to which predicate
+specifications apply.
+
+26/3
+{AI05-0153-3AI05-0153-3} The prefix of an attribute_reference whose
+attribute_designator is First, Last, or Range shall not denote a scalar
+subtype to which predicate specifications apply.
+
+26.a/3
+          Reason: {AI05-0297-1AI05-0297-1} This is to prevent confusion
+          about whether the First value is the lowest value of the
+          subtype (which does not depend on the predicate) or the lowest
+          value of the subtype which meets the predicate.  (For a
+          dynamic predicate, determining this latter value is expensive
+          as it would usually require a loop.)  For a static subtype
+          that has a static predicate, the First_Valid and Last_Valid
+          attributes (see *note 3.5.5::) can be used instead.
+
+27/3
+{AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1}
+{AI05-0287-1AI05-0287-1} The discrete_subtype_definition of a
+loop_parameter_specification shall not denote a nonstatic subtype to
+which predicate specifications apply or any subtype to which
+Dynamic_Predicate specifications apply.
+
+28/3
+{AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1} The discrete_choice of
+a named_array_aggregate shall not denote a nonstatic subtype to which
+predicate specifications apply.
+
+28.a/3
+          Reason: {AI05-0262-1AI05-0262-1} This rule prevents
+          noncontiguous dynamically bounded array aggregates, which
+          could be expensive to check for.  (Array aggregates have rules
+          to prevent problems with static subtypes.)  We define this
+          rule here so that the runtime generic body check applies.
+
+29/3
+{AI05-0262-1AI05-0262-1} In addition to the places where Legality Rules
+normally apply (see *note 12.3::), these rules apply also in the private
+part of an instance of a generic unit.
+
+                          _Dynamic Semantics_
+
+30/3
+{AI05-0153-3AI05-0153-3} {AI05-0290-1AI05-0290-1} If predicate checks
+are enabled for a given subtype, then:
+
+31/3
+          [On every subtype conversion, the predicate of the target
+          subtype is evaluated, and a check is performed that the
+          predicate is True.  This includes all parameter passing,
+          except for certain parameters passed by reference, which are
+          covered by the following rule: ] After normal completion and
+          leaving of a subprogram, for each in out or out parameter that
+          is passed by reference, the predicate of the subtype of the
+          actual is evaluated, and a check is performed that the
+          predicate is True.  For an object created by an
+          object_declaration with no explicit initialization expression,
+          or by an uninitialized allocator, if any subcomponents have
+          default_expressions, the predicate of the nominal subtype of
+          the created object is evaluated, and a check is performed that
+          the predicate is True.  Assertions.Assertion_Error is raised
+          if any of these checks fail.
+
+31.a/3
+          Ramification: Predicates are not evaluated at the point of the
+          (sub)type declaration.
+
+31.b/3
+          Implementation Note: Static_Predicate checks can be removed
+          even in the presence of potentially invalid values, just as
+          constraint checks can be removed.
+
+32/3
+{AI05-0262-1AI05-0262-1} A value satisfies a predicate if the predicate
+is True for that value.
+
+33/3
+{AI05-0153-3AI05-0153-3} {AI05-0276-1AI05-0276-1} If any of the above
+Legality Rules is violated in an instance of a generic unit,
+Program_Error is raised at the point of the violation.
+
+33.a/3
+          Discussion: This is the usual way around the contract model;
+          this applies even in instance bodies.  Note that errors in
+          instance specifications will be detected at compile-time by
+          the "re-check" of the specification, only errors in the body
+          should raise Program_Error.
+
+     NOTES
+
+34/3
+     5  {AI05-0153-3AI05-0153-3} A predicate specification does not
+     cause a subtype to be considered constrained.
+
+35/3
+     6  {AI05-0153-3AI05-0153-3} A Static_Predicate, like a constraint,
+     always remains True for all objects of the subtype, except in the
+     case of uninitialized variables and other invalid values.  A
+     Dynamic_Predicate, on the other hand, is checked as specified
+     above, but can become False at other times.  For example, the
+     predicate of a record subtype is not checked when a subcomponent is
+     modified.
+
+                       _Extensions to Ada 2005_
+
+35.a/3
+          {AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1}
+          {AI05-0276-1AI05-0276-1} {AI05-0290-1AI05-0290-1} Predicate
+          aspects are new in Ada 2012.
+
+
+File: aarm2012.info,  Node: 3.3,  Next: 3.4,  Prev: 3.2,  Up: 3
+
+3.3 Objects and Named Numbers
+=============================
+
+1
+[Objects are created at run time and contain a value of a given type.
+An object can be created and initialized as part of elaborating a
+declaration, evaluating an allocator, aggregate, or function_call, or
+passing a parameter by copy.  Prior to reclaiming the storage for an
+object, it is finalized if necessary (see *note 7.6.1::).]
+
+                          _Static Semantics_
+
+2
+All of the following are objects:
+
+2.a
+          Glossary entry: An object is either a constant or a variable.
+          An object contains a value.  An object is created by an
+          object_declaration or by an allocator.  A formal parameter is
+          (a view of) an object.  A subcomponent of an object is an
+          object.
+
+3
+   * the entity declared by an object_declaration;
+
+4
+   * a formal parameter of a subprogram, entry, or generic subprogram;
+
+5
+   * a generic formal object;
+
+6
+   * a loop parameter;
+
+7
+   * a choice parameter of an exception_handler;
+
+8
+   * an entry index of an entry_body;
+
+9
+   * the result of dereferencing an access-to-object value (see *note
+     4.1::);
+
+10/3
+   * {AI95-00416-01AI95-00416-01} {AI05-0015-1AI05-0015-1} the return
+     object of a function;
+
+11
+   * the result of evaluating an aggregate;
+
+11.1/3
+   * {AI05-0003-1AI05-0003-1} a qualified_expression whose operand
+     denotes an object;
+
+12
+   * a component, slice, or view conversion of another object.
+
+13/3
+{AI05-0054-2AI05-0054-2} An object is either a constant object or a
+variable object.  Similarly, a view of an object is either a constant or
+a variable.  All views of a constant elementary object are constant.
+All views of a constant composite object are constant, except for parts
+that are of controlled or immutably limited types; variable views of
+those parts and their subcomponents may exist.  In this sense, objects
+of controlled and immutably limited types are inherently mutable.  A
+constant view of an object cannot be used to modify its value.  The
+terms constant and variable by themselves refer to constant and variable
+views of objects.
+
+14
+The value of an object is read when the value of any part of the object
+is evaluated, or when the value of an enclosing object is evaluated.
+The value of a variable is updated when an assignment is performed to
+any part of the variable, or when an assignment is performed to an
+enclosing object.
+
+14.a
+          Ramification: Reading and updating are intended to include
+          read/write references of any kind, even if they are not
+          associated with the evaluation of a particular construct.
+          Consider, for example, the expression "X.all(F)", where X is
+          an access-to-array object, and F is a function.  The
+          implementation is allowed to first evaluate "X.all" and then
+          F. Finally, a read is performed to get the value of the F'th
+          component of the array.  Note that the array is not
+          necessarily read as part of the evaluation of "X.all".  This
+          is important, because if F were to free X using
+          Unchecked_Deallocation, we want the execution of the final
+          read to be erroneous.
+
+15
+Whether a view of an object is constant or variable is determined by the
+definition of the view.  The following (and no others) represent
+constants:
+
+16
+   * an object declared by an object_declaration with the reserved word
+     constant;
+
+16.a/2
+          To be honest: {AI95-00385-01AI95-00385-01} We mean the word
+          constant as defined by the grammar for object_declaration, not
+          some random word constant.  Thus,
+
+16.b/2
+               X : access constant T;
+
+16.c/2
+          is not a constant.
+
+17
+   * a formal parameter or generic formal object of mode in;
+
+18
+   * a discriminant;
+
+18.1/3
+   * {AI05-0262-1AI05-0262-1} a loop parameter unless specified to be a
+     variable for a generalized loop (see *note 5.5.2::);
+
+19/3
+   * {AI05-0262-1AI05-0262-1} a choice parameter or entry index;
+
+20
+   * the dereference of an access-to-constant value;
+
+20.1/3
+   * {AI05-0015-1AI05-0015-1} the return object declared by an
+     extended_return_statement with the reserved word constant;
+
+21/3
+   * {AI05-0015-1AI05-0015-1} the object denoted by a function_call or
+     an aggregate;
+
+21.1/3
+   * {AI05-0003-1AI05-0003-1} the result of evaluating a
+     qualified_expression;
+
+21.2/3
+   * {AI05-0120-1AI05-0120-1} within the body of a protected function
+     (or a function declared immediately within a protected_body), the
+     current instance of the enclosing protected unit;
+
+22
+   * a selected_component, indexed_component, slice, or view conversion
+     of a constant.
+
+23/3
+{AI05-0264-1AI05-0264-1} At the place where a view of an object is
+defined, a nominal subtype is associated with the view.  The object's
+actual subtype (that is, its subtype) can be more restrictive than the
+nominal subtype of the view; it always is if the nominal subtype is an
+indefinite subtype.  A subtype is an indefinite subtype if it is an
+unconstrained array subtype, or if it has unknown discriminants or
+unconstrained discriminants without defaults (see *note 3.7::);
+otherwise, the subtype is a definite subtype [(all elementary subtypes
+are definite subtypes)].  [A class-wide subtype is defined to have
+unknown discriminants, and is therefore an indefinite subtype.  An
+indefinite subtype does not by itself provide enough information to
+create an object; an additional constraint or explicit initialization
+expression is necessary (see *note 3.3.1::).  A component cannot have an
+indefinite nominal subtype.]
+
+23.1/3
+{AI05-0008-1AI05-0008-1} A view of a composite object is known to be
+constrained if:
+
+23.2/3
+   * its nominal subtype is constrained, and is not an untagged partial
+     view; or
+
+23.3/3
+   * its nominal subtype is indefinite; or
+
+23.4/3
+   * {AI05-0008-1AI05-0008-1} {AI05-0093-1AI05-0093-1} its type is
+     immutably limited (see *note 7.5::); or
+
+23.5/3
+   * it is part of a stand-alone constant (including a generic formal
+     object of mode in); or
+
+23.6/3
+   * it is part of a formal parameter of mode in; or
+
+23.7/3
+   * it is part of the object denoted by a function_call or aggregate;
+     or
+
+23.8/3
+   * it is part of a constant return object of an
+     extended_return_statement; or
+
+23.9/3
+   * {AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1} it is a
+     dereference of a pool-specific access type, and there is no
+     ancestor of its type that has a constrained partial view.
+
+23.a/3
+          Discussion: We do not include dereferences of general access
+          types because they might denote stand-alone aliased
+          unconstrained variables.  That's true even for
+          access-to-constant types (the denoted object does not have to
+          be a constant).
+
+23.b/3
+          {AI05-0005-1AI05-0005-1} {AI05-0008-1AI05-0008-1} There are
+          other cases that could have been included in this definition
+          (view conversions, the current instance of a type, objects of
+          a formal discriminated private type), but these are not
+          relevant to the places this term is used, so they were not
+          included.  If this term is used in additional places, the
+          definition should be checked to see if any of these additional
+          cases are relevant and appropriate wording added if necessary.
+
+23.10/3
+{AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1} For the purposes of
+determining within a generic body whether an object is known to be
+constrained:
+
+23.11/3
+   * if a subtype is a descendant of an untagged generic formal private
+     or derived type, and the subtype is not an unconstrained array
+     subtype, it is not considered indefinite and is considered to have
+     a constrained partial view;
+
+23.12/3
+   * if a subtype is a descendant of a formal access type, it is not
+     considered pool-specific.
+
+24
+A named number provides a name for a numeric value known at compile
+time.  It is declared by a number_declaration.
+
+     NOTES
+
+25
+     7  A constant cannot be the target of an assignment operation, nor
+     be passed as an in out or out parameter, between its initialization
+     and finalization, if any.
+
+25.1/3
+     8  {AI05-0054-2AI05-0054-2} The value of a constant object cannot
+     be changed after its initialization, except in some cases where the
+     object has a controlled or immutably limited part (see *note 7.5::,
+     *note 7.6::, and *note 13.9.1::).
+
+26/3
+     9  {AI05-0264-1AI05-0264-1} The nominal and actual subtypes of an
+     elementary object are always the same.  For a discriminated or
+     array object, if the nominal subtype is constrained, then so is the
+     actual subtype.
+
+                        _Extensions to Ada 83_
+
+26.a
+          There are additional kinds of objects (choice parameters and
+          entry indices of entry bodies).
+
+26.b
+          The result of a function and of evaluating an aggregate are
+          considered (constant) objects.  This is necessary to explain
+          the action of finalization on such things.  Because a
+          function_call is also syntactically a name (see *note 4.1::),
+          the result of a function_call can be renamed, thereby allowing
+          repeated use of the result without calling the function again.
+
+                     _Wording Changes from Ada 83_
+
+26.c/3
+          {AI05-0299-1AI05-0299-1} This subclause now follows the
+          subclauses on types and subtypes, to cut down on the number of
+          forward references.
+
+26.d
+          The term nominal subtype is new.  It is used to distinguish
+          what is known at compile time about an object's constraint,
+          versus what its "true" run-time constraint is.
+
+26.e
+          The terms definite and indefinite (which apply to subtypes)
+          are new.  They are used to aid in the description of generic
+          formal type matching, and to specify when an explicit initial
+          value is required in an object_declaration.
+
+26.f
+          We have moved the syntax for object_declaration and
+          number_declaration down into their respective subclauses, to
+          keep the syntax close to the description of the associated
+          semantics.
+
+26.g
+          We talk about variables and constants here, since the
+          discussion is not specific to object_declarations, and it
+          seems better to have the list of the kinds of constants
+          juxtaposed with the kinds of objects.
+
+26.h
+          We no longer talk about indirect updating due to parameter
+          passing.  Parameter passing is handled in 6.2 and 6.4.1 in a
+          way that there is no need to mention it here in the definition
+          of read and update.  Reading and updating now includes the
+          case of evaluating or assigning to an enclosing object.
+
+                     _Wording Changes from Ada 95_
+
+26.i/2
+          {AI95-00416-01AI95-00416-01} Clarified that the return object
+          is the object created by a function call.
+
+                       _Extensions to Ada 2005_
+
+26.j/3
+          {AI05-0015-1AI05-0015-1} Added wording to allow return objects
+          to be declared as constants, and corrected the definition of
+          return objects as objects.
+
+                    _Wording Changes from Ada 2005_
+
+26.k/3
+          {AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1}
+          {AI05-0093-1AI05-0093-1} Correction: Added a definition of
+          known to be constrained, for use in other rules.
+
+26.l/3
+          {AI05-0054-2AI05-0054-2} Correction: We now recognize the fact
+          that not all declared constant objects are immutable; for
+          those that a variable view can be constructed, they can be
+          changed via that view.
+
+26.m/3
+          {AI05-0120-1AI05-0120-1} Correction: Added the current
+          instance of a protected object to the list of constant views;
+          since the list claims to include all possibilities, it had
+          better include that one.
+
+26.n/3
+          {AI05-0003-1AI05-0003-1} The result of a qualified_expression
+          is defined to be a constant view and is defined to be an
+          object if the operand of the qualified_expression is an
+          object.  These definitions, combined with some grammar
+          changes, allow qualified_expressions to be used in more
+          places.  See *note 4.1:: for details.
+
+* Menu:
+
+* 3.3.1 ::    Object Declarations
+* 3.3.2 ::    Number Declarations
+
+
+File: aarm2012.info,  Node: 3.3.1,  Next: 3.3.2,  Up: 3.3
+
+3.3.1 Object Declarations
+-------------------------
+
+1/3
+{AI05-0262-1AI05-0262-1} An object_declaration declares a stand-alone
+object with a given nominal subtype and, optionally, an explicit initial
+value given by an initialization expression.  For an array, access,
+task, or protected object, the object_declaration may include the
+definition of the (anonymous) type of the object.
+
+                               _Syntax_
+
+2/3
+     {AI95-00385-01AI95-00385-01} {AI95-00406-01AI95-00406-01}
+     {AI05-0183-1AI05-0183-1} object_declaration ::=
+         defining_identifier_list : [aliased] [constant] 
+     subtype_indication [:= expression]
+             [aspect_specification];
+       | defining_identifier_list : [aliased] [constant] 
+     access_definition [:= expression]
+             [aspect_specification];
+       | defining_identifier_list : [aliased] [constant] 
+     array_type_definition [:= expression]
+             [aspect_specification];
+       | single_task_declaration
+       | single_protected_declaration
+
+3
+     defining_identifier_list ::=
+       defining_identifier {, defining_identifier}
+
+                        _Name Resolution Rules_
+
+4
+For an object_declaration with an expression following the compound
+delimiter :=, the type expected for the expression is that of the
+object.  This expression is called the initialization expression.  
+
+                           _Legality Rules_
+
+5/2
+{AI95-00287-01AI95-00287-01} An object_declaration without the reserved
+word constant declares a variable object.  If it has a
+subtype_indication or an array_type_definition that defines an
+indefinite subtype, then there shall be an initialization expression.
+
+                          _Static Semantics_
+
+6/3
+{AI05-0264-1AI05-0264-1} {AI05-0299-1AI05-0299-1} An object_declaration
+with the reserved word constant declares a constant object.  If it has
+an initialization expression, then it is called a full constant
+declaration.  Otherwise, it is called a deferred constant declaration.
+The rules for deferred constant declarations are given in subclause
+*note 7.4::.  The rules for full constant declarations are given in this
+subclause.
+
+7
+Any declaration that includes a defining_identifier_list with more than
+one defining_identifier is equivalent to a series of declarations each
+containing one defining_identifier from the list, with the rest of the
+text of the declaration copied for each declaration in the series, in
+the same order as the list.  The remainder of this International
+Standard relies on this equivalence; explanations are given for
+declarations with a single defining_identifier.
+
+8/2
+{AI95-00385-01AI95-00385-01} The subtype_indication, access_definition,
+or full type definition of an object_declaration defines the nominal
+subtype of the object.  The object_declaration declares an object of the
+type of the nominal subtype.
+
+8.a/2
+          Discussion: {AI95-00385-01AI95-00385-01} The phrase "full type
+          definition" here includes the case of an anonymous array,
+          access, task, or protected type.
+
+8.1/2
+{AI95-00373-01AI95-00373-01} A component of an object is said to require
+late initialization if it has an access discriminant value constrained
+by a per-object expression, or if it has an initialization expression
+that includes a name denoting the current instance of the type or
+denoting an access discriminant.
+
+8.b/2
+          Reason: Such components can depend on the values of other
+          components of the object.  We want to initialize them as late
+          and as reproducibly as possible.
+
+                          _Dynamic Semantics_
+
+9/2
+{AI95-00363-01AI95-00363-01} If a composite object declared by an
+object_declaration has an unconstrained nominal subtype, then if this
+subtype is indefinite or the object is constant the actual subtype of
+this object is constrained.  The constraint is determined by the bounds
+or discriminants (if any) of its initial value; the object is said to be
+constrained by its initial value.  When not constrained by its initial
+value, the actual and nominal subtypes of the object are the same.  If
+its actual subtype is constrained, the object is called a constrained
+object.
+
+10
+For an object_declaration without an initialization expression, any
+initial values for the object or its subcomponents are determined by the
+implicit initial values defined for its nominal subtype, as follows:
+
+11
+   * The implicit initial value for an access subtype is the null value
+     of the access type.
+
+11.1/3
+   * {AI05-0228-1AI05-0228-1} The implicit initial value for a scalar
+     subtype that has the Default_Value aspect specified is the value of
+     that aspect converted to the nominal subtype (which might raise
+     Constraint_Error -- see *note 4.6::, "*note 4.6:: Type
+     Conversions");
+
+11.a.1/3
+          Ramification: This is a Dynamic Semantics rule, so the
+          visibility of the aspect_specification is not relevant -- if
+          the full type for a private type has the Default_Value aspect
+          specified, partial views of the type also have this implicit
+          initial value.
+
+12
+   * The implicit initial (and only) value for each discriminant of a
+     constrained discriminated subtype is defined by the subtype.
+
+13/3
+   * {AI05-0228-1AI05-0228-1} For a (definite) composite subtype, the
+     implicit initial value of each component with a default_expression
+     is obtained by evaluation of this expression and conversion to the
+     component's nominal subtype (which might raise Constraint_Error),
+     unless the component is a discriminant of a constrained subtype
+     (the previous case), or is in an excluded variant (see *note
+     3.8.1::).  For each component that does not have a
+     default_expression, if the composite subtype has the
+     Default_Component_Value aspect specified, the implicit initial
+     value is the value of that aspect converted to the component's
+     nominal subtype; otherwise, any implicit initial values are those
+     determined by the component's nominal subtype.
+
+14
+   * For a protected or task subtype, there is an implicit component (an
+     entry queue) corresponding to each entry, with its implicit initial
+     value being an empty queue.
+
+14.a
+          Implementation Note: The implementation may add implicit
+          components for its own use, which might have implicit initial
+          values.  For a task subtype, such components might represent
+          the state of the associated thread of control.  For a type
+          with dynamic-sized components, such implicit components might
+          be used to hold the offset to some explicit component.
+
+15
+The elaboration of an object_declaration proceeds in the following
+sequence of steps:
+
+16/2
+     1.  {AI95-00385-01AI95-00385-01} The subtype_indication (*note
+     3.2.2: S0027.), access_definition (*note 3.10: S0084.),
+     array_type_definition (*note 3.6: S0051.), single_task_declaration
+     (*note 9.1: S0206.), or single_protected_declaration (*note 9.4:
+     S0211.) is first elaborated.  This creates the nominal subtype (and
+     the anonymous type in the last four cases).
+
+17
+     2.  If the object_declaration includes an initialization
+     expression, the (explicit) initial value is obtained by evaluating
+     the expression and converting it to the nominal subtype (which
+     might raise Constraint_Error -- see *note 4.6::).  
+
+18/2
+     3.  {8652/00028652/0002} {AI95-00171-01AI95-00171-01}
+     {AI95-00373-01AI95-00373-01} The object is created, and, if there
+     is not an initialization expression, the object is initialized by
+     default.  When an object is initialized by default, any per-object
+     constraints (see *note 3.8::) are elaborated and any implicit
+     initial values for the object or for its subcomponents are obtained
+     as determined by the nominal subtype.  Any initial values (whether
+     explicit or implicit) are assigned to the object or to the
+     corresponding subcomponents.  As described in *note 5.2:: and *note
+     7.6::, Initialize and Adjust procedures can be called.  
+
+18.a
+          Discussion: For a per-object constraint that contains some
+          per-object expressions and some non-per-object expressions,
+          the values used for the constraint consist of the values of
+          the non-per-object expressions evaluated at the point of the
+          type_declaration, and the values of the per-object expressions
+          evaluated at the point of the creation of the object.
+
+18.b
+          The elaboration of per-object constraints was presumably
+          performed as part of the dependent compatibility check in Ada
+          83.  If the object is of a limited type with an access
+          discriminant, the access_definition is elaborated at this time
+          (see *note 3.7::).
+
+18.c
+          Reason: The reason we say that evaluating an explicit
+          initialization expression happens before creating the object
+          is that in some cases it is impossible to know the size of the
+          object being created until its initial value is known, as in
+          "X: String := Func_Call(...);".  The implementation can create
+          the object early in the common case where the size can be
+          known early, since this optimization is semantically neutral.
+
+19/2
+       This paragraph was deleted.{AI95-00373-01AI95-00373-01}
+
+19.a
+          Ramification: Since the initial values have already been
+          converted to the appropriate nominal subtype, the only
+          Constraint_Errors that might occur as part of these
+          assignments are for values outside their base range that are
+          used to initialize unconstrained numeric subcomponents.  See
+          *note 3.5::.
+
+20/2
+{AI95-00373-01AI95-00373-01} For the third step above, evaluations and
+assignments are performed in an arbitrary order subject to the following
+restrictions:
+
+20.1/2
+   * {AI95-00373-01AI95-00373-01} Assignment to any part of the object
+     is preceded by the evaluation of the value that is to be assigned.
+
+20.a.1/2
+          Reason: Duh.  But we ought to say it.  Note that, like any
+          rule in the International Standard, it doesn't prevent an
+          "as-if" optimization; as long as the semantics as observed
+          from the program are correct, the compiler can generate any
+          code it wants.
+
+20.2/2
+   * {AI95-00373-01AI95-00373-01} The evaluation of a default_expression
+     that includes the name of a discriminant is preceded by the
+     assignment to that discriminant.
+
+20.a.2/2
+          Reason: Duh again.  But we have to say this, too.  It's odd
+          that Ada 95 only required the default expressions to be
+          evaluated before the discriminant is used; it says nothing
+          about discriminant values that come from subtype_indications.
+
+20.3/2
+   * {AI95-00373-01AI95-00373-01} The evaluation of the
+     default_expression for any component that depends on a discriminant
+     is preceded by the assignment to that discriminant.
+
+20.a
+          Reason: For example:
+
+20.b
+               type R(D : Integer := F) is
+                   record
+                       S : String(1..D) := (others => G);
+                   end record;
+
+20.c
+               X : R;
+
+20.d
+          For the elaboration of the declaration of X, it is important
+          that F be evaluated before the aggregate.
+
+20.4/3
+   * {AI95-00373-01AI95-00373-01} {AI05-0092-1AI05-0092-1} The
+     assignments to any components, including implicit components, not
+     requiring late initialization precede the initial value evaluations
+     for any components requiring late initialization; if two components
+     both require late initialization, then assignments to parts of the
+     component occurring earlier in the order of the component
+     declarations precede the initial value evaluations of the component
+     occurring later.
+
+20.e/2
+          Reason: Components that require late initialization can refer
+          to the entire object during their initialization.  We want
+          them to be initialized as late as possible to reduce the
+          chance that their initialization depends on uninitialized
+          components.  For instance:
+
+20.f/2
+               type T (D : Natural) is
+                 limited record
+                   C1 : T1 (T'Access);
+                   C2 : Natural := F (D);
+                   C3 : String (1 .. D) := (others => ' ');
+                 end record;
+
+20.g/2
+          Component C1 requires late initialization.  The initialization
+          could depend on the values of any component of T, including D,
+          C2, or C3.  Therefore, we want to it to be initialized last.
+          Note that C2 and C3 do not require late initialization; they
+          only have to be initialized after D.
+
+20.h/2
+          It is possible for there to be more than one component that
+          requires late initialization.  In this case, the language
+          can't prevent problems, because all of the components can't be
+          the last one initialized.  In this case, we specify the order
+          of initialization for components requiring late
+          initialization; by doing so, programmers can arrange their
+          code to avoid accessing uninitialized components, and such
+          arrangements are portable.  Note that if the program accesses
+          an uninitialized component, *note 13.9.1:: defines the
+          execution to be erroneous.
+
+21/3
+{AI05-0228-1AI05-0228-1} [There is no implicit initial value defined for
+a scalar subtype unless the Default_Value aspect has been specified for
+the type.]  In the absence of an explicit initialization or the
+specification of the Default_Value aspect, a newly created scalar object
+might have a value that does not belong to its subtype (see *note
+13.9.1:: and *note H.1::).
+
+21.a
+          To be honest: It could even be represented by a bit pattern
+          that doesn't actually represent any value of the type at all,
+          such as an invalid internal code for an enumeration type, or a
+          NaN for a floating point type.  It is a generally a bounded
+          error to reference scalar objects with such "invalid
+          representations", as explained in *note 13.9.1::, "*note
+          13.9.1:: Data Validity".
+
+21.b
+          Ramification: There is no requirement that two objects of the
+          same scalar subtype have the same implicit initial "value" (or
+          representation).  It might even be the case that two
+          elaborations of the same object_declaration produce two
+          different initial values.  However, any particular
+          uninitialized object is default-initialized to a single value
+          (or invalid representation).  Thus, multiple reads of such an
+          uninitialized object will produce the same value each time (if
+          the implementation chooses not to detect the error).
+
+     NOTES
+
+22
+     10  Implicit initial values are not defined for an indefinite
+     subtype, because if an object's nominal subtype is indefinite, an
+     explicit initial value is required.
+
+23/3
+     11  {AI05-0092-1AI05-0092-1} {AI05-0255-1AI05-0255-1} As indicated
+     above, a stand-alone object is an object declared by an
+     object_declaration.  Similar definitions apply to "stand-alone
+     constant" and "stand-alone variable."  A subcomponent of an object
+     is not a stand-alone object, nor is an object that is created by an
+     allocator.  An object declared by a loop_parameter_specification,
+     iterator_specification, parameter_specification,
+     entry_index_specification, choice_parameter_specification,
+     extended_return_statement, or a formal_object_declaration of mode
+     in out is not considered a stand-alone object.
+
+24
+     12  The type of a stand-alone object cannot be abstract (see *note
+     3.9.3::).
+
+                              _Examples_
+
+25
+Example of a multiple object declaration:
+
+26
+     --  the multiple object declaration 
+
+27/2
+     {AI95-00433-01AI95-00433-01} John, Paul : not null Person_Name := new 
Person(Sex => M);  --  see *note 3.10.1::
+
+28
+     --  is equivalent to the two single object declarations in the order given
+
+29/2
+     {AI95-00433-01AI95-00433-01} John : not null Person_Name := new 
Person(Sex => M);
+     Paul : not null Person_Name := new Person(Sex => M);
+
+30
+Examples of variable declarations:
+
+31/2
+     {AI95-00433-01AI95-00433-01} Count, Sum  : Integer;
+     Size        : Integer range 0 .. 10_000 := 0;
+     Sorted      : Boolean := False;
+     Color_Table : array(1 .. Max) of Color;
+     Option      : Bit_Vector(1 .. 10) := (others => True);
+     Hello       : aliased String := "Hi, world.";
+     [Unicode 952], [Unicode 966]        : Float range -PI .. +PI;
+
+32
+Examples of constant declarations:
+
+33/2
+     {AI95-00433-01AI95-00433-01} Limit     : constant Integer := 10_000;
+     Low_Limit : constant Integer := Limit/10;
+     Tolerance : constant Real := Dispersion(1.15);
+     Hello_Msg : constant access String := Hello'Access; -- see *note 3.10.2::
+
+                        _Extensions to Ada 83_
+
+33.a
+          The syntax rule for object_declaration is modified to allow
+          the aliased reserved word.
+
+33.b
+          A variable declared by an object_declaration can be
+          constrained by its initial value; that is, a variable of a
+          nominally unconstrained array subtype, or discriminated type
+          without defaults, can be declared so long as it has an
+          explicit initial value.  In Ada 83, this was permitted for
+          constants, and for variables created by allocators, but not
+          for variables declared by object_declarations.  This is
+          particularly important for tagged class-wide types, since
+          there is no way to constrain them explicitly, and so an
+          initial value is the only way to provide a constraint.  It is
+          also important for generic formal private types with unknown
+          discriminants.
+
+33.c
+          We now allow an unconstrained_array_definition in an
+          object_declaration.  This allows an object of an anonymous
+          array type to have its bounds determined by its initial value.
+          This is for uniformity: If one can write "X: constant
+          array(Integer range 1..10) of Integer := ...;" then it makes
+          sense to also allow "X: constant array(Integer range <>) of
+          Integer := ...;".  (Note that if anonymous array types are
+          ever sensible, a common situation is for a table implemented
+          as an array.  Tables are often constant, and for constants,
+          there's usually no point in forcing the user to count the
+          number of elements in the value.)
+
+                     _Wording Changes from Ada 83_
+
+33.d
+          We have moved the syntax for object_declarations into this
+          subclause.
+
+33.e
+          Deferred constants no longer have a separate syntax rule, but
+          rather are incorporated in object_declaration as constants
+          declared without an initialization expression.
+
+                     _Inconsistencies With Ada 95_
+
+33.f/2
+          {AI95-00363-01AI95-00363-01} Unconstrained aliased objects of
+          types with discriminants with defaults are no longer
+          constrained by their initial values.  This means that a
+          program that raised Constraint_Error from an attempt to change
+          the discriminants will no longer do so.  The change only
+          affects programs that depended on the raising of
+          Constraint_Error in this case, so the inconsistency is
+          unlikely to occur outside of the ACATS. This change may
+          however cause compilers to implement these objects
+          differently, possibly taking additional memory or time.  This
+          is unlikely to be worse than the differences caused by any
+          major compiler upgrade.
+
+                        _Extensions to Ada 95_
+
+33.g/2
+          {AI95-00287-01AI95-00287-01} A constant may have a limited
+          type; the initialization expression has to be built-in-place
+          (see *note 7.5::).
+
+33.h/2
+          {AI95-00385-01AI95-00385-01} {AI95-00406-01AI95-00406-01} A
+          stand-alone object may have an anonymous access type.
+
+                     _Wording Changes from Ada 95_
+
+33.i/2
+          {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+          Corrected wording to say that per-object constraints are
+          elaborated (not evaluated).
+
+33.j/2
+          {AI95-00373-01AI95-00373-01} The rules for evaluating default
+          initialization have been tightened.  In particular, components
+          whose default initialization can refer to the rest of the
+          object are required to be initialized last.
+
+33.k/2
+          {AI95-00433-01AI95-00433-01} Added examples of various new
+          constructs.
+
+                       _Extensions to Ada 2005_
+
+33.l/3
+          {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+          be used in an object_declaration.  This is described in *note
+          13.1.1::.
+
+                    _Wording Changes from Ada 2005_
+
+33.m/3
+          {AI05-0228-1AI05-0228-1} Implicit initial values can now be
+          given for scalar types and for scalar array components, using
+          the Default_Value (see *note 3.5::) and
+          Default_Component_Value (see *note 3.6::) aspects; the
+          extension is documented there.
+
+
+File: aarm2012.info,  Node: 3.3.2,  Prev: 3.3.1,  Up: 3.3
+
+3.3.2 Number Declarations
+-------------------------
+
+1
+A number_declaration declares a named number.
+
+1.a/3
+          Discussion: {AI05-0299-1AI05-0299-1} If a value or other
+          property of a construct is required to be static that means it
+          is required to be determined prior to execution.  A static
+          expression is an expression whose value is computed at compile
+          time and is usable in contexts where the actual value might
+          affect the legality of the construct.  This is fully defined
+          in subclause *note 4.9::.
+
+                               _Syntax_
+
+2
+     number_declaration ::=
+          defining_identifier_list : constant := static_expression;
+
+                        _Name Resolution Rules_
+
+3
+The static_expression given for a number_declaration is expected to be
+of any numeric type.
+
+                           _Legality Rules_
+
+4/3
+{AI05-0299-1AI05-0299-1} The static_expression given for a number
+declaration shall be a static expression, as defined by subclause *note
+4.9::.
+
+                          _Static Semantics_
+
+5
+The named number denotes a value of type universal_integer if the type
+of the static_expression is an integer type.  The named number denotes a
+value of type universal_real if the type of the static_expression is a
+real type.
+
+6
+The value denoted by the named number is the value of the
+static_expression, converted to the corresponding universal type.  
+
+                          _Dynamic Semantics_
+
+7
+The elaboration of a number_declaration has no effect.
+
+7.a
+          Proof: Since the static_expression was evaluated at compile
+          time.
+
+                              _Examples_
+
+8
+Examples of number declarations:
+
+9
+     Two_Pi        : constant := 2.0*Ada.Numerics.Pi;   -- a real number (see 
*note A.5::)
+
+10/2
+     {AI95-00433-01AI95-00433-01} Max           : constant := 500;             
      -- an integer number
+     Max_Line_Size : constant := Max/6;                 -- the integer 83
+     Power_16      : constant := 2**16;                 -- the integer 65_536
+     One, Un, Eins : constant := 1;                     -- three different 
names for 1
+
+                        _Extensions to Ada 83_
+
+10.a
+          We now allow a static expression of any numeric type to
+          initialize a named number.  For integer types, it was possible
+          in Ada 83 to use 'Pos to define a named number, but there was
+          no way to use a static expression of some nonuniversal real
+          type to define a named number.  This change is upward
+          compatible because of the preference rule for the operators of
+          the root numeric types.
+
+                     _Wording Changes from Ada 83_
+
+10.b
+          We have moved the syntax rule into this subclause.
+
+10.c
+          AI83-00263 describes the elaboration of a number declaration
+          in words similar to that of an object_declaration.  However,
+          since there is no expression to be evaluated and no object to
+          be created, it seems simpler to say that the elaboration has
+          no effect.
+
+
+File: aarm2012.info,  Node: 3.4,  Next: 3.5,  Prev: 3.3,  Up: 3
+
+3.4 Derived Types and Classes
+=============================
+
+1/2
+{AI95-00401-01AI95-00401-01} {AI95-00419-01AI95-00419-01} A
+derived_type_definition defines a derived type (and its first subtype)
+whose characteristics are derived from those of a parent type, and
+possibly from progenitor types.  
+
+1.a/2
+          Glossary entry: A derived type is a type defined in terms of
+          one or more other types given in a derived type definition.
+          The first of those types is the parent type of the derived
+          type and any others are progenitor types.  Each class
+          containing the parent type or a progenitor type also contains
+          the derived type.  The derived type inherits properties such
+          as components and primitive operations from the parent and
+          progenitors.  A type together with the types derived from it
+          (directly or indirectly) form a derivation class.
+
+1.1/2
+{AI95-00442-01AI95-00442-01} A class of types is a set of types that is
+closed under derivation; that is, if the parent or a progenitor type of
+a derived type belongs to a class, then so does the derived type.  By
+saying that a particular group of types forms a class, we are saying
+that all derivatives of a type in the set inherit the characteristics
+that define that set.  The more general term category of types is used
+for a set of types whose defining characteristics are not necessarily
+inherited by derivatives; for example, limited, abstract, and interface
+are all categories of types, but not classes of types.
+
+1.b/2
+          Ramification: A class of types is also a category of types.
+
+                               _Syntax_
+
+2/2
+     {AI95-00251-01AI95-00251-01} {AI95-00419-01AI95-00419-01}
+     derived_type_definition ::=
+         [abstract] [limited] new parent_subtype_indication [[and 
+     interface_list] record_extension_part]
+
+                           _Legality Rules_
+
+3/2
+{AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01}
+{AI95-00419-01AI95-00419-01} The parent_subtype_indication defines the
+parent subtype; its type is the parent type.  The interface_list defines
+the progenitor types (see *note 3.9.4::).  A derived type has one parent
+type and zero or more progenitor types.
+
+3.a/2
+          Glossary entry: The parent of a derived type is the first type
+          given in the definition of the derived type.  The parent can
+          be almost any kind of type, including an interface type.
+
+4
+A type shall be completely defined (see *note 3.11.1::) prior to being
+specified as the parent type in a derived_type_definition -- [the
+full_type_declarations for the parent type and any of its subcomponents
+have to precede the derived_type_definition.]
+
+4.a
+          Discussion: This restriction does not apply to the ancestor
+          type of a private extension -- see *note 7.3::; such a type
+          need not be completely defined prior to the
+          private_extension_declaration.  However, the restriction does
+          apply to record extensions, so the ancestor type will have to
+          be completely defined prior to the full_type_declaration
+          corresponding to the private_extension_declaration.
+
+4.b
+          Reason: We originally hoped we could relax this restriction.
+          However, we found it too complex to specify the rules for a
+          type derived from an incompletely defined limited type that
+          subsequently became nonlimited.
+
+5/2
+{AI95-00401-01AI95-00401-01} If there is a record_extension_part, the
+derived type is called a record extension of the parent type.  A
+record_extension_part shall be provided if and only if the parent type
+is a tagged type.  [An interface_list shall be provided only if the
+parent type is a tagged type.]
+
+5.a.1/2
+          Proof: {AI95-00401-01AI95-00401-01} The syntax only allows an
+          interface_list to appear with a record_extension_part, and a
+          record_extension_part can only be provided if the parent type
+          is a tagged type.  We give the last sentence anyway for
+          completeness.
+
+5.a
+          Implementation Note: We allow a record extension to inherit
+          discriminants; an early version of Ada 9X did not.  If the
+          parent subtype is unconstrained, it can be implemented as
+          though its discriminants were repeated in a new
+          known_discriminant_part and then used to constrain the old
+          ones one-for-one.  However, in an extension aggregate, the
+          discriminants in this case do not appear in the component
+          association list.
+
+5.b/2
+          Ramification: {AI95-00114-01AI95-00114-01} This rule needs to
+          be rechecked in the visible part of an instance of a generic
+          unit because of the "only if" part of the rule.  For example:
+
+5.c/2
+               generic
+                  type T is private;
+               package P is
+                  type Der is new T;
+               end P;
+
+5.d/2
+               package I is new P (Some_Tagged_Type); -- illegal
+
+5.e/2
+          {AI95-00114-01AI95-00114-01} The instantiation is illegal
+          because a tagged type is being extended in the visible part
+          without a record_extension_part.  Note that this is legal in
+          the private part or body of an instance, both to avoid a
+          contract model violation, and because no code that can see
+          that the type is actually tagged can also see the derived type
+          declaration.
+
+5.f/2
+          No recheck is needed for derived types with a
+          record_extension_part, as that has to be derived from
+          something that is known to be tagged (otherwise the template
+          is illegal).
+
+5.1/3
+{AI95-00419-01AI95-00419-01} {AI05-0096-1AI05-0096-1} If the reserved
+word limited appears in a derived_type_definition, the parent type shall
+be a limited type.  If the parent type is a tagged formal type, then in
+addition to the places where Legality Rules normally apply (see *note
+12.3::), this rule applies also in the private part of an instance of a
+generic unit.
+
+5.g/2
+          Reason: We allow limited because we don't inherit limitedness
+          from interfaces, so we must have a way to derive a limited
+          type from interfaces.  The word limited has to be legal when
+          the parent could be an interface, and that includes generic
+          formal abstract types.  Since we have to allow it in this
+          case, we might as well allow it everywhere as documentation,
+          to make it explicit that the type is limited.
+
+5.h/2
+          However, we do not want to allow limited when the parent is
+          nonlimited: limitedness cannot change in a derivation tree.
+
+5.i/3
+          If the parent type is an untagged limited formal type with an
+          actual type that is nonlimited, we allow derivation as a
+          limited type in the private part or body as no place could
+          have visibility on the resulting type where it was known to be
+          nonlimited (outside of the instance).  (See the previous
+          paragraph's annotations for an explanation of this.)  However,
+          if the parent type is a tagged limited formal type with an
+          actual type that is nonlimited, it would be possible to pass a
+          value of the limited type extension to a class-wide type of
+          the parent, which would be nonlimited.  That's too weird to
+          allow (even though all of the extension components would have
+          to be nonlimited because the rules of *note 3.9.1:: are
+          rechecked), so we have a special rule to prevent that in the
+          private part (type extension from a formal type is illegal in
+          a generic package body).
+
+                          _Static Semantics_
+
+6
+The first subtype of the derived type is unconstrained if a
+known_discriminant_part is provided in the declaration of the derived
+type, or if the parent subtype is unconstrained.  Otherwise, the
+constraint of the first subtype corresponds to that of the parent
+subtype in the following sense: it is the same as that of the parent
+subtype except that for a range constraint (implicit or explicit), the
+value of each bound of its range is replaced by the corresponding value
+of the derived type.
+
+6.a
+          Discussion: A digits_constraint in a subtype_indication for a
+          decimal fixed point subtype always imposes a range constraint,
+          implicitly if there is no explicit one given.  See *note
+          3.5.9::, "*note 3.5.9:: Fixed Point Types".
+
+6.1/2
+{AI95-00231-01AI95-00231-01} The first subtype of the derived type
+excludes null (see *note 3.10::) if and only if the parent subtype
+excludes null.
+
+7/3
+{AI05-0110-1AI05-0110-1} The characteristics and implicitly declared
+primitive subprograms of the derived type are defined as follows:
+
+7.a/3
+          Ramification: {AI05-0110-1AI05-0110-1} The characteristics of
+          a type do not include its primitive subprograms (primitive
+          subprograms include predefined operators).  The rules
+          governing availability/visibility and inheritance of
+          characteristics are separate from those for primitive
+          subprograms.
+
+8/2
+   * {AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01}
+     {AI95-00442-01AI95-00442-01} [If the parent type or a progenitor
+     type belongs to a class of types, then the derived type also
+     belongs to that class.]  The following sets of types, as well as
+     any higher-level sets composed from them, are classes in this
+     sense[, and hence the characteristics defining these classes are
+     inherited by derived types from their parent or progenitor types]:
+     signed integer, modular integer, ordinary fixed, decimal fixed,
+     floating point, enumeration, boolean, character,
+     access-to-constant, general access-to-variable, pool-specific
+     access-to-variable, access-to-subprogram, array, string, non-array
+     composite, nonlimited, untagged record, tagged, task, protected,
+     and synchronized tagged.
+
+8.a
+          Discussion: This is inherent in our notion of a "class" of
+          types.  It is not mentioned in the initial definition of
+          "class" since at that point type derivation has not been
+          defined.  In any case, this rule ensures that every class of
+          types is closed under derivation.
+
+9
+   * If the parent type is an elementary type or an array type, then the
+     set of possible values of the derived type is a copy of the set of
+     possible values of the parent type.  For a scalar type, the base
+     range of the derived type is the same as that of the parent type.
+
+9.a
+          Discussion: The base range of a type defined by an
+          integer_type_definition or a real_type_definition is
+          determined by the _definition, and is not necessarily the same
+          as that of the corresponding root numeric type from which the
+          newly defined type is implicitly derived.  Treating numerics
+          types as implicitly derived from one of the two root numeric
+          types is simply to link them into a type hierarchy; such an
+          implicit derivation does not follow all the rules given here
+          for an explicit derived_type_definition.
+
+10
+   * If the parent type is a composite type other than an array type,
+     then the components, protected subprograms, and entries that are
+     declared for the derived type are as follows:
+
+11
+             * The discriminants specified by a new
+               known_discriminant_part, if there is one; otherwise, each
+               discriminant of the parent type (implicitly declared in
+               the same order with the same specifications) -- in the
+               latter case, the discriminants are said to be inherited,
+               or if unknown in the parent, are also unknown in the
+               derived type;
+
+12
+             * Each nondiscriminant component, entry, and protected
+               subprogram of the parent type, implicitly declared in the
+               same order with the same declarations; these components,
+               entries, and protected subprograms are said to be
+               inherited;
+
+12.a
+          Ramification: The profiles of entries and protected
+          subprograms do not change upon type derivation, although the
+          type of the "implicit" parameter identified by the prefix of
+          the name in a call does.
+
+12.b
+          To be honest: Any name in the parent type_declaration that
+          denotes the current instance of the type is replaced with a
+          name denoting the current instance of the derived type,
+          converted to the parent type.
+
+13
+             * Each component declared in a record_extension_part, if
+               any.
+
+14
+     Declarations of components, protected subprograms, and entries,
+     whether implicit or explicit, occur immediately within the
+     declarative region of the type, in the order indicated above,
+     following the parent subtype_indication.
+
+14.a
+          Discussion: The order of declarations within the region
+          matters for record_aggregates and extension_aggregates.
+
+14.b
+          Ramification: In most cases, these things are implicitly
+          declared immediately following the parent subtype_indication.
+          However, *note 7.3.1::, "*note 7.3.1:: Private Operations"
+          defines some cases in which they are implicitly declared
+          later, and some cases in which the are not declared at all.
+
+14.c
+          Discussion: The place of the implicit declarations of
+          inherited components matters for visibility -- they are not
+          visible in the known_discriminant_part nor in the parent
+          subtype_indication, but are usually visible within the
+          record_extension_part, if any (although there are restrictions
+          on their use).  Note that a discriminant specified in a new
+          known_discriminant_part is not considered "inherited" even if
+          it has the same name and subtype as a discriminant of the
+          parent type.
+
+15/2
+   * This paragraph was deleted.{AI95-00419-01AI95-00419-01}
+
+16
+   * [For each predefined operator of the parent type, there is a
+     corresponding predefined operator of the derived type.]
+
+16.a
+          Proof: This is a ramification of the fact that each class that
+          includes the parent type also includes the derived type, and
+          the fact that the set of predefined operators that is defined
+          for a type, as described in *note 4.5::, is determined by the
+          classes to which it belongs.
+
+16.b
+          Reason: Predefined operators are handled separately because
+          they follow a slightly different rule than user-defined
+          primitive subprograms.  In particular the systematic
+          replacement described below does not apply fully to the
+          relational operators for Boolean and the exponentiation
+          operator for Integer.  The relational operators for a type
+          derived from Boolean still return Standard.Boolean.  The
+          exponentiation operator for a type derived from Integer still
+          expects Standard.Integer for the right operand.  In addition,
+          predefined operators "reemerge" when a type is the actual type
+          corresponding to a generic formal type, so they need to be
+          well defined even if hidden by user-defined primitive
+          subprograms.
+
+17/2
+   * {AI95-00401-01AI95-00401-01} For each user-defined primitive
+     subprogram (other than a user-defined equality operator -- see
+     below) of the parent type or of a progenitor type that already
+     exists at the place of the derived_type_definition, there exists a
+     corresponding inherited primitive subprogram of the derived type
+     with the same defining name.  Primitive user-defined equality
+     operators of the parent type and any progenitor types are also
+     inherited by the derived type, except when the derived type is a
+     nonlimited record extension, and the inherited operator would have
+     a profile that is type conformant with the profile of the
+     corresponding predefined equality operator; in this case, the
+     user-defined equality operator is not inherited, but is rather
+     incorporated into the implementation of the predefined equality
+     operator of the record extension (see *note 4.5.2::).  
+
+17.a
+          Ramification: We say "...already exists..."  rather than "is
+          visible" or "has been declared" because there are certain
+          operations that are declared later, but still exist at the
+          place of the derived_type_definition, and there are operations
+          that are never declared, but still exist.  These cases are
+          explained in *note 7.3.1::.
+
+17.b
+          Note that nonprivate extensions can appear only after the last
+          primitive subprogram of the parent -- the freezing rules
+          ensure this.
+
+17.c
+          Reason: A special case is made for the equality operators on
+          nonlimited record extensions because their predefined equality
+          operators are already defined in terms of the primitive
+          equality operator of their parent type (and of the tagged
+          components of the extension part).  Inheriting the parent's
+          equality operator as is would be undesirable, because it would
+          ignore any components of the extension part.  On the other
+          hand, if the parent type is limited, then any user-defined
+          equality operator is inherited as is, since there is no
+          predefined equality operator to take its place.
+
+17.d/2
+          Ramification: {AI95-00114-01AI95-00114-01} Because
+          user-defined equality operators are not inherited by
+          nonlimited record extensions, the formal parameter names of =
+          and /= revert to Left and Right, even if different formal
+          parameter names were used in the user-defined equality
+          operators of the parent type.
+
+17.e/2
+          Discussion: {AI95-00401-01AI95-00401-01} This rule only
+          describes what operations are inherited; the rules that
+          describe what happens when there are conflicting inherited
+          subprograms are found in *note 8.3::.
+
+18/3
+     {AI95-00401-01AI95-00401-01} {AI05-0164-1AI05-0164-1}
+     {AI05-0240-1AI05-0240-1} The profile of an inherited subprogram
+     (including an inherited enumeration literal) is obtained from the
+     profile of the corresponding (user-defined) primitive subprogram of
+     the parent or progenitor type, after systematic replacement of each
+     subtype of its profile (see *note 6.1::) that is of the parent or
+     progenitor type, other than those subtypes found in the designated
+     profile of an access_definition, with a corresponding subtype of
+     the derived type.  For a given subtype of the parent or progenitor
+     type, the corresponding subtype of the derived type is defined as
+     follows:
+
+19
+             * If the declaration of the derived type has neither a
+               known_discriminant_part nor a record_extension_part, then
+               the corresponding subtype has a constraint that
+               corresponds (as defined above for the first subtype of
+               the derived type) to that of the given subtype.
+
+20
+             * If the derived type is a record extension, then the
+               corresponding subtype is the first subtype of the derived
+               type.
+
+21
+             * If the derived type has a new known_discriminant_part but
+               is not a record extension, then the corresponding subtype
+               is constrained to those values that when converted to the
+               parent type belong to the given subtype (see *note
+               4.6::).  
+
+21.a
+          Reason: An inherited subprogram of an untagged type has an
+          Intrinsic calling convention, which precludes the use of the
+          Access attribute.  We preclude 'Access because correctly
+          performing all required constraint checks on an indirect call
+          to such an inherited subprogram was felt to impose an
+          undesirable implementation burden.
+
+21.b/3
+          {AI05-0164-1AI05-0164-1} Note that the exception to
+          substitution of the parent or progenitor type applies only in
+          the profiles of anonymous access-to-subprogram types.  The
+          exception is necessary to avoid calling an
+          access-to-subprogram with types and/or constraints different
+          than expected by the actual routine.
+
+22/2
+     {AI95-00401-01AI95-00401-01} The same formal parameters have
+     default_expressions in the profile of the inherited subprogram.
+     [Any type mismatch due to the systematic replacement of the parent
+     or progenitor type by the derived type is handled as part of the
+     normal type conversion associated with parameter passing -- see
+     *note 6.4.1::.]
+
+22.a/2
+          Reason: {AI95-00401-01AI95-00401-01} We don't introduce the
+          type conversion explicitly here since conversions to record
+          extensions or on access parameters are not generally legal.
+          Furthermore, any type conversion would just be "undone" since
+          the subprogram of the parent or progenitor is ultimately being
+          called anyway.  (Null procedures can be inherited from a
+          progenitor without being overridden, so it is possible to call
+          subprograms of an interface.)
+
+23/2
+{AI95-00401-01AI95-00401-01} If a primitive subprogram of the parent or
+progenitor type is visible at the place of the derived_type_definition,
+then the corresponding inherited subprogram is implicitly declared
+immediately after the derived_type_definition.  Otherwise, the inherited
+subprogram is implicitly declared later or not at all, as explained in
+*note 7.3.1::.
+
+24
+A derived type can also be defined by a private_extension_declaration
+(*note 7.3: S0194.) (see *note 7.3::) or a
+formal_derived_type_definition (*note 12.5.1: S0285.) (see *note
+12.5.1::).  Such a derived type is a partial view of the corresponding
+full or actual type.
+
+25
+All numeric types are derived types, in that they are implicitly derived
+from a corresponding root numeric type (see *note 3.5.4:: and *note
+3.5.6::).
+
+                          _Dynamic Semantics_
+
+26
+The elaboration of a derived_type_definition creates the derived type
+and its first subtype, and consists of the elaboration of the
+subtype_indication (*note 3.2.2: S0027.) and the record_extension_part
+(*note 3.9.1: S0075.), if any.  If the subtype_indication (*note 3.2.2:
+S0027.) depends on a discriminant, then only those expressions that do
+not depend on a discriminant are evaluated.
+
+26.a/2
+          Discussion: {AI95-00251-01AI95-00251-01} We don't mention the
+          interface_list, because it does not need elaboration (see
+          *note 3.9.4::).  This is consistent with the handling of
+          discriminant_parts, which aren't elaborated either.
+
+27/2
+{AI95-00391-01AI95-00391-01} {AI95-00401-01AI95-00401-01} For the
+execution of a call on an inherited subprogram, a call on the
+corresponding primitive subprogram of the parent or progenitor type is
+performed; the normal conversion of each actual parameter to the subtype
+of the corresponding formal parameter (see *note 6.4.1::) performs any
+necessary type conversion as well.  If the result type of the inherited
+subprogram is the derived type, the result of calling the subprogram of
+the parent or progenitor is converted to the derived type, or in the
+case of a null extension, extended to the derived type using the
+equivalent of an extension_aggregate with the original result as the
+ancestor_part and null record as the record_component_association_list.  
+
+27.a/2
+          Discussion: {AI95-00391-01AI95-00391-01} If an inherited
+          function returns the derived type, and the type is a nonnull
+          record extension, then the inherited function shall be
+          overridden, unless the type is abstract (in which case the
+          function is abstract, and (unless overridden) cannot be called
+          except via a dispatching call).  See *note 3.9.3::.
+
+     NOTES
+
+28
+     13  Classes are closed under derivation -- any class that contains
+     a type also contains its derivatives.  Operations available for a
+     given class of types are available for the derived types in that
+     class.
+
+29
+     14  Evaluating an inherited enumeration literal is equivalent to
+     evaluating the corresponding enumeration literal of the parent
+     type, and then converting the result to the derived type.  This
+     follows from their equivalence to parameterless functions.  
+
+30
+     15  A generic subprogram is not a subprogram, and hence cannot be a
+     primitive subprogram and cannot be inherited by a derived type.  On
+     the other hand, an instance of a generic subprogram can be a
+     primitive subprogram, and hence can be inherited.
+
+31
+     16  If the parent type is an access type, then the parent and the
+     derived type share the same storage pool; there is a null access
+     value for the derived type and it is the implicit initial value for
+     the type.  See *note 3.10::.
+
+32
+     17  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 *note 4.5.2::).  If the parent type is an integer
+     type, the right operand of the predefined exponentiation operator
+     is of the predefined type Integer (see *note 4.5.6::).
+
+33
+     18  Any discriminants of the parent type are either all inherited,
+     or completely replaced with a new set of discriminants.
+
+34
+     19  For an inherited subprogram, the subtype of a formal parameter
+     of the derived type need not have any value in common with the
+     first subtype of the derived type.
+
+34.a
+          Proof: This happens when the parent subtype is constrained to
+          a range that does not overlap with the range of a subtype of
+          the parent type that appears in the profile of some primitive
+          subprogram of the parent type.  For example:
+
+34.b
+               type T1 is range 1..100;
+               subtype S1 is T1 range 1..10;
+               procedure P(X : in S1);  -- P is a primitive subprogram
+               type T2 is new T1 range 11..20;
+               -- implicitly declared:
+               -- procedure P(X : in T2'Base range 1..10);
+               --      X cannot be in T2'First .. T2'Last
+
+35
+     20  If the reserved word abstract is given in the declaration of a
+     type, the type is abstract (see *note 3.9.3::).
+
+35.1/2
+     21  {AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01} An
+     interface type that has a progenitor type "is derived from" that
+     type.  A derived_type_definition, however, never defines an
+     interface type.
+
+35.2/2
+     22  {AI95-00345-01AI95-00345-01} It is illegal for the parent type
+     of a derived_type_definition to be a synchronized tagged type.
+
+35.a/3
+          Proof: {AI05-0299-1AI05-0299-1} *note 3.9.1:: prohibits record
+          extensions whose parent type is a synchronized tagged type,
+          and this subclause requires tagged types to have a record
+          extension.  Thus there are no legal derivations.  Note that a
+          synchronized interface can be used as a progenitor in an
+          interface_type_definition as well as in task and protected
+          types, but we do not allow concrete extensions of any
+          synchronized tagged type.
+
+                              _Examples_
+
+36
+Examples of derived type declarations:
+
+37
+     type Local_Coordinate is new Coordinate;   --  two different types
+     type Midweek is new Day range Tue .. Thu;  --  see *note 3.5.1::
+     type Counter is new Positive;              --  same range as Positive 
+
+38
+     type Special_Key is new Key_Manager.Key;   --  see *note 7.3.1::
+       -- the inherited subprograms have the following specifications: 
+       --         procedure Get_Key(K : out Special_Key);
+       --         function "<"(X,Y : Special_Key) return Boolean;
+
+                     _Inconsistencies With Ada 83_
+
+38.a
+          When deriving from a (nonprivate, nonderived) type in the same
+          visible part in which it is defined, if a predefined operator
+          had been overridden prior to the derivation, the derived type
+          will inherit the user-defined operator rather than the
+          predefined operator.  The work-around (if the new behavior is
+          not the desired behavior) is to move the definition of the
+          derived type prior to the overriding of any predefined
+          operators.
+
+                    _Incompatibilities With Ada 83_
+
+38.b
+          When deriving from a (nonprivate, nonderived) type in the same
+          visible part in which it is defined, a primitive subprogram of
+          the parent type declared before the derived type will be
+          inherited by the derived type.  This can cause upward
+          incompatibilities in cases like this:
+
+38.c
+                  package P is
+                     type T is (A, B, C, D);
+                     function F( X : T := A ) return Integer;
+                     type NT is new T;
+                     -- inherits F as
+                     -- function F( X : NT := A ) return Integer;
+                     -- in Ada 95 only
+                     ...
+                  end P;
+                  ...
+                  use P;  -- Only one declaration of F from P is use-visible in
+                          -- Ada 83;  two declarations of F are use-visible in
+                          -- Ada 95.
+               begin
+                  ...
+                  if F > 1 then ... -- legal in Ada 83, ambiguous in Ada 95
+
+                        _Extensions to Ada 83_
+
+38.d
+          The syntax for a derived_type_definition is amended to include
+          an optional record_extension_part (see *note 3.9.1::).
+
+38.e
+          A derived type may override the discriminants of the parent by
+          giving a new discriminant_part.
+
+38.f
+          The parent type in a derived_type_definition may be a derived
+          type defined in the same visible part.
+
+38.g
+          When deriving from a type in the same visible part in which it
+          is defined, the primitive subprograms declared prior to the
+          derivation are inherited as primitive subprograms of the
+          derived type.  See *note 3.2.3::.
+
+                     _Wording Changes from Ada 83_
+
+38.h
+          We now talk about the classes to which a type belongs, rather
+          than a single class.
+
+                        _Extensions to Ada 95_
+
+38.i/2
+          {AI05-0190-1AI05-0190-1} {AI95-00251-01AI95-00251-01}
+          {AI95-00401-01AI95-00401-01} A derived type may inherit from
+          multiple (interface) progenitors, as well as the parent type
+          -- see *note 3.9.4::, "*note 3.9.4:: Interface Types".
+
+38.j/2
+          {AI95-00419-01AI95-00419-01} A derived type may specify that
+          it is a limited type.  This is required for interface
+          ancestors (from which limitedness is not inherited), but it is
+          generally useful as documentation of limitedness.
+
+                     _Wording Changes from Ada 95_
+
+38.k/2
+          {AI95-00391-01AI95-00391-01} Defined the result of functions
+          for null extensions (which we no longer require to be
+          overridden - see *note 3.9.3::).
+
+38.l/2
+          {AI95-00442-01AI95-00442-01} Defined the term "category of
+          types" and used it in wording elsewhere; also specified the
+          language-defined categories that form classes of types (this
+          was never normatively specified in Ada 95).
+
+                   _Incompatibilities With Ada 2005_
+
+38.m/3
+          {AI05-0096-1AI05-0096-1} Correction: Added a (re)check that
+          limited type extensions never are derived from nonlimited
+          types in generic private parts.  This is disallowed as it
+          would make it possible to pass a limited object to a
+          nonlimited class-wide type, which could then be copied.  This
+          is only possible using Ada 2005 syntax, so examples in
+          existing programs should be rare.
+
+                    _Wording Changes from Ada 2005_
+
+38.n/3
+          {AI05-0110-1AI05-0110-1} Correction: Added wording to clarify
+          that the characteristics of derived types are formally defined
+          here.  (This is the only place in the Standard that actually
+          spells out what sorts of things are actually characteristics,
+          which is rather important.)
+
+38.o/3
+          {AI05-0164-1AI05-0164-1} Correction: Added wording to ensure
+          that anonymous access-to-subprogram types don't get modified
+          on derivation.
+
+* Menu:
+
+* 3.4.1 ::    Derivation Classes
+
+
+File: aarm2012.info,  Node: 3.4.1,  Up: 3.4
+
+3.4.1 Derivation Classes
+------------------------
+
+1
+In addition to the various language-defined classes of types, types can
+be grouped into derivation classes.
+
+                          _Static Semantics_
+
+2/2
+{AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01} A derived type
+is derived from its parent type directly; it is derived indirectly from
+any type from which its parent type is derived.  A derived type,
+interface type, type extension, task type, protected type, or formal
+derived type is also derived from every ancestor of each of its
+progenitor types, if any.  The derivation class of types for a type T
+(also called the class rooted at T) is the set consisting of T (the root
+type of the class) and all types derived from T (directly or indirectly)
+plus any associated universal or class-wide types (defined below).
+
+2.a
+          Discussion: Note that the definition of "derived from" is a
+          recursive definition.  We don't define a root type for all
+          interesting language-defined classes, though presumably we
+          could.
+
+2.b
+          To be honest: By the class-wide type "associated" with a type
+          T, we mean the type T'Class.  Similarly, the universal type
+          associated with root_integer, root_real, and root_fixed are
+          universal_integer, universal_real, and universal_fixed,
+          respectively.
+
+3/2
+{AI95-00230-01AI95-00230-01} Every type is either a specific type, a
+class-wide type, or a universal type.  A specific type is one defined by
+a type_declaration, a formal_type_declaration, or a full type definition
+embedded in another construct.  Class-wide and universal types are
+implicitly defined, to act as representatives for an entire class of
+types, as follows:
+
+3.a
+          To be honest: The root types root_integer, root_real, and
+          root_fixed are also specific types.  They are declared in the
+          specification of package Standard.
+
+4
+Class-wide types
+               Class-wide types are defined for [(and belong to)] each
+               derivation class rooted at a tagged type (see *note
+               3.9::).  Given a subtype S of a tagged type T, S'Class is
+               the subtype_mark for a corresponding subtype of the
+               tagged class-wide type T'Class.  Such types are called
+               "class-wide" because when a formal parameter is defined
+               to be of a class-wide type T'Class, an actual parameter
+               of any type in the derivation class rooted at T is
+               acceptable (see *note 8.6::).
+
+5
+               The set of values for a class-wide type T'Class is the
+               discriminated union of the set of values of each specific
+               type in the derivation class rooted at T (the tag acts as
+               the implicit discriminant -- see *note 3.9::).
+               Class-wide types have no primitive subprograms of their
+               own.  However, as explained in *note 3.9.2::, operands of
+               a class-wide type T'Class can be used as part of a
+               dispatching call on a primitive subprogram of the type T.
+               The only components [(including discriminants)] of
+               T'Class that are visible are those of T. If S is a first
+               subtype, then S'Class is a first subtype.
+
+5.a
+          Reason: We want S'Class to be a first subtype when S is, so
+          that an attribute_definition_clause (*note 13.3: S0309.) like
+          "for S'Class'Output use ...;" will be legal.
+
+6/2
+{AI95-00230-01AI95-00230-01} Universal types
+               Universal types are defined for [(and belong to)] the
+               integer, real, fixed point, and access classes, and are
+               referred to in this standard as respectively,
+               universal_integer, universal_real, universal_fixed, and
+               universal_access.  These are analogous to class-wide
+               types for these language-defined elementary classes.  As
+               with class-wide types, if a formal parameter is of a
+               universal type, then an actual parameter of any type in
+               the corresponding class is acceptable.  In addition, a
+               value of a universal type (including an integer or real
+               numeric_literal, or the literal null) is "universal" in
+               that it is acceptable where some particular type in the
+               class is expected (see *note 8.6::).
+
+7
+               The set of values of a universal type is the
+               undiscriminated union of the set of values possible for
+               any definable type in the associated class.  Like
+               class-wide types, universal types have no primitive
+               subprograms of their own.  However, their "universality"
+               allows them to be used as operands with the primitive
+               subprograms of any type in the corresponding class.
+
+7.a
+          Discussion: A class-wide type is only class-wide in one
+          direction, from specific to class-wide, whereas a universal
+          type is class-wide (universal) in both directions, from
+          specific to universal and back.
+
+7.b/2
+          {AI95-00230-01AI95-00230-01} We considered defining class-wide
+          or perhaps universal types for all derivation classes, not
+          just tagged classes and these four elementary classes.
+          However, this was felt to overly weaken the strong-typing
+          model in some situations.  Tagged types preserve strong type
+          distinctions thanks to the run-time tag.  Class-wide or
+          universal types for untagged types would weaken the
+          compile-time type distinctions without providing a
+          compensating run-time-checkable distinction.
+
+7.c
+          We considered defining standard names for the universal
+          numeric types so they could be used in formal parameter
+          specifications.  However, this was felt to impose an undue
+          implementation burden for some implementations.
+
+7.d
+          To be honest: Formally, the set of values of a universal type
+          is actually a copy of the undiscriminated union of the values
+          of the types in its class.  This is because we want each value
+          to have exactly one type, with explicit or implicit conversion
+          needed to go between types.  An alternative, consistent model
+          would be to associate a class, rather than a particular type,
+          with a value, even though any given expression would have a
+          particular type.  In that case, implicit type conversions
+          would not generally need to change the value, although an
+          associated subtype conversion might need to.
+
+8
+The integer and real numeric classes each have a specific root type in
+addition to their universal type, named respectively root_integer and
+root_real.
+
+9
+A class-wide or universal type is said to cover all of the types in its
+class.  A specific type covers only itself.
+
+10/2
+{AI95-00230-01AI95-00230-01} {AI95-00251-01AI95-00251-01} A specific
+type T2 is defined to be a descendant of a type T1 if T2 is the same as
+T1, or if T2 is derived (directly or indirectly) from T1.  A class-wide
+type T2'Class is defined to be a descendant of type T1 if T2 is a
+descendant of T1.  Similarly, the numeric universal types are defined to
+be descendants of the root types of their classes.  If a type T2 is a
+descendant of a type T1, then T1 is called an ancestor of T2.  An
+ultimate ancestor of a type is an ancestor of that type that is not
+itself a descendant of any other type.  Every untagged type has a unique
+ultimate ancestor.
+
+10.a
+          Ramification: A specific type is a descendant of itself.
+          Class-wide types are considered descendants of the
+          corresponding specific type, and do not have any descendants
+          of their own.
+
+10.b
+          A specific type is an ancestor of itself.  The root of a
+          derivation class is an ancestor of all types in the class,
+          including any class-wide types in the class.
+
+10.c
+          Discussion: The terms root, parent, ancestor, and ultimate
+          ancestor are all related.  For example:
+
+10.d/2
+             * {AI95-00251-01AI95-00251-01} Each type has at most one
+               parent, and one or more ancestor types; each untagged
+               type has exactly one ultimate ancestor.  In Ada 83, the
+               term "parent type" was sometimes used more generally to
+               include any ancestor type (e.g.  RM83-9.4(14)).  In Ada
+               95, we restrict parent to mean the immediate ancestor.
+
+10.e
+             * A class of types has at most one root type; a derivation
+               class has exactly one root type.
+
+10.f
+             * The root of a class is an ancestor of all of the types in
+               the class (including itself).
+
+10.g
+             * The type root_integer is the root of the integer class,
+               and is the ultimate ancestor of all integer types.  A
+               similar statement applies to root_real.
+
+10.h/2
+          Glossary entry: An ancestor of a type is the type itself or,
+          in the case of a type derived from other types, its parent
+          type or one of its progenitor types or one of their ancestors.
+          Note that ancestor and descendant are inverse relationships.
+
+10.i/2
+          Glossary entry: A type is a descendant of itself, its parent
+          and progenitor types, and their ancestors.  Note that
+          descendant and ancestor are inverse relationships.
+
+11
+An inherited component [(including an inherited discriminant)] of a
+derived type is inherited from a given ancestor of the type if the
+corresponding component was inherited by each derived type in the chain
+of derivations going back to the given ancestor.
+
+     NOTES
+
+12
+     23  Because operands of a universal type are acceptable to the
+     predefined operators of any type in their class, ambiguity can
+     result.  For universal_integer and universal_real, this potential
+     ambiguity is resolved by giving a preference (see *note 8.6::) to
+     the predefined operators of the corresponding root types
+     (root_integer and root_real, respectively).  Hence, in an
+     apparently ambiguous expression like
+
+13
+          1 + 4 < 7
+
+14
+     where each of the literals is of type universal_integer, the
+     predefined operators of root_integer will be preferred over those
+     of other specific integer types, thereby resolving the ambiguity.
+
+14.a
+          Ramification: Except for this preference, a root numeric type
+          is essentially like any other specific type in the associated
+          numeric class.  In particular, the result of a predefined
+          operator of a root numeric type is not "universal" (implicitly
+          convertible) even if both operands were.
+
+                     _Wording Changes from Ada 95_
+
+14.b/2
+          {AI95-00230-01AI95-00230-01} Updated the wording to define the
+          universal_access type.  This was defined to make null for
+          anonymous access types sensible.
+
+14.c/2
+          {AI95-00251-01AI95-00251-01} {AI95-00401-01AI95-00401-01} The
+          definitions of ancestors and descendants were updated to allow
+          multiple ancestors (necessary to support interfaces).
+
+
+File: aarm2012.info,  Node: 3.5,  Next: 3.6,  Prev: 3.4,  Up: 3
+
+3.5 Scalar Types
+================
+
+1
+Scalar types comprise enumeration types, integer types, and real types.
+Enumeration types and integer types are called discrete types; each
+value of a discrete type has a position number which is an integer
+value.  Integer types and real types are called numeric types.  [All
+scalar types are ordered, that is, all relational operators are
+predefined for their values.]
+
+                               _Syntax_
+
+2
+     range_constraint ::=  range range
+
+3
+     range ::=  range_attribute_reference
+        | simple_expression .. simple_expression
+
+3.a
+          Discussion: These need to be simple_expressions rather than
+          more general expressions because ranges appear in membership
+          tests and other contexts where expression ..  expression would
+          be ambiguous.
+
+4
+A range has a lower bound and an upper bound and specifies a subset of
+the values of some scalar type (the type of the range).  A range with
+lower bound L and upper bound R is described by "L ..  R". If R is less
+than L, then the range is a null range, and specifies an empty set of
+values.  Otherwise, the range specifies the values of the type from the
+lower bound to the upper bound, inclusive.  A value belongs to a range
+if it is of the type of the range, and is in the subset of values
+specified by the range.  A value satisfies a range constraint if it
+belongs to the associated range.  One range is included in another if
+all values that belong to the first range also belong to the second.
+
+                        _Name Resolution Rules_
+
+5
+For a subtype_indication containing a range_constraint, either directly
+or as part of some other scalar_constraint, the type of the range shall
+resolve to that of the type determined by the subtype_mark of the
+subtype_indication.  For a range of a given type, the simple_expressions
+of the range (likewise, the simple_expressions of the equivalent range
+for a range_attribute_reference) are expected to be of the type of the
+range.
+
+5.a
+          Discussion: In Ada 95, constraints only appear within
+          subtype_indications; things that look like constraints that
+          appear in type declarations are called something else like
+          real_range_specifications.
+
+5.b/3
+          {AI05-0299-1AI05-0299-1} We say "the expected type is ..."  or
+          "the type is expected to be ..."  depending on which reads
+          better.  They are fundamentally equivalent, and both feed into
+          the type resolution rules of subclause *note 8.6::.
+
+5.c
+          In some cases, it doesn't work to use expected types.  For
+          example, in the above rule, we say that the "type of the range
+          shall resolve to ..."  rather than "the expected type for the
+          range is ...".  We then use "expected type" for the bounds.
+          If we used "expected" at both points, there would be an
+          ambiguity, since one could apply the rules of *note 8.6::
+          either on determining the type of the range, or on determining
+          the types of the individual bounds.  It is clearly important
+          to allow one bound to be of a universal type, and the other of
+          a specific type, so we need to use "expected type" for the
+          bounds.  Hence, we used "shall resolve to" for the type of the
+          range as a whole.  There are other situations where "expected
+          type" is not quite right, and we use "shall resolve to"
+          instead.
+
+                          _Static Semantics_
+
+6
+The base range of a scalar type is the range of finite values of the
+type that can be represented in every unconstrained object of the type;
+it is also the range supported at a minimum for intermediate values
+during the evaluation of expressions involving predefined operators of
+the type.
+
+6.a
+          Implementation Note: Note that in some machine architectures
+          intermediates in an expression (particularly if static), and
+          register-resident variables might accommodate a wider range.
+          The base range does not include the values of this wider range
+          that are not assignable without overflow to memory-resident
+          objects.
+
+6.b
+          Ramification: The base range of an enumeration type is the
+          range of values of the enumeration type.
+
+6.c
+          Reason: If the representation supports infinities, the base
+          range is nevertheless restricted to include only the
+          representable finite values, so that 'Base'First and
+          'Base'Last are always guaranteed to be finite.
+
+6.d
+          To be honest: By a "value that can be assigned without
+          overflow" we don't mean to restrict ourselves to values that
+          can be represented exactly.  Values between machine
+          representable values can be assigned, but on subsequent
+          reading, a slightly different value might be retrieved, as
+          (partially) determined by the number of digits of precision of
+          the type.
+
+7
+[A constrained scalar subtype is one to which a range constraint
+applies.]  The range of a constrained scalar subtype is the range
+associated with the range constraint of the subtype.  The range of an
+unconstrained scalar subtype is the base range of its type.
+
+                          _Dynamic Semantics_
+
+8
+A range is compatible with a scalar subtype if and only if it is either
+a null range or each bound of the range belongs to the range of the
+subtype.  A range_constraint is compatible with a scalar subtype if and
+only if its range is compatible with the subtype.
+
+8.a
+          Ramification: Only range_constraints (explicit or implicit)
+          impose conditions on the values of a scalar subtype.  The
+          other scalar_constraints, digits_constraints and
+          delta_constraints impose conditions on the subtype denoted by
+          the subtype_mark in a subtype_indication, but don't impose a
+          condition on the values of the subtype being defined.
+          Therefore, a scalar subtype is not called constrained if all
+          that applies to it is a digits_constraint.  Decimal subtypes
+          are subtle, because a digits_constraint without a
+          range_constraint nevertheless includes an implicit
+          range_constraint.
+
+9
+The elaboration of a range_constraint consists of the evaluation of the
+range.  The evaluation of a range determines a lower bound and an upper
+bound.  If simple_expressions are given to specify bounds, the
+evaluation of the range evaluates these simple_expressions in an
+arbitrary order, and converts them to the type of the range.  If a
+range_attribute_reference is given, the evaluation of the range consists
+of the evaluation of the range_attribute_reference.
+
+10
+Attributes
+
+11
+For every scalar subtype S, the following attributes are defined:
+
+12
+S'First
+               S'First denotes the lower bound of the range of S. The
+               value of this attribute is of the type of S.
+
+12.a
+          Ramification: Evaluating S'First never raises
+          Constraint_Error.
+
+13
+S'Last
+               S'Last denotes the upper bound of the range of S. The
+               value of this attribute is of the type of S.
+
+13.a
+          Ramification: Evaluating S'Last never raises Constraint_Error.
+
+14
+S'Range
+               S'Range is equivalent to the range S'First ..  S'Last.
+
+15
+S'Base
+               S'Base denotes an unconstrained subtype of the type of S.
+               This unconstrained subtype is called the base subtype of
+               the type.  
+
+16
+S'Min
+               S'Min denotes a function with the following
+               specification:
+
+17
+                    function S'Min(Left, Right : S'Base)
+                      return S'Base
+
+18
+               The function returns the lesser of the values of the two
+               parameters.
+
+18.a
+          Discussion: The formal parameter names are italicized because
+          they cannot be used in calls -- see *note 6.4::.  Such a
+          specification cannot be written by the user because an
+          attribute_reference is not permitted as the designator of a
+          user-defined function, nor can its formal parameters be
+          anonymous.
+
+19
+S'Max
+               S'Max denotes a function with the following
+               specification:
+
+20
+                    function S'Max(Left, Right : S'Base)
+                      return S'Base
+
+21
+               The function returns the greater of the values of the two
+               parameters.
+
+22
+S'Succ
+               S'Succ denotes a function with the following
+               specification:
+
+23
+                    function S'Succ(Arg : S'Base)
+                      return S'Base
+
+24
+               For an enumeration type, the function returns the value
+               whose position number is one more than that of the value
+               of Arg; Constraint_Error is raised if there is no such
+               value of the type.  For an integer type, the function
+               returns the result of adding one to the value of Arg.
+               For a fixed point type, the function returns the result
+               of adding small to the value of Arg.  For a floating
+               point type, the function returns the machine number (as
+               defined in *note 3.5.7::) immediately above the value of
+               Arg; Constraint_Error is raised if there is no such
+               machine number.
+
+24.a
+          Ramification: S'Succ for a modular integer subtype wraps
+          around if the value of Arg is S'Base'Last.  S'Succ for a
+          signed integer subtype might raise Constraint_Error if the
+          value of Arg is S'Base'Last, or it might return the
+          out-of-base-range value S'Base'Last+1, as is permitted for all
+          predefined numeric operations.
+
+25
+S'Pred
+               S'Pred denotes a function with the following
+               specification:
+
+26
+                    function S'Pred(Arg : S'Base)
+                      return S'Base
+
+27
+               For an enumeration type, the function returns the value
+               whose position number is one less than that of the value
+               of Arg; Constraint_Error is raised if there is no such
+               value of the type.  For an integer type, the function
+               returns the result of subtracting one from the value of
+               Arg.  For a fixed point type, the function returns the
+               result of subtracting small from the value of Arg.  For a
+               floating point type, the function returns the machine
+               number (as defined in *note 3.5.7::) immediately below
+               the value of Arg; Constraint_Error is raised if there is
+               no such machine number.
+
+27.a
+          Ramification: S'Pred for a modular integer subtype wraps
+          around if the value of Arg is S'Base'First.  S'Pred for a
+          signed integer subtype might raise Constraint_Error if the
+          value of Arg is S'Base'First, or it might return the
+          out-of-base-range value S'Base'First-1, as is permitted for
+          all predefined numeric operations.
+
+27.1/2
+S'Wide_Wide_Image
+               {AI95-00285-01AI95-00285-01} S'Wide_Wide_Image denotes a
+               function with the following specification:
+
+27.2/2
+                    function S'Wide_Wide_Image(Arg : S'Base)
+                      return Wide_Wide_String
+
+27.3/2
+               The function returns an image of the value of Arg, that
+               is, a sequence of characters representing the value in
+               display form.  The lower bound of the result is one.
+
+27.4/2
+               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.
+
+27.b/2
+          Implementation Note: If the machine supports negative zeros
+          for signed integer types, it is not specified whether " 0" or
+          "-0" should be returned for negative zero.  We don't have
+          enough experience with such machines to know what is
+          appropriate, and what other languages do.  In any case, the
+          implementation should be consistent.
+
+27.5/2
+               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.  For a nongraphic character (a value of a
+               character type that has no enumeration literal associated
+               with it), the result is a corresponding language-defined
+               name in upper case (for example, the image of the
+               nongraphic character identified as nul is "NUL" -- the
+               quotes are not part of the image).
+
+27.c/2
+          Implementation Note: For an enumeration type T that has
+          "holes" (caused by an enumeration_representation_clause (*note
+          13.4: S0310.)), T'Wide_Image should raise Program_Error if the
+          value is one of the holes (which is a bounded error anyway,
+          since holes can be generated only via uninitialized variables
+          and similar things).
+
+27.6/2
+               The image of a floating point value is a decimal real
+               literal best approximating the value (rounded away from
+               zero if halfway between) with a single leading character
+               that is either a minus sign or a space, a single digit
+               (that is nonzero unless the value is zero), a decimal
+               point, S'Digits-1 (see *note 3.5.8::) digits after the
+               decimal point (but one if S'Digits is one), an upper case
+               E, the sign of the exponent (either + or -), and two or
+               more digits (with leading zeros if necessary)
+               representing the exponent.  If S'Signed_Zeros is True,
+               then the leading character is a minus sign for a
+               negatively signed zero.
+
+27.d/2
+          To be honest: Leading zeros are present in the exponent only
+          if necessary to make the exponent at least two digits.
+
+27.e/2
+          Reason: This image is intended to conform to that produced by
+          Text_IO.Float_IO.Put in its default format.
+
+27.f/2
+          Implementation Note: The rounding direction is specified here
+          to ensure portability of output results.
+
+27.7/2
+               The image of a fixed point value is a decimal real
+               literal best approximating the value (rounded away from
+               zero if halfway between) with a single leading character
+               that is either a minus sign or a space, one or more
+               digits before the decimal point (with no redundant
+               leading zeros), a decimal point, and S'Aft (see *note
+               3.5.10::) digits after the decimal point.
+
+27.g/2
+          Reason: This image is intended to conform to that produced by
+          Text_IO.Fixed_IO.Put.
+
+27.h/2
+          Implementation Note: The rounding direction is specified here
+          to ensure portability of output results.
+
+27.i/2
+          Implementation Note: For a machine that supports negative
+          zeros, it is not specified whether " 0.000" or "-0.000" is
+          returned.  See corresponding comment above about integer types
+          with signed zeros.
+
+28
+S'Wide_Image
+               S'Wide_Image denotes a function with the following
+               specification:
+
+29
+                    function S'Wide_Image(Arg : S'Base)
+                      return Wide_String
+
+30/3
+               {AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1}
+               {AI05-0264-1AI05-0264-1} The function returns an image of
+               the value of Arg as a Wide_String.  The lower bound of
+               the result is one.  The image has the same sequence of
+               graphic characters as defined for S'Wide_Wide_Image if
+               all the graphic characters are defined in Wide_Character;
+               otherwise, the sequence of characters is implementation
+               defined (but no shorter than that of S'Wide_Wide_Image
+               for the same value of Arg).
+
+30.a/2
+          Implementation defined: The sequence of characters of the
+          value returned by S'Wide_Image when some of the graphic
+          characters of S'Wide_Wide_Image are not defined in
+          Wide_Character.
+
+               Paragraphs 31 through 34 were moved to Wide_Wide_Image.
+
+35
+S'Image
+               S'Image denotes a function with the following
+               specification:
+
+36
+                    function S'Image(Arg : S'Base)
+                      return String
+
+37/3
+               {AI95-00285-01AI95-00285-01} {AI05-0264-1AI05-0264-1} The
+               function returns an image of the value of Arg as a
+               String.  The lower bound of the result is one.  The image
+               has the same sequence of graphic characters as that
+               defined for S'Wide_Wide_Image if all the graphic
+               characters are defined in Character; otherwise, the
+               sequence of characters is implementation defined (but no
+               shorter than that of S'Wide_Wide_Image for the same value
+               of Arg).
+
+37.a/2
+          Implementation defined: The sequence of characters of the
+          value returned by S'Image when some of the graphic characters
+          of S'Wide_Wide_Image are not defined in Character.
+
+37.1/2
+S'Wide_Wide_Width
+               {AI95-00285-01AI95-00285-01} S'Wide_Wide_Width denotes
+               the maximum length of a Wide_Wide_String returned by
+               S'Wide_Wide_Image over all values of the subtype S. It
+               denotes zero for a subtype that has a null range.  Its
+               type is universal_integer.
+
+38
+S'Wide_Width
+               S'Wide_Width denotes the maximum length of a Wide_String
+               returned by S'Wide_Image over all values of the subtype
+               S. It denotes zero for a subtype that has a null range.
+               Its type is universal_integer.
+
+39
+S'Width
+               S'Width denotes the maximum length of a String returned
+               by S'Image over all values of the subtype S. It denotes
+               zero for a subtype that has a null range.  Its type is
+               universal_integer.
+
+39.1/2
+S'Wide_Wide_Value
+               {AI95-00285-01AI95-00285-01} S'Wide_Wide_Value denotes a
+               function with the following specification:
+
+39.2/2
+                    function S'Wide_Wide_Value(Arg : Wide_Wide_String)
+                      return S'Base
+
+39.3/2
+               This function returns a value given an image of the value
+               as a Wide_Wide_String, ignoring any leading or trailing
+               spaces.
+
+39.4/3
+               {AI05-0264-1AI05-0264-1} For the evaluation of a call on
+               S'Wide_Wide_Value for an enumeration subtype S, if the
+               sequence of characters of the parameter (ignoring leading
+               and trailing spaces) has the syntax of an enumeration
+               literal and if it corresponds to a literal of the type of
+               S (or corresponds to the result of S'Wide_Wide_Image for
+               a nongraphic character of the type), the result is the
+               corresponding enumeration value; otherwise,
+               Constraint_Error is raised.
+
+39.a.1/2
+          Discussion: It's not crystal clear that Range_Check is
+          appropriate here, but it doesn't seem worthwhile to invent a
+          whole new check name just for this weird case, so we decided
+          to lump it in with Range_Check.
+
+39.a.2/2
+          To be honest: {8652/00968652/0096}
+          {AI95-00053-01AI95-00053-01} A sequence of characters
+          corresponds to the result of S'Wide_Wide_Image if it is the
+          same ignoring case.  Thus, the case of an image of a
+          nongraphic character does not matter.  For example,
+          Character'Wide_Wide_Value("nul") does not raise
+          Constraint_Error, even though Character'Wide_Wide_Image
+          returns "NUL" for the nul character.
+
+39.5/3
+               {AI05-0264-1AI05-0264-1} For the evaluation of a call on
+               S'Wide_Wide_Value for an integer subtype S, if the
+               sequence of characters of the parameter (ignoring leading
+               and trailing spaces) has the syntax of an integer
+               literal, with an optional leading sign character (plus or
+               minus for a signed type; only plus for a modular type),
+               and the corresponding numeric value belongs to the base
+               range of the type of S, then that value is the result; 
+               otherwise, Constraint_Error is raised.
+
+39.a.3/2
+          Discussion: We considered allowing 'Value to return a
+          representable but out-of-range value without a
+          Constraint_Error.  However, we currently require (see *note
+          4.9::) in an assignment_statement like "X :=
+          <numeric_literal>;" that the value of the numeric-literal be
+          in X's base range (at compile time), so it seems unfriendly
+          and confusing to have a different range allowed for 'Value.
+          Furthermore, for modular types, without the requirement for
+          being in the base range, 'Value would have to handle
+          arbitrarily long literals (since overflow never occurs for
+          modular types).
+
+39.6/2
+               For the evaluation of a call on S'Wide_Wide_Value for a
+               real subtype S, if the sequence of characters of the
+               parameter (ignoring leading and trailing spaces) has the
+               syntax of one of the following:
+
+39.7/2
+                  * numeric_literal
+
+39.8/2
+                  * numeral.[exponent]
+
+39.9/2
+                  * .numeral[exponent]
+
+39.10/2
+                  * base#based_numeral.#[exponent]
+
+39.11/2
+                  * base#.based_numeral#[exponent]
+
+39.12/3
+               {AI05-0264-1AI05-0264-1} with an optional leading sign
+               character (plus or minus), and if the corresponding
+               numeric value belongs to the base range of the type of S,
+               then that value is the result; otherwise,
+               Constraint_Error is raised.  The sign of a zero value is
+               preserved (positive if none has been specified) if
+               S'Signed_Zeros is True.
+
+40
+S'Wide_Value
+               S'Wide_Value denotes a function with the following
+               specification:
+
+41
+                    function S'Wide_Value(Arg : Wide_String)
+                      return S'Base
+
+42
+               This function returns a value given an image of the value
+               as a Wide_String, ignoring any leading or trailing
+               spaces.
+
+43/3
+               {AI95-00285-01AI95-00285-01} {AI05-0264-1AI05-0264-1} For
+               the evaluation of a call on S'Wide_Value for an
+               enumeration subtype S, if the sequence of characters of
+               the parameter (ignoring leading and trailing spaces) has
+               the syntax of an enumeration literal and if it
+               corresponds to a literal of the type of S (or corresponds
+               to the result of S'Wide_Image for a value of the type),
+               the result is the corresponding enumeration value; 
+               otherwise, Constraint_Error is raised.  For a numeric
+               subtype S, the evaluation of a call on S'Wide_Value with
+               Arg of type Wide_String is equivalent to a call on
+               S'Wide_Wide_Value for a corresponding Arg of type
+               Wide_Wide_String.
+
+43.a/2
+          This paragraph was deleted.
+
+43.a.1/2
+          This paragraph was deleted.{8652/00968652/0096}
+          {AI95-00053-01AI95-00053-01}
+
+43.b/2
+          Reason: S'Wide_Value is subtly different from
+          S'Wide_Wide_Value for enumeration subtypes since S'Wide_Image
+          might produce a different sequence of characters than
+          S'Wide_Wide_Image if the enumeration literal uses characters
+          outside of the predefined type Wide_Character.  That is why we
+          don't just define S'Wide_Value in terms of S'Wide_Wide_Value
+          for enumeration subtypes.  S'Wide_Value and S'Wide_Wide_Value
+          for numeric subtypes yield the same result given the same
+          sequence of characters.
+
+               Paragraphs 44 through 51 were moved to Wide_Wide_Value.
+
+52
+S'Value
+               S'Value denotes a function with the following
+               specification:
+
+53
+                    function S'Value(Arg : String)
+                      return S'Base
+
+54
+               This function returns a value given an image of the value
+               as a String, ignoring any leading or trailing spaces.
+
+55/3
+               {AI95-00285-01AI95-00285-01} {AI05-0264-1AI05-0264-1} For
+               the evaluation of a call on S'Value for an enumeration
+               subtype S, if the sequence of characters of the parameter
+               (ignoring leading and trailing spaces) has the syntax of
+               an enumeration literal and if it corresponds to a literal
+               of the type of S (or corresponds to the result of S'Image
+               for a value of the type), the result is the corresponding
+               enumeration value; otherwise, Constraint_Error is raised.
+               For a numeric subtype S, the evaluation of a call on
+               S'Value with Arg of type String is equivalent to a call
+               on S'Wide_Wide_Value for a corresponding Arg of type
+               Wide_Wide_String.
+
+55.a/2
+          Reason: {AI95-00285-01AI95-00285-01} S'Value is subtly
+          different from S'Wide_Wide_Value for enumeration subtypes; see
+          the discussion under S'Wide_Value.
+
+                     _Implementation Permissions_
+
+56/2
+{AI95-00285-01AI95-00285-01} An implementation may extend the
+Wide_Wide_Value, [Wide_Value, Value, Wide_Wide_Image, Wide_Image, and
+Image] attributes of a floating point type to support special values
+such as infinities and NaNs.
+
+56.a/2
+          Proof: {AI95-00285-01AI95-00285-01} The permission is really
+          only necessary for Wide_Wide_Value, because Value and
+          Wide_Value are defined in terms of Wide_Wide_Value, and
+          because the behavior of Wide_Wide_Image, Wide_Image, and Image
+          is already unspecified for things like infinities and NaNs.
+
+56.b
+          Reason: This is to allow implementations to define full
+          support for IEEE arithmetic.  See also the similar permission
+          for Get in *note A.10.9::.
+
+56.1/3
+{AI05-0182-1AI05-0182-1} {AI05-0262-1AI05-0262-1}
+{AI05-0269-1AI05-0269-1} An implementation may extend the
+Wide_Wide_Value, Wide_Value, and Value attributes of a character type to
+accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any
+character (not just the ones for which Wide_Wide_Image would produce
+that form -- see *note 3.5.2::), as well as three-character strings of
+the form "'X'", where X is any character, including nongraphic
+characters.
+
+                          _Static Semantics_
+
+56.2/3
+{AI05-0228-1AI05-0228-1} For a scalar type, the following
+language-defined representation aspect may be specified with an
+aspect_specification (see *note 13.1.1::):
+
+56.3/3
+Default_Value
+               This aspect shall be specified by a static expression,
+               and that expression shall be explicit, even if the aspect
+               has a boolean type.  Default_Value shall be specified
+               only on a full_type_declaration.
+
+56.c/3
+          Reason: The part about requiring an explicit expression is to
+          disallow omitting the value for this aspect, which would
+          otherwise be allowed by the rules of *note 13.1.1::.
+
+56.d/3
+          This is a representation aspect in order to disallow
+          specifying it on a derived type that has inherited primitive
+          subprograms; that is necessary as the sizes of out parameters
+          could be different whether or not a Default_Value is specified
+          (see *note 6.4.1::).
+
+56.e/3
+          Aspect Description for Default_Value: Default value for a
+          scalar subtype.
+
+56.4/3
+{AI05-0228-1AI05-0228-1} If a derived type with no primitive subprograms
+inherits a boolean Default_Value aspect, the aspect may be specified to
+have any value for the derived type.
+
+56.f/3
+          Reason: This overrides the *note 13.1.1:: rule that says that
+          a boolean aspect with a value True cannot be changed.
+
+                        _Name Resolution Rules_
+
+56.5/3
+{AI05-0228-1AI05-0228-1} The expected type for the expression specified
+for the Default_Value aspect is the type defined by the
+full_type_declaration on which it appears.
+
+     NOTES
+
+57
+     24  The evaluation of S'First or S'Last never raises an exception.
+     If a scalar subtype S has a nonnull range, S'First and S'Last
+     belong to this range.  These values can, for example, always be
+     assigned to a variable of subtype S.
+
+57.a
+          Discussion: This paragraph addresses an issue that came up
+          with Ada 83, where for fixed point types, the end points of
+          the range specified in the type definition were not
+          necessarily within the base range of the type.  However, it
+          was later clarified (and we reconfirm it in *note 3.5.9::,
+          "*note 3.5.9:: Fixed Point Types") that the First and Last
+          attributes reflect the true bounds chosen for the type, not
+          the bounds specified in the type definition (which might be
+          outside the ultimately chosen base range).
+
+58
+     25  For a subtype of a scalar type, the result delivered by the
+     attributes Succ, Pred, and Value might not belong to the subtype;
+     similarly, the actual parameters of the attributes Succ, Pred, and
+     Image need not belong to the subtype.
+
+59
+     26  For any value V (including any nongraphic character) of an
+     enumeration subtype S, S'Value(S'Image(V)) equals V, as do
+     S'Wide_Value(S'Wide_Image(V)) and
+     S'Wide_Wide_Value(S'Wide_Wide_Image(V)). None of these expressions
+     ever raise Constraint_Error.
+
+                              _Examples_
+
+60
+Examples of ranges:
+
+61
+     -10 .. 10
+     X .. X + 1
+     0.0 .. 2.0*Pi
+     Red .. Green     -- see *note 3.5.1::
+     1 .. 0           -- a null range
+     Table'Range      -- a range attribute reference (see *note 3.6::)
+
+62
+Examples of range constraints:
+
+63
+     range -999.0 .. +999.0
+     range S'First+1 .. S'Last-1
+
+                    _Incompatibilities With Ada 83_
+
+63.a/1
+          S'Base is no longer defined for nonscalar types.  One
+          conceivable existing use of S'Base for nonscalar types is
+          S'Base'Size where S is a generic formal private type.
+          However, that is not generally useful because the actual
+          subtype corresponding to S might be a constrained array or
+          discriminated type, which would mean that S'Base'Size might
+          very well overflow (for example, S'Base'Size where S is a
+          constrained subtype of String will generally be 8 *
+          (Integer'Last + 1)).  For derived discriminated types that are
+          packed, S'Base'Size might not even be well defined if the
+          first subtype is constrained, thereby allowing some amount of
+          normally required "dope" to have been squeezed out in the
+          packing.  Hence our conclusion is that S'Base'Size is not
+          generally useful in a generic, and does not justify keeping
+          the attribute Base for nonscalar types just so it can be used
+          as a prefix.
+
+                        _Extensions to Ada 83_
+
+63.b
+          The attribute S'Base for a scalar subtype is now permitted
+          anywhere a subtype_mark is permitted.  S'Base'First ..
+          S'Base'Last is the base range of the type.  Using an
+          attribute_definition_clause (*note 13.3: S0309.), one cannot
+          specify any subtype-specific attributes for the subtype
+          denoted by S'Base (the base subtype).
+
+63.c
+          The attribute S'Range is now allowed for scalar subtypes.
+
+63.d
+          The attributes S'Min and S'Max are now defined, and made
+          available for all scalar types.
+
+63.e
+          The attributes S'Succ, S'Pred, S'Image, S'Value, and S'Width
+          are now defined for real types as well as discrete types.
+
+63.f
+          Wide_String versions of S'Image and S'Value are defined.
+          These are called S'Wide_Image and S'Wide_Value to avoid
+          introducing ambiguities involving uses of these attributes
+          with string literals.
+
+                     _Wording Changes from Ada 83_
+
+63.g
+          We now use the syntactic category range_attribute_reference
+          since it is now syntactically distinguished from other
+          attribute references.
+
+63.h
+          The definition of S'Base has been moved here from 3.3.3 since
+          it now applies only to scalar types.
+
+63.i
+          More explicit rules are provided for nongraphic characters.
+
+                        _Extensions to Ada 95_
+
+63.j/2
+          {AI95-00285-01AI95-00285-01} The attributes Wide_Wide_Image,
+          Wide_Wide_Value, and Wide_Wide_Width are new.  Note that
+          Wide_Image and Wide_Value are now defined in terms of
+          Wide_Wide_Image and Wide_Wide_Value, but the image of types
+          other than characters have not changed.
+
+                     _Wording Changes from Ada 95_
+
+63.k/2
+          {AI95-00285-01AI95-00285-01} The Wide_Image and Wide_Value
+          attributes are now defined in terms of Wide_Wide_Image and
+          Wide_Wide_Value, but the images of numeric types have not
+          changed.
+
+                    _Inconsistencies With Ada 2005_
+
+63.l/3
+          {AI05-0181-1AI05-0181-1} Correction: Soft hyphen (code point
+          173) is nongraphic in ISO/IEC 10646:2011 (and also in the 2003
+          version of that standard).  Thus, we have given it the
+          language-defined name soft_hyphen.  This changes the result of
+          Character'Image (and all of the related types and Image
+          attributes) for this character, and changes the behavior of
+          Character'Value (and all of the related types and Value
+          attributes) for this character, and (in unusual
+          circumstances), changes the result for Character'Width (and
+          all of the related types and Width attributes).  The vast
+          majority of programs won't see any difference, as they are
+          already prepared to handle nongraphic characters.
+
+63.m/3
+          {AI05-0182-1AI05-0182-1} Correction: Added an Implementation
+          Permissions to let Wide_Wide_Value, Wide_Value, and Value
+          accept strings in the form of literals containing nongraphic
+          characters and "Hex_hhhhhhhh" for Latin-1 and graphic
+          characters.  These were required to raise Constraint_Error in
+          Ada 2005.  Since these attributes aren't very useful,
+          implementations were inconsistent as to whether these were
+          accepted, and since code that would care why the attribute
+          failed seems unlikely, this should not be a problem in
+          practice.
+
+                       _Extensions to Ada 2005_
+
+63.n/3
+          {AI05-0228-1AI05-0228-1} The new aspect Default_Value allows
+          defining implicit initial values (see *note 3.3.1::) for
+          scalar types.
+
+* Menu:
+
+* 3.5.1 ::    Enumeration Types
+* 3.5.2 ::    Character Types
+* 3.5.3 ::    Boolean Types
+* 3.5.4 ::    Integer Types
+* 3.5.5 ::    Operations of Discrete Types
+* 3.5.6 ::    Real Types
+* 3.5.7 ::    Floating Point Types
+* 3.5.8 ::    Operations of Floating Point Types
+* 3.5.9 ::    Fixed Point Types
+* 3.5.10 ::   Operations of Fixed Point Types
+
+
+File: aarm2012.info,  Node: 3.5.1,  Next: 3.5.2,  Up: 3.5
+
+3.5.1 Enumeration Types
+-----------------------
+
+1
+[ An enumeration_type_definition defines an enumeration type.]
+
+                               _Syntax_
+
+2
+     enumeration_type_definition ::=
+        (enumeration_literal_specification {, 
+     enumeration_literal_specification})
+
+3
+     enumeration_literal_specification ::=  defining_identifier | 
+     defining_character_literal
+
+4
+     defining_character_literal ::= character_literal
+
+                           _Legality Rules_
+
+5/3
+{AI05-0227-1AI05-0227-1} {AI05-0299-1AI05-0299-1} The
+defining_identifiers in upper case [and the defining_character_literals]
+listed in an enumeration_type_definition shall be distinct.
+
+5.a/3
+          Proof: {AI05-0227-1AI05-0227-1} For character literals, this
+          is a ramification of the normal disallowance of homographs
+          explicitly declared immediately in the same declarative
+          region.
+
+5.b/3
+          Reason: {AI05-0227-1AI05-0227-1} To ease implementation of the
+          attribute Wide_Wide_Value, we require that all enumeration
+          literals have distinct images.
+
+                          _Static Semantics_
+
+6/3
+{AI05-0006-1AI05-0006-1} Each enumeration_literal_specification is the
+explicit declaration of the corresponding enumeration literal: it
+declares a parameterless function, whose defining name is the
+defining_identifier (*note 3.1: S0022.) or defining_character_literal
+(*note 3.5.1: S0040.), and whose result subtype is the base subtype of
+the enumeration type.
+
+6.a
+          Reason: This rule defines the profile of the enumeration
+          literal, which is used in the various types of conformance.
+
+6.b
+          Ramification: The parameterless function associated with an
+          enumeration literal is fully defined by the
+          enumeration_type_definition; a body is not permitted for it,
+          and it never fails the Elaboration_Check when called.
+
+6.c/3
+          Discussion: {AI05-0006-1AI05-0006-1} The result subtype is
+          primarily a concern when an enumeration literal is used as the
+          expression of a case statement, due to the full coverage
+          requirement based on the nominal subtype.
+
+7
+Each enumeration literal corresponds to a distinct value of the
+enumeration type, and to a distinct position number.  The position
+number of the value of the first listed enumeration literal is zero; the
+position number of the value of each subsequent enumeration literal is
+one more than that of its predecessor in the list.
+
+8
+[The predefined order relations between values of the enumeration type
+follow the order of corresponding position numbers.]
+
+9
+[ If the same defining_identifier or defining_character_literal is
+specified in more than one enumeration_type_definition (*note 3.5.1:
+S0038.), the corresponding enumeration literals are said to be
+overloaded.  At any place where an overloaded enumeration literal occurs
+in the text of a program, the type of the enumeration literal has to be
+determinable from the context (see *note 8.6::).]
+
+                          _Dynamic Semantics_
+
+10
+The elaboration of an enumeration_type_definition creates the
+enumeration type and its first subtype, which is constrained to the base
+range of the type.
+
+10.a
+          Ramification: The first subtype of a discrete type is always
+          constrained, except in the case of a derived type whose parent
+          subtype is Whatever'Base.
+
+11
+When called, the parameterless function associated with an enumeration
+literal returns the corresponding value of the enumeration type.
+
+     NOTES
+
+12
+     27  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 *note 4.7::).
+
+                              _Examples_
+
+13
+Examples of enumeration types and subtypes:
+
+14
+     type Day    is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
+     type Suit   is (Clubs, Diamonds, Hearts, Spades);
+     type Gender is (M, F);
+     type Level  is (Low, Medium, Urgent);
+     type Color  is (White, Red, Yellow, Green, Blue, Brown, Black);
+     type Light  is (Red, Amber, Green); -- Red and Green are overloaded
+
+15
+     type Hexa   is ('A', 'B', 'C', 'D', 'E', 'F');
+     type Mixed  is ('A', 'B', '*', B, None, '?', '%');
+
+16
+     subtype Weekday is Day   range Mon .. Fri;
+     subtype Major   is Suit  range Hearts .. Spades;
+     subtype Rainbow is Color range Red .. Blue;  --  the Color Red, not the 
Light
+
+                     _Wording Changes from Ada 83_
+
+16.a
+          The syntax rule for defining_character_literal is new.  It is
+          used for the defining occurrence of a character_literal,
+          analogously to defining_identifier.  Usage occurrences use the
+          name or selector_name syntactic categories.
+
+16.b
+          We emphasize the fact that an enumeration literal denotes a
+          function, which is called to produce a value.
+
+                   _Incompatibilities With Ada 2005_
+
+16.c/3
+          {AI05-0227-1AI05-0227-1} Correction: Required that all
+          enumeration literals in a type have distinct images; this
+          might not be the case since upper case conversion can map
+          distinct characters to the same upper case character.  This
+          can only happen for identifiers using Unicode characters first
+          allowed by Ada 2005; moreover, the original definition of Ada
+          2005 was confused and appeared to require inconsistent results
+          from the Image attribute, so implementations that allowed
+          problematic cases are rare; the problematic cases are very
+          rare; so it is expected that this change would only affect
+          test programs.
+
+                    _Wording Changes from Ada 2005_
+
+16.d/3
+          {AI05-0006-1AI05-0006-1} Correction: Defined the result
+          subtype of an enumeration literal to close a minor language
+          hole.
+
+
+File: aarm2012.info,  Node: 3.5.2,  Next: 3.5.3,  Prev: 3.5.1,  Up: 3.5
+
+3.5.2 Character Types
+---------------------
+
+                          _Static Semantics_
+
+1
+An enumeration type is said to be a character type if at least one of
+its enumeration literals is a character_literal.
+
+2/3
+{AI95-00285-01AI95-00285-01} {AI05-0181-1AI05-0181-1}
+{AI05-0262-1AI05-0262-1} {AI05-0266-1AI05-0266-1} The predefined type
+Character is a character type whose values correspond to the 256 code
+points of Row 00 (also known as Latin-1) of the ISO/IEC 10646:2011 Basic
+Multilingual Plane (BMP). Each of the graphic characters of Row 00 of
+the BMP has a corresponding character_literal in Character.  Each of the
+nongraphic characters of Row 00 has a corresponding language-defined
+name, which is not usable as an enumeration literal, but which is usable
+with the attributes Image, Wide_Image, Wide_Wide_Image, Value,
+Wide_Value, and Wide_Wide_Value; these names are given in the definition
+of type Character in *note A.1::, "*note A.1:: The Package Standard",
+but are set in italics.  
+
+2.a/3
+          Discussion: {AI05-0262-1AI05-0262-1} Code point is defined in
+          ISO/IEC 10646:2011.
+
+3/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The predefined
+type Wide_Character is a character type whose values correspond to the
+65536 code points of the ISO/IEC 10646:2011 Basic Multilingual Plane
+(BMP). Each of the graphic characters of the BMP has a corresponding
+character_literal in Wide_Character.  The first 256 values of
+Wide_Character have the same character_literal or language-defined name
+as defined for Character.  Each of the graphic_characters has a
+corresponding character_literal.
+
+4/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The predefined
+type Wide_Wide_Character is a character type whose values correspond to
+the 2147483648 code points of the ISO/IEC 10646:2011 character set.
+Each of the graphic_characters has a corresponding character_literal in
+Wide_Wide_Character.  The first 65536 values of Wide_Wide_Character have
+the same character_literal or language-defined name as defined for
+Wide_Character.
+
+5/3
+{AI95-00285-01AI95-00285-01} {AI05-0262-1AI05-0262-1} The characters
+whose code point is larger than 16#FF# and which are not
+graphic_characters have language-defined names which are formed by
+appending to the string "Hex_" the representation of their code point in
+hexadecimal as eight extended digits.  As with other language-defined
+names, these names are usable only with the attributes (Wide_)Wide_Image
+and (Wide_)Wide_Value; they are not usable as enumeration literals.
+
+5.a/2
+          Reason: {AI95-00285-01AI95-00285-01} The language-defined
+          names are not usable as enumeration literals to avoid
+          "polluting" the name space.  Since Wide_Character and
+          Wide_Wide_Character are defined in Standard, if the
+          language-defined names were usable as enumeration literals,
+          they would hide other nonoverloadable declarations with the
+          same names in use-d packages.]}
+
+Paragraphs 6 and 7 were deleted.
+
+     NOTES
+
+8
+     28  The language-defined library package Characters.Latin_1 (see
+     *note A.3.3::) includes the declaration of constants denoting
+     control characters, lower case characters, and special characters
+     of the predefined type Character.
+
+8.a
+          To be honest: The package ASCII does the same, but only for
+          the first 128 characters of Character.  Hence, it is an
+          obsolescent package, and we no longer mention it here.
+
+9/3
+     29  {AI05-0299-1AI05-0299-1} A conventional character set such as
+     EBCDIC can be declared as a character type; the internal codes of
+     the characters can be specified by an
+     enumeration_representation_clause as explained in subclause *note
+     13.4::.
+
+                              _Examples_
+
+10
+Example of a character type:
+
+11
+     type Roman_Digit is ('I', 'V', 'X', 'L', 'C', 'D', 'M');
+
+                     _Inconsistencies With Ada 83_
+
+11.a
+          The declaration of Wide_Character in package Standard hides
+          use-visible declarations with the same defining identifier.
+          In the unlikely event that an Ada 83 program had depended on
+          such a use-visible declaration, and the program remains legal
+          after the substitution of Standard.Wide_Character, the meaning
+          of the program will be different.
+
+                    _Incompatibilities With Ada 83_
+
+11.b
+          The presence of Wide_Character in package Standard means that
+          an expression such as
+
+11.c
+               'a' = 'b'
+
+11.d
+          is ambiguous in Ada 95, whereas in Ada 83 both literals could
+          be resolved to be of type Character.
+
+11.e
+          The change in visibility rules (see *note 4.2::) for character
+          literals means that additional qualification might be
+          necessary to resolve expressions involving overloaded
+          subprograms and character literals.
+
+                        _Extensions to Ada 83_
+
+11.f
+          The type Character has been extended to have 256 positions,
+          and the type Wide_Character has been added.  Note that this
+          change was already approved by the ARG for Ada 83 conforming
+          compilers.
+
+11.g
+          The rules for referencing character literals are changed (see
+          *note 4.2::), so that the declaration of the character type
+          need not be directly visible to use its literals, similar to
+          null and string literals.  Context is used to resolve their
+          type.
+
+                     _Inconsistencies With Ada 95_
+
+11.h/2
+          {AI95-00285-01AI95-00285-01} Ada 95 defined most characters in
+          Wide_Character to be graphic characters, while Ada 2005 uses
+          the categorizations from ISO-10646:2003.  It also provides
+          language-defined names for all nongraphic characters.  That
+          means that in Ada 2005, Wide_Character'Wide_Value will raise
+          Constraint_Error for a string representing a character_literal
+          of a nongraphic character, while Ada 95 would have accepted
+          it.  Similarly, the result of Wide_Character'Wide_Image will
+          change for such nongraphic characters.
+
+11.i/3
+          {AI95-00395-01AI95-00395-01} {AI05-0005-1AI05-0005-1}
+          {AI05-0262-1AI05-0262-1} The language-defined names FFFE and
+          FFFF were replaced by a consistent set of language-defined
+          names for all nongraphic characters with code points greater
+          than 16#FF#.  That means that in Ada 2005,
+          Wide_Character'Wide_Value("FFFE") will raise Constraint_Error
+          while Ada 95 would have accepted it.  Similarly, the result of
+          Wide_Character'Wide_Image will change for the position numbers
+          16#FFFE# and 16#FFFF#.  It is very unlikely that this will
+          matter in practice, as these names do not represent usable
+          characters.
+
+11.j/2
+          {AI95-00285-01AI95-00285-01} {AI95-00395-01AI95-00395-01}
+          Because of the previously mentioned changes to the
+          Wide_Character'Wide_Image of various character values, the
+          value of attribute Wide_Width will change for some subtypes of
+          Wide_Character.  However, the new language-defined names were
+          chosen so that the value of Wide_Character'Wide_Width itself
+          does not change.
+
+11.k/2
+          {AI95-00285-01AI95-00285-01} The declaration of
+          Wide_Wide_Character in package Standard hides use-visible
+          declarations with the same defining identifier.  In the (very)
+          unlikely event that an Ada 95 program had depended on such a
+          use-visible declaration, and the program remains legal after
+          the substitution of Standard.Wide_Wide_Character, the meaning
+          of the program will be different.
+
+                        _Extensions to Ada 95_
+
+11.l/2
+          {AI95-00285-01AI95-00285-01} The type Wide_Wide_Character is
+          new.
+
+                     _Wording Changes from Ada 95_
+
+11.m/2
+          {AI95-00285-01AI95-00285-01} Characters are now defined in
+          terms of the entire ISO/IEC 10646:2003 character set.
+
+11.n/3
+          {AI95-00285-01AI95-00285-01} {AI05-0248-1AI05-0248-1} We
+          dropped the Implementation Advice for nonstandard
+          interpretation of character sets; an implementation can do
+          what it wants in a nonstandard mode, so there isn't much point
+          to any advice.
+
+                    _Wording Changes from Ada 2005_
+
+11.o/3
+          {AI05-0181-1AI05-0181-1} Correction: Removed the position
+          numbers of nongraphic characters from the text, as it is wrong
+          and thus misleading.
+
+11.p/3
+          {AI05-0262-1AI05-0262-1} Changed "code position" to "code
+          point" consistently throughout the standard, as ISO/IEC
+          10646:2011 prefers "code point" and we are referring to the
+          definition in that Standard.  This change also reduces
+          confusion between "code point" and "position number"; while
+          these have the same values for the predefined character types,
+          there is no required relationship for other character types.
+
+
+File: aarm2012.info,  Node: 3.5.3,  Next: 3.5.4,  Prev: 3.5.2,  Up: 3.5
+
+3.5.3 Boolean Types
+-------------------
+
+                          _Static Semantics_
+
+1
+There is a predefined enumeration type named Boolean, [declared in the
+visible part of package Standard].  It has the two enumeration literals
+False and True ordered with the relation False < True.  Any descendant
+of the predefined type Boolean is called a boolean type.
+
+1.a
+          Implementation Note: An implementation is not required to
+          support enumeration representation clauses on boolean types
+          that impose an unacceptable implementation burden.  See *note
+          13.4::, "*note 13.4:: Enumeration Representation Clauses".
+          However, it is generally straightforward to support
+          representations where False is zero and True is 2**n - 1 for
+          some n.
+
+
+File: aarm2012.info,  Node: 3.5.4,  Next: 3.5.5,  Prev: 3.5.3,  Up: 3.5
+
+3.5.4 Integer Types
+-------------------
+
+1
+An integer_type_definition defines an integer type; it defines either a
+signed integer type, or a modular integer type.  The base range of a
+signed integer type includes at least the values of the specified range.
+A modular type is an integer type with all arithmetic modulo a specified
+positive modulus; such a type corresponds to an unsigned type with
+wrap-around semantics.  
+
+                               _Syntax_
+
+2
+     integer_type_definition ::= signed_integer_type_definition | 
+     modular_type_definition
+
+3
+     signed_integer_type_definition ::= range static_
+     simple_expression .. static_simple_expression
+
+3.a
+          Discussion: We don't call this a range_constraint, because it
+          is rather different -- not only is it required to be static,
+          but the associated overload resolution rules are different
+          than for normal range constraints.  A similar comment applies
+          to real_range_specification.  This used to be
+          integer_range_specification but when we added support for
+          modular types, it seemed overkill to have three levels of
+          syntax rules, and just calling these
+          signed_integer_range_specification and
+          modular_range_specification loses the fact that they are
+          defining different classes of types, which is important for
+          the generic type matching rules.
+
+4
+     modular_type_definition ::= mod static_expression
+
+                        _Name Resolution Rules_
+
+5
+Each simple_expression in a signed_integer_type_definition is expected
+to be of any integer type; they need not be of the same type.  The
+expression in a modular_type_definition is likewise expected to be of
+any integer type.
+
+                           _Legality Rules_
+
+6
+The simple_expressions of a signed_integer_type_definition shall be
+static, and their values shall be in the range System.Min_Int ..
+System.Max_Int.
+
+7
+The expression of a modular_type_definition shall be static, and its
+value (the modulus) shall be positive, and shall be no greater than
+System.Max_Binary_Modulus if a power of 2, or no greater than
+System.Max_Nonbinary_Modulus if not.
+
+7.a
+          Reason: For a 2's-complement machine, supporting nonbinary
+          moduli greater than System.Max_Int can be quite difficult,
+          whereas essentially any binary moduli are straightforward to
+          support, up to 2*System.Max_Int+2, so this justifies having
+          two separate limits.
+
+                          _Static Semantics_
+
+8
+The set of values for a signed integer type is the (infinite) set of
+mathematical integers[, though only values of the base range of the type
+are fully supported for run-time operations].  The set of values for a
+modular integer type are the values from 0 to one less than the modulus,
+inclusive.
+
+9
+A signed_integer_type_definition defines an integer type whose base
+range includes at least the values of the simple_expressions and is
+symmetric about zero, excepting possibly an extra negative value.  A
+signed_integer_type_definition also defines a constrained first subtype
+of the type, with a range whose bounds are given by the values of the
+simple_expressions, converted to the type being defined.
+
+9.a/2
+          Implementation Note: {AI95-00114-01AI95-00114-01} The base
+          range of a signed integer type might be much larger than is
+          necessary to satisfy the above requirements.
+
+9.a.1/1
+          To be honest: The conversion mentioned above is not an
+          implicit subtype conversion (which is something that happens
+          at overload resolution, see *note 4.6::), although it happens
+          implicitly.  Therefore, the freezing rules are not invoked on
+          the type (which is important so that representation items can
+          be given for the type).  
+
+10
+A modular_type_definition defines a modular type whose base range is
+from zero to one less than the given modulus.  A modular_type_definition
+also defines a constrained first subtype of the type with a range that
+is the same as the base range of the type.
+
+11
+There is a predefined signed integer subtype named Integer[, declared in
+the visible part of package Standard].  It is constrained to the base
+range of its type.
+
+11.a
+          Reason: Integer is a constrained subtype, rather than an
+          unconstrained subtype.  This means that on assignment to an
+          object of subtype Integer, a range check is required.  On the
+          other hand, an object of subtype Integer'Base is
+          unconstrained, and no range check (only overflow check) is
+          required on assignment.  For example, if the object is held in
+          an extended-length register, its value might be outside of
+          Integer'First ..  Integer'Last.  All parameter and result
+          subtypes of the predefined integer operators are of such
+          unconstrained subtypes, allowing extended-length registers to
+          be used as operands or for the result.  In an earlier version
+          of Ada 95, Integer was unconstrained.  However, the fact that
+          certain Constraint_Errors might be omitted or appear elsewhere
+          was felt to be an undesirable upward inconsistency in this
+          case.  Note that for Float, the opposite conclusion was
+          reached, partly because of the high cost of performing range
+          checks when not actually necessary.  Objects of subtype Float
+          are unconstrained, and no range checks, only overflow checks,
+          are performed for them.
+
+12
+Integer has two predefined subtypes, [declared in the visible part of
+package Standard:]
+
+13
+     subtype Natural  is Integer range 0 .. Integer'Last;
+     subtype Positive is Integer range 1 .. Integer'Last;
+
+14
+A type defined by an integer_type_definition is implicitly derived from
+root_integer, an anonymous predefined (specific) integer type, whose
+base range is System.Min_Int ..  System.Max_Int.  However, the base
+range of the new type is not inherited from root_integer, but is instead
+determined by the range or modulus specified by the
+integer_type_definition.  [Integer literals are all of the type
+universal_integer, the universal type (see *note 3.4.1::) for the class
+rooted at root_integer, allowing their use with the operations of any
+integer type.]
+
+14.a
+          Discussion: This implicit derivation is not considered exactly
+          equivalent to explicit derivation via a
+          derived_type_definition.  In particular, integer types defined
+          via a derived_type_definition inherit their base range from
+          their parent type.  A type defined by an
+          integer_type_definition does not necessarily inherit its base
+          range from root_integer.  It is not specified whether the
+          implicit derivation from root_integer is direct or indirect,
+          not that it really matters.  All we want is for all integer
+          types to be descendants of root_integer.
+
+14.a.1/1
+          {8652/00998652/0099} {AI95-00152-01AI95-00152-01} Note that
+          this derivation does not imply any inheritance of subprograms.
+          Subprograms are inherited only for types derived by a
+          derived_type_definition (*note 3.4: S0035.) (see *note 3.4::),
+          or a private_extension_declaration (*note 7.3: S0194.) (see
+          *note 7.3::, *note 7.3.1::, and *note 12.5.1::).
+
+14.b
+          Implementation Note: It is the intent that even nonstandard
+          integer types (see below) will be descendants of root_integer,
+          even though they might have a base range that exceeds that of
+          root_integer.  This causes no problem for static calculations,
+          which are performed without range restrictions (see *note
+          4.9::).  However for run-time calculations, it is possible
+          that Constraint_Error might be raised when using an operator
+          of root_integer on the result of 'Val applied to a value of a
+          nonstandard integer type.
+
+15
+The position number of an integer value is equal to the value.
+
+16/2
+{AI95-00340-01AI95-00340-01} For every modular subtype S, the following
+attributes are defined:
+
+16.1/2
+S'Mod
+               {AI95-00340-01AI95-00340-01} S'Mod denotes a function
+               with the following specification:
+
+16.2/2
+                    function S'Mod (Arg : universal_integer)
+                      return S'Base
+
+16.3/2
+               This function returns Arg mod S'Modulus, as a value of
+               the type of S.
+
+17
+S'Modulus
+               S'Modulus yields the modulus of the type of S, as a value
+               of the type universal_integer.
+
+                          _Dynamic Semantics_
+
+18
+The elaboration of an integer_type_definition creates the integer type
+and its first subtype.
+
+19
+For a modular type, if the result of the execution of a predefined
+operator (see *note 4.5::) is outside the base range of the type, the
+result is reduced modulo the modulus of the type to a value that is
+within the base range of the type.
+
+20
+For a signed integer type, the exception Constraint_Error is raised by
+the execution of an operation that cannot deliver the correct result
+because it is outside the base range of the type.  [ For any integer
+type, Constraint_Error is raised by the operators "/", "rem", and "mod"
+if the right operand is zero.]
+
+                     _Implementation Requirements_
+
+21
+In an implementation, the range of Integer shall include the range
+-2**15+1 ..  +2**15-1.
+
+22
+If Long_Integer is predefined for an implementation, then its range
+shall include the range -2**31+1 ..  +2**31-1.
+
+23
+System.Max_Binary_Modulus shall be at least 2**16.
+
+                     _Implementation Permissions_
+
+24
+For the execution of a predefined operation of a signed integer type,
+the implementation need not raise Constraint_Error if the result is
+outside the base range of the type, so long as the correct result is
+produced.
+
+24.a
+          Discussion: Constraint_Error is never raised for operations on
+          modular types, except for divide-by-zero (and
+          rem/mod-by-zero).
+
+25
+An implementation may provide additional predefined signed integer
+types[, declared in the visible part of Standard], whose first subtypes
+have names of the form Short_Integer, Long_Integer, Short_Short_Integer,
+Long_Long_Integer, etc.  Different predefined integer types are allowed
+to have the same base range.  However, the range of Integer should be no
+wider than that of Long_Integer.  Similarly, the range of Short_Integer
+(if provided) should be no wider than Integer.  Corresponding
+recommendations apply to any other predefined integer types.  There need
+not be a named integer type corresponding to each distinct base range
+supported by an implementation.  The range of each first subtype should
+be the base range of its type.
+
+25.a
+          Implementation defined: The predefined integer types declared
+          in Standard.
+
+26
+An implementation may provide nonstandard integer types, descendants of
+root_integer that are declared outside of the specification of package
+Standard, which need not have all the standard characteristics of a type
+defined by an integer_type_definition.  For example, a nonstandard
+integer type might have an asymmetric base range or it might not be
+allowed as an array or loop index (a very long integer).  Any type
+descended from a nonstandard integer type is also nonstandard.  An
+implementation may place arbitrary restrictions on the use of such
+types; it is implementation defined whether operators that are
+predefined for "any integer type" are defined for a particular
+nonstandard integer type.  [In any case, such types are not permitted as
+explicit_generic_actual_parameters for formal scalar types -- see *note
+12.5.2::.]
+
+26.a
+          Implementation defined: Any nonstandard integer types and the
+          operators defined for them.
+
+27
+For a one's complement machine, the high bound of the base range of a
+modular type whose modulus is one less than a power of 2 may be equal to
+the modulus, rather than one less than the modulus.  It is
+implementation defined for which powers of 2, if any, this permission is
+exercised.
+
+27.1/1
+{8652/00038652/0003} {AI95-00095-01AI95-00095-01} For a one's complement
+machine, implementations may support nonbinary modulus values greater
+than System.Max_Nonbinary_Modulus.  It is implementation defined which
+specific values greater than System.Max_Nonbinary_Modulus, if any, are
+supported.
+
+27.a.1/1
+          Reason: On a one's complement machine, the natural full word
+          type would have a modulus of 2**Word_Size-1.  However, we
+          would want to allow the all-ones bit pattern (which represents
+          negative zero as a number) in logical operations.  These
+          permissions are intended to allow that and the natural modulus
+          value without burdening implementations with supporting
+          expensive modulus values.
+
+                        _Implementation Advice_
+
+28
+An implementation should support Long_Integer in addition to Integer if
+the target machine supports 32-bit (or longer) arithmetic.  No other
+named integer subtypes are recommended for package Standard.  Instead,
+appropriate named integer subtypes should be provided in the library
+package Interfaces (see *note B.2::).
+
+28.a.1/2
+          Implementation Advice: Long_Integer should be declared in
+          Standard if the target supports 32-bit arithmetic.  No other
+          named integer subtypes should be declared in Standard.
+
+28.a
+          Implementation Note: To promote portability, implementations
+          should explicitly declare the integer (sub)types Integer and
+          Long_Integer in Standard, and leave other predefined integer
+          types anonymous.  For implementations that already support
+          Byte_Integer, etc., upward compatibility argues for keeping
+          such declarations in Standard during the transition period,
+          but perhaps generating a warning on use.  A separate package
+          Interfaces in the predefined environment is available for
+          pre-declaring types such as Integer_8, Integer_16, etc.  See
+          *note B.2::.  In any case, if the user declares a subtype
+          (first or not) whose range fits in, for example, a byte, the
+          implementation can store variables of the subtype in a single
+          byte, even if the base range of the type is wider.
+
+29
+An implementation for a two's complement machine should support modular
+types with a binary modulus up to System.Max_Int*2+2.  An implementation
+should support a nonbinary modulus up to Integer'Last.
+
+29.a.1/2
+          Implementation Advice: For a two's complement target, modular
+          types with a binary modulus up to System.Max_Int*2+2 should be
+          supported.  A nonbinary modulus up to Integer'Last should be
+          supported.
+
+29.a
+          Reason: Modular types provide bit-wise "and", "or", "xor", and
+          "not" operations.  It is important for systems programming
+          that these be available for all integer types of the target
+          hardware.
+
+29.b
+          Ramification: Note that on a one's complement machine, the
+          largest supported modular type would normally have a nonbinary
+          modulus.  On a two's complement machine, the largest supported
+          modular type would normally have a binary modulus.
+
+29.c
+          Implementation Note: Supporting a nonbinary modulus greater
+          than Integer'Last can impose an undesirable implementation
+          burden on some machines.
+
+     NOTES
+
+30
+     30  Integer literals are of the anonymous predefined integer type
+     universal_integer.  Other integer types have no literals.  However,
+     the overload resolution rules (see *note 8.6::, "*note 8.6:: The
+     Context of Overload Resolution") allow expressions of the type
+     universal_integer whenever an integer type is expected.
+
+31
+     31  The same arithmetic operators are predefined for all signed
+     integer types defined by a signed_integer_type_definition (see
+     *note 4.5::, "*note 4.5:: Operators and Expression Evaluation").
+     For modular types, these same operators are predefined, plus
+     bit-wise logical operators (and, or, xor, and not).  In addition,
+     for the unsigned types declared in the language-defined package
+     Interfaces (see *note B.2::), functions are defined that provide
+     bit-wise shifting and rotating.
+
+32
+     32  Modular types match a generic_formal_parameter_declaration of
+     the form "type T is mod <>;"; signed integer types match "type T is
+     range <>;" (see *note 12.5.2::).
+
+                              _Examples_
+
+33
+Examples of integer types and subtypes:
+
+34
+     type Page_Num  is range 1 .. 2_000;
+     type Line_Size is range 1 .. Max_Line_Size;
+
+35
+     subtype Small_Int   is Integer   range -10 .. 10;
+     subtype Column_Ptr  is Line_Size range 1 .. 10;
+     subtype Buffer_Size is Integer   range 0 .. Max;
+
+36
+     type Byte        is mod 256; -- an unsigned byte
+     type Hash_Index  is mod 97;  -- modulus is prime
+
+                        _Extensions to Ada 83_
+
+36.a
+          An implementation is allowed to support any number of distinct
+          base ranges for integer types, even if fewer integer types are
+          explicitly declared in Standard.
+
+36.b
+          Modular (unsigned, wrap-around) types are new.
+
+                     _Wording Changes from Ada 83_
+
+36.c
+          Ada 83's integer types are now called "signed" integer types,
+          to contrast them with "modular" integer types.
+
+36.d
+          Standard.Integer, Standard.Long_Integer, etc., denote
+          constrained subtypes of predefined integer types, consistent
+          with the Ada 95 model that only subtypes have names.
+
+36.e
+          We now impose minimum requirements on the base range of
+          Integer and Long_Integer.
+
+36.f
+          We no longer explain integer type definition in terms of an
+          equivalence to a normal type derivation, except to say that
+          all integer types are by definition implicitly derived from
+          root_integer.  This is for various reasons.
+
+36.g
+          First of all, the equivalence with a type derivation and a
+          subtype declaration was not perfect, and was the source of
+          various AIs (for example, is the conversion of the bounds
+          static?  Is a numeric type a derived type with respect to
+          other rules of the language?)
+
+36.h
+          Secondly, we don't want to require that every integer size
+          supported shall have a corresponding named type in Standard.
+          Adding named types to Standard creates nonportabilities.
+
+36.i
+          Thirdly, we don't want the set of types that match a formal
+          derived type "type T is new Integer;" to depend on the
+          particular underlying integer representation chosen to
+          implement a given user-defined integer type.  Hence, we would
+          have needed anonymous integer types as parent types for the
+          implicit derivation anyway.  We have simply chosen to identify
+          only one anonymous integer type -- root_integer, and stated
+          that every integer type is derived from it.
+
+36.j
+          Finally, the "fiction" that there were distinct preexisting
+          predefined types for every supported representation breaks
+          down for fixed point with arbitrary smalls, and was never
+          exploited for enumeration types, array types, etc.  Hence,
+          there seems little benefit to pushing an explicit equivalence
+          between integer type definition and normal type derivation.
+
+                        _Extensions to Ada 95_
+
+36.k/2
+          {AI95-00340-01AI95-00340-01} The Mod attribute is new.  It
+          eases mixing of signed and unsigned values in an expression,
+          which can be difficult as there may be no type which can
+          contain all of the values of both of the types involved.
+
+                     _Wording Changes from Ada 95_
+
+36.l/2
+          {8652/00038652/0003} {AI95-00095-01AI95-00095-01} Corrigendum:
+          Added additional permissions for modular types on one's
+          complement machines.
+
+
+File: aarm2012.info,  Node: 3.5.5,  Next: 3.5.6,  Prev: 3.5.4,  Up: 3.5
+
+3.5.5 Operations of Discrete Types
+----------------------------------
+
+                          _Static Semantics_
+
+1
+For every discrete subtype S, the following attributes are defined:
+
+2
+S'Pos
+               S'Pos denotes a function with the following
+               specification:
+
+3
+                    function S'Pos(Arg : S'Base)
+                      return universal_integer
+
+4
+               This function returns the position number of the value of
+               Arg, as a value of type universal_integer.
+
+5
+S'Val
+               S'Val denotes a function with the following
+               specification:
+
+6
+                    function S'Val(Arg : universal_integer)
+                      return S'Base
+
+7
+               This function returns a value of the type of S whose
+               position number equals the value of Arg.  For the
+               evaluation of a call on S'Val, if there is no value in
+               the base range of its type with the given position
+               number, Constraint_Error is raised.
+
+7.a
+          Ramification: By the overload resolution rules, a formal
+          parameter of type universal_integer allows an actual parameter
+          of any integer type.
+
+7.b
+          Reason: We considered allowing S'Val for a signed integer
+          subtype S to return an out-of-range value, but since checks
+          were required for enumeration and modular types anyway, the
+          allowance didn't seem worth the complexity of the rule.
+
+7.1/3
+{AI05-0297-1AI05-0297-1} For every static discrete subtype S for which
+there exists at least one value belonging to S that satisfies any
+predicate of S, the following attributes are defined:
+
+7.2/3
+S'First_Valid
+               {AI05-0297-1AI05-0297-1} S'First_Valid denotes the
+               smallest value that belongs to S and satisfies the
+               predicate of S. The value of this attribute is of the
+               type of S.
+
+7.3/3
+S'Last_Valid
+               {AI05-0297-1AI05-0297-1} S'Last_Valid denotes the largest
+               value that belongs to S and satisfies the predicate of S.
+               The value of this attribute is of the type of S.
+
+7.4/3
+{AI05-0297-1AI05-0297-1} [First_Valid and Last_Valid
+attribute_references are always static expressions.  Any explicit
+predicate of S can only have been specified by a Static_Predicate
+aspect.]
+
+7.c/3
+          Proof: An attribute_reference is static if the prefix is a
+          static subtype (see *note 4.9::), (true by definition) and any
+          arguments are static (there are none).  Similarly, a dynamic
+          predicate always makes a subtype nonstatic.  QED.
+
+7.d/3
+          Reason: We require there to be at least one value so that
+          these are always values of the subtype.  (This sidesteps the
+          question of what to return for a subtype with no values.)
+
+7.e/3
+          Discussion: These attributes are intended primarily for use in
+          the case where the Static_Predicate aspect of S has been
+          specified; First and Last are equivalent if these are allowed
+          and there is no predicate.
+
+                        _Implementation Advice_
+
+8
+For the evaluation of a call on S'Pos for an enumeration subtype, if the
+value of the operand does not correspond to the internal code for any
+enumeration literal of its type [(perhaps due to an uninitialized
+variable)], then the implementation should raise Program_Error.  This is
+particularly important for enumeration types with noncontiguous internal
+codes specified by an enumeration_representation_clause (*note 13.4:
+S0310.).
+
+8.a.1/2
+          Implementation Advice: Program_Error should be raised for the
+          evaluation of S'Pos for an enumeration type, if the value of
+          the operand does not correspond to the internal code for any
+          enumeration literal of the type.
+
+8.a
+          Reason: We say Program_Error here, rather than
+          Constraint_Error, because the main reason for such values is
+          uninitialized variables, and the normal way to indicate such a
+          use (if detected) is to raise Program_Error.  (Other reasons
+          would involve the misuse of low-level features such as
+          Unchecked_Conversion.)
+
+     NOTES
+
+9
+     33  Indexing and loop iteration use values of discrete types.
+
+10/3
+     34  {AI05-0299-1AI05-0299-1} The predefined operations of a
+     discrete type include the assignment operation, qualification, the
+     membership tests, and the relational operators; for a boolean type
+     they include the short-circuit control forms and the logical
+     operators; for an integer type they include type conversion to and
+     from other numeric types, as well as the binary and unary adding
+     operators - and +, the multiplying operators, the unary operator
+     abs, and the exponentiation operator.  The assignment operation is
+     described in *note 5.2::.  The other predefined operations are
+     described in Clause *note 4::.
+
+11
+     35  As for all types, objects of a discrete type have Size and
+     Address attributes (see *note 13.3::).
+
+12
+     36  For a subtype of a discrete type, the result delivered by the
+     attribute Val might not belong to the subtype; similarly, the
+     actual parameter of the attribute Pos need not belong to the
+     subtype.  The following relations are satisfied (in the absence of
+     an exception) by these attributes:
+
+13
+             S'Val(S'Pos(X)) = X
+             S'Pos(S'Val(N)) = N
+
+                              _Examples_
+
+14
+Examples of attributes of discrete subtypes:
+
+15
+     --  For the types and subtypes declared in subclause *note 3.5.1:: the 
following hold: 
+
+16
+     --  Color'First   = White,   Color'Last   = Black
+     --  Rainbow'First = Red,     Rainbow'Last = Blue
+
+17
+     --  Color'Succ(Blue) = Rainbow'Succ(Blue) = Brown
+     --  Color'Pos(Blue)  = Rainbow'Pos(Blue)  = 4
+     --  Color'Val(0)     = Rainbow'Val(0)     = White
+
+                        _Extensions to Ada 83_
+
+17.a
+          The attributes S'Succ, S'Pred, S'Width, S'Image, and S'Value
+          have been generalized to apply to real types as well (see
+          *note 3.5::, "*note 3.5:: Scalar Types").
+
+                       _Extensions to Ada 2005_
+
+17.b/3
+          {AI05-0297-1AI05-0297-1} The attributes S'First_Valid and
+          S'Last_Valid are new.
+
+
+File: aarm2012.info,  Node: 3.5.6,  Next: 3.5.7,  Prev: 3.5.5,  Up: 3.5
+
+3.5.6 Real Types
+----------------
+
+1
+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.
+
+                               _Syntax_
+
+2
+     real_type_definition ::=
+        floating_point_definition | fixed_point_definition
+
+                          _Static Semantics_
+
+3
+A type defined by a real_type_definition is implicitly derived from
+root_real, an anonymous predefined (specific) real type.  [Hence, all
+real types, whether floating point or fixed point, are in the derivation
+class rooted at root_real.]
+
+3.a
+          Ramification: It is not specified whether the derivation from
+          root_real is direct or indirect, not that it really matters.
+          All we want is for all real types to be descendants of
+          root_real.
+
+3.a.1/1
+          {8652/00998652/0099} {AI95-00152-01AI95-00152-01} Note that
+          this derivation does not imply any inheritance of subprograms.
+          Subprograms are inherited only for types derived by a
+          derived_type_definition (*note 3.4: S0035.) (see *note 3.4::),
+          or a private_extension_declaration (*note 7.3: S0194.) (see
+          *note 7.3::, *note 7.3.1::, and *note 12.5.1::).
+
+4
+[ Real literals are all of the type universal_real, the universal type
+(see *note 3.4.1::) for the class rooted at root_real, allowing their
+use with the operations of any real type.  Certain multiplying operators
+have a result type of universal_fixed (see *note 4.5.5::), the universal
+type for the class of fixed point types, allowing the result of the
+multiplication or division to be used where any specific fixed point
+type is expected.]
+
+                          _Dynamic Semantics_
+
+5
+The elaboration of a real_type_definition consists of the elaboration of
+the floating_point_definition or the fixed_point_definition.
+
+                     _Implementation Requirements_
+
+6
+An implementation shall perform the run-time evaluation of a use of a
+predefined operator of root_real with an accuracy at least as great as
+that of any floating point type definable by a
+floating_point_definition.
+
+6.a
+          Ramification: Static calculations using the operators of
+          root_real are exact, as for all static calculations.  See
+          *note 4.9::.
+
+6.b
+          Implementation Note: The Digits attribute of the type used to
+          represent root_real at run time is at least as great as that
+          of any other floating point type defined by a
+          floating_point_definition, and its safe range includes that of
+          any such floating point type with the same Digits attribute.
+          On some machines, there might be real types with less accuracy
+          but a wider range, and hence run-time calculations with
+          root_real might not be able to accommodate all values that can
+          be represented at run time in such floating point or fixed
+          point types.
+
+                     _Implementation Permissions_
+
+7/2
+{AI95-00114-01AI95-00114-01} [For the execution of a predefined
+operation of a real type, the implementation need not raise
+Constraint_Error if the result is outside the base range of the type, so
+long as the correct result is produced, or the Machine_Overflows
+attribute of the type is False (see *note G.2::).]
+
+8
+An implementation may provide nonstandard real types, descendants of
+root_real that are declared outside of the specification of package
+Standard, which need not have all the standard characteristics of a type
+defined by a real_type_definition.  For example, a nonstandard real type
+might have an asymmetric or unsigned base range, or its predefined
+operations might wrap around or "saturate" rather than overflow (modular
+or saturating arithmetic), or it might not conform to the accuracy model
+(see *note G.2::).  Any type descended from a nonstandard real type is
+also nonstandard.  An implementation may place arbitrary restrictions on
+the use of such types; it is implementation defined whether operators
+that are predefined for "any real type" are defined for a particular
+nonstandard real type.  [In any case, such types are not permitted as
+explicit_generic_actual_parameters for formal scalar types -- see *note
+12.5.2::.]
+
+8.a
+          Implementation defined: Any nonstandard real types and the
+          operators defined for them.
+
+     NOTES
+
+9
+     37  As stated, real literals are of the anonymous predefined real
+     type universal_real.  Other real types have no literals.  However,
+     the overload resolution rules (see *note 8.6::) allow expressions
+     of the type universal_real whenever a real type is expected.
+
+                     _Wording Changes from Ada 83_
+
+9.a
+          The syntax rule for real_type_definition is modified to use
+          the new syntactic categories floating_point_definition and
+          fixed_point_definition, instead of floating_point_constraint
+          and fixed_point_constraint, because the semantics of a type
+          definition are significantly different than the semantics of a
+          constraint.
+
+9.b
+          All discussion of model numbers, safe ranges, and machine
+          numbers is moved to *note 3.5.7::, *note 3.5.8::, and *note
+          G.2::.  Values of a fixed point type are now described as
+          being multiples of the small of the fixed point type, and we
+          have no need for model numbers, safe ranges, etc.  for fixed
+          point types.
+
+
+File: aarm2012.info,  Node: 3.5.7,  Next: 3.5.8,  Prev: 3.5.6,  Up: 3.5
+
+3.5.7 Floating Point Types
+--------------------------
+
+1
+For floating point types, the error bound is specified as a relative
+precision by giving the required minimum number of significant decimal
+digits.
+
+                               _Syntax_
+
+2
+     floating_point_definition ::=
+       digits static_expression [real_range_specification]
+
+3
+     real_range_specification ::=
+       range static_simple_expression .. static_simple_expression
+
+                        _Name Resolution Rules_
+
+4
+The requested decimal precision, which is the minimum number of
+significant decimal digits required for the floating point type, is
+specified by the value of the expression given after the reserved word
+digits.  This expression is expected to be of any integer type.
+
+5
+Each simple_expression of a real_range_specification is expected to be
+of any real type[; the types need not be the same].
+
+                           _Legality Rules_
+
+6
+The requested decimal precision shall be specified by a static
+expression whose value is positive and no greater than
+System.Max_Base_Digits.  Each simple_expression of a
+real_range_specification shall also be static.  If the
+real_range_specification is omitted, the requested decimal precision
+shall be no greater than System.Max_Digits.
+
+6.a
+          Reason: We have added Max_Base_Digits to package System.  It
+          corresponds to the requested decimal precision of root_real.
+          System.Max_Digits corresponds to the maximum value for Digits
+          that may be specified in the absence of a
+          real_range_specification, for upward compatibility.  These
+          might not be the same if root_real has a base range that does
+          not include � 10.0**(4*Max_Base_Digits).
+
+7
+A floating_point_definition is illegal if the implementation does not
+support a floating point type that satisfies the requested decimal
+precision and range.
+
+7.a
+          Implementation defined: What combinations of requested decimal
+          precision and range are supported for floating point types.
+
+                          _Static Semantics_
+
+8
+The set of values for a floating point type is the (infinite) set of
+rational numbers.  The machine numbers of a floating point type are the
+values of the type that can be represented exactly in every
+unconstrained variable of the type.  The base range (see *note 3.5::) of
+a floating point type is symmetric around zero, except that it can
+include some extra negative values in some implementations.
+
+8.a
+          Implementation Note: For example, if a 2's complement
+          representation is used for the mantissa rather than a
+          sign-mantissa or 1's complement representation, then there is
+          usually one extra negative machine number.
+
+8.b
+          To be honest: If the Signed_Zeros attribute is True, then
+          minus zero could in a sense be considered a value of the type.
+          However, for most purposes, minus zero behaves the same as
+          plus zero.
+
+9
+The base decimal precision of a floating point type is the number of
+decimal digits of precision representable in objects of the type.  The
+safe range of a floating point type is that part of its base range for
+which the accuracy corresponding to the base decimal precision is
+preserved by all predefined operations.
+
+9.a
+          Implementation Note: In most cases, the safe range and base
+          range are the same.  However, for some hardware, values near
+          the boundaries of the base range might result in excessive
+          inaccuracies or spurious overflows when used with certain
+          predefined operations.  For such hardware, the safe range
+          would omit such values.
+
+10
+A floating_point_definition defines a floating point type whose base
+decimal precision is no less than the requested decimal precision.  If a
+real_range_specification is given, the safe range of the floating point
+type (and hence, also its base range) includes at least the values of
+the simple expressions given in the real_range_specification.  If a
+real_range_specification is not given, the safe (and base) range of the
+type includes at least the values of the range -10.0**(4*D) ..
++10.0**(4*D) where D is the requested decimal precision.  [The safe
+range might include other values as well.  The attributes Safe_First and
+Safe_Last give the actual bounds of the safe range.]
+
+11
+A floating_point_definition also defines a first subtype of the type.  
+If a real_range_specification is given, then the subtype is constrained
+to a range whose bounds are given by a conversion of the values of the
+simple_expressions of the real_range_specification to the type being
+defined.  Otherwise, the subtype is unconstrained.
+
+11.a.1/1
+          To be honest: The conversion mentioned above is not an
+          implicit subtype conversion (which is something that happens
+          at overload resolution, see *note 4.6::), although it happens
+          implicitly.  Therefore, the freezing rules are not invoked on
+          the type (which is important so that representation items can
+          be given for the type).  
+
+12
+There is a predefined, unconstrained, floating point subtype named
+Float[, declared in the visible part of package Standard].
+
+                          _Dynamic Semantics_
+
+13
+[The elaboration of a floating_point_definition creates the floating
+point type and its first subtype.]
+
+                     _Implementation Requirements_
+
+14
+In an implementation that supports floating point types with 6 or more
+digits of precision, the requested decimal precision for Float shall be
+at least 6.
+
+15
+If Long_Float is predefined for an implementation, then its requested
+decimal precision shall be at least 11.
+
+                     _Implementation Permissions_
+
+16
+An implementation is allowed to provide additional predefined floating
+point types[, declared in the visible part of Standard], whose
+(unconstrained) first subtypes have names of the form Short_Float,
+Long_Float, Short_Short_Float, Long_Long_Float, etc.  Different
+predefined floating point types are allowed to have the same base
+decimal precision.  However, the precision of Float should be no greater
+than that of Long_Float.  Similarly, the precision of Short_Float (if
+provided) should be no greater than Float.  Corresponding
+recommendations apply to any other predefined floating point types.
+There need not be a named floating point type corresponding to each
+distinct base decimal precision supported by an implementation.
+
+16.a
+          Implementation defined: The predefined floating point types
+          declared in Standard.
+
+                        _Implementation Advice_
+
+17
+An implementation should support Long_Float in addition to Float if the
+target machine supports 11 or more digits of precision.  No other named
+floating point subtypes are recommended for package Standard.  Instead,
+appropriate named floating point subtypes should be provided in the
+library package Interfaces (see *note B.2::).
+
+17.a.1/2
+          Implementation Advice: Long_Float should be declared in
+          Standard if the target supports 11 or more digits of
+          precision.  No other named float subtypes should be declared
+          in Standard.
+
+17.a
+          Implementation Note: To promote portability, implementations
+          should explicitly declare the floating point (sub)types Float
+          and Long_Float in Standard, and leave other predefined float
+          types anonymous.  For implementations that already support
+          Short_Float, etc., upward compatibility argues for keeping
+          such declarations in Standard during the transition period,
+          but perhaps generating a warning on use.  A separate package
+          Interfaces in the predefined environment is available for
+          pre-declaring types such as Float_32, IEEE_Float_64, etc.  See
+          *note B.2::.
+
+     NOTES
+
+18
+     38  If a floating point subtype is unconstrained, then assignments
+     to variables of the subtype involve only Overflow_Checks, never
+     Range_Checks.
+
+                              _Examples_
+
+19
+Examples of floating point types and subtypes:
+
+20
+     type Coefficient is digits 10 range -1.0 .. 1.0;
+
+21
+     type Real is digits 8;
+     type Mass is digits 7 range 0.0 .. 1.0E35;
+
+22
+     subtype Probability is Real range 0.0 .. 1.0;   --   a subtype with a 
smaller range
+
+                     _Inconsistencies With Ada 83_
+
+22.a
+          No Range_Checks, only Overflow_Checks, are performed on
+          variables (or parameters) of an unconstrained floating point
+          subtype.  This is upward compatible for programs that do not
+          raise Constraint_Error.  For those that do raise
+          Constraint_Error, it is possible that the exception will be
+          raised at a later point, or not at all, if extended range
+          floating point registers are used to hold the value of the
+          variable (or parameter).
+
+22.b
+          Reason: This change was felt to be justified by the
+          possibility of improved performance on machines with
+          extended-range floating point registers.  An implementation
+          need not take advantage of this relaxation in the range
+          checking; it can hide completely the use of extended range
+          registers if desired, presumably at some run-time expense.
+
+                     _Wording Changes from Ada 83_
+
+22.c
+          The syntax rules for floating_point_constraint and
+          floating_accuracy_definition are removed.  The syntax rules
+          for floating_point_definition and real_range_specification are
+          new.
+
+22.d
+          A syntax rule for digits_constraint is given in *note 3.5.9::,
+          "*note 3.5.9:: Fixed Point Types".  In *note J.3:: we indicate
+          that a digits_constraint may be applied to a floating point
+          subtype_mark as well (to be compatible with Ada 83's
+          floating_point_constraint).
+
+22.e
+          Discussion of model numbers is postponed to *note 3.5.8:: and
+          *note G.2::.  The concept of safe numbers has been replaced by
+          the concept of the safe range of values.  The bounds of the
+          safe range are given by T'Safe_First ..  T'Safe_Last, rather
+          than -T'Safe_Large ..  T'Safe_Large, since on some machines
+          the safe range is not perfectly symmetric.  The concept of
+          machine numbers is new, and is relevant to the definition of
+          Succ and Pred for floating point numbers.
+
+
+File: aarm2012.info,  Node: 3.5.8,  Next: 3.5.9,  Prev: 3.5.7,  Up: 3.5
+
+3.5.8 Operations of Floating Point Types
+----------------------------------------
+
+                          _Static Semantics_
+
+1
+The following attribute is defined for every floating point subtype S:
+
+2/1
+S'Digits
+               {8652/00048652/0004} {AI95-00203-01AI95-00203-01}
+               S'Digits denotes the requested decimal precision for the
+               subtype S. The value of this attribute is of the type
+               universal_integer.  The requested decimal precision of
+               the base subtype of a floating point type T is defined to
+               be the largest value of d for which
+               ceiling(d * log(10) / log(T'Machine_Radix)) + g <=
+               T'Model_Mantissa
+               where g is 0 if Machine_Radix is a positive power of 10
+               and 1 otherwise.
+
+     NOTES
+
+3
+     39  The predefined operations of a floating point type include the
+     assignment operation, qualification, the membership tests, and
+     explicit conversion to and from other numeric types.  They also
+     include the relational operators and the following predefined
+     arithmetic operators: the binary and unary adding operators - and
+     +, certain multiplying operators, the unary operator abs, and the
+     exponentiation operator.
+
+4
+     40  As for all types, objects of a floating point type have Size
+     and Address attributes (see *note 13.3::).  Other attributes of
+     floating point types are defined in *note A.5.3::.
+
+                     _Wording Changes from Ada 95_
+
+4.a/2
+          {8652/00048652/0004} {AI95-00203-01AI95-00203-01} Corrigendum:
+          Corrected the formula for Digits when the Machine_Radix is 10.
+
+
+File: aarm2012.info,  Node: 3.5.9,  Next: 3.5.10,  Prev: 3.5.8,  Up: 3.5
+
+3.5.9 Fixed Point Types
+-----------------------
+
+1
+A fixed point type is either an ordinary fixed point type, or a decimal
+fixed point type.  The error bound of a fixed point type is specified as
+an absolute value, called the delta of the fixed point type.
+
+                               _Syntax_
+
+2
+     fixed_point_definition ::= ordinary_fixed_point_definition | 
+     decimal_fixed_point_definition
+
+3
+     ordinary_fixed_point_definition ::=
+        delta static_expression  real_range_specification
+
+4
+     decimal_fixed_point_definition ::=
+        delta static_expression digits static_expression [
+     real_range_specification]
+
+5
+     digits_constraint ::=
+        digits static_expression [range_constraint]
+
+                        _Name Resolution Rules_
+
+6
+For a type defined by a fixed_point_definition, the delta of the type is
+specified by the value of the expression given after the reserved word
+delta; this expression is expected to be of any real type.  For a type
+defined by a decimal_fixed_point_definition (a decimal fixed point
+type), the number of significant decimal digits for its first subtype
+(the digits of the first subtype) is specified by the expression given
+after the reserved word digits; this expression is expected to be of any
+integer type.
+
+                           _Legality Rules_
+
+7
+In a fixed_point_definition or digits_constraint, the expressions given
+after the reserved words delta and digits shall be static; their values
+shall be positive.
+
+8/2
+{AI95-00100-01AI95-00100-01} The set of values of a fixed point type
+comprise the integral multiples of a number called the small of the
+type.  The machine numbers of a fixed point type are the values of the
+type that can be represented exactly in every unconstrained variable of
+the type.  For a type defined by an ordinary_fixed_point_definition (an
+ordinary fixed point type), the small may be specified by an
+attribute_definition_clause (*note 13.3: S0309.) (see *note 13.3::); if
+so specified, it shall be no greater than the delta of the type.  If not
+specified, the small of an ordinary fixed point type is an
+implementation-defined power of two less than or equal to the delta.
+
+8.a
+          Implementation defined: The small of an ordinary fixed point
+          type.
+
+9
+For a decimal fixed point type, the small equals the delta; the delta
+shall be a power of 10.  If a real_range_specification is given, both
+bounds of the range shall be in the range -(10**digits-1)*delta ..
++(10**digits-1)*delta.
+
+10
+A fixed_point_definition is illegal if the implementation does not
+support a fixed point type with the given small and specified range or
+digits.
+
+10.a
+          Implementation defined: What combinations of small, range, and
+          digits are supported for fixed point types.
+
+11
+For a subtype_indication with a digits_constraint, the subtype_mark
+shall denote a decimal fixed point subtype.
+
+11.a
+          To be honest: Or, as an obsolescent feature, a floating point
+          subtype is permitted -- see *note J.3::.
+
+                          _Static Semantics_
+
+12
+The base range (see *note 3.5::) of a fixed point type is symmetric
+around zero, except possibly for an extra negative value in some
+implementations.
+
+13
+An ordinary_fixed_point_definition defines an ordinary fixed point type
+whose base range includes at least all multiples of small that are
+between the bounds specified in the real_range_specification.  The base
+range of the type does not necessarily include the specified bounds
+themselves.  An ordinary_fixed_point_definition (*note 3.5.9: S0048.)
+also defines a constrained first subtype of the type, with each bound of
+its range given by the closer to zero of:
+
+14
+   * the value of the conversion to the fixed point type of the
+     corresponding expression of the real_range_specification; 
+
+14.a.1/1
+          To be honest: The conversion mentioned above is not an
+          implicit subtype conversion (which is something that happens
+          at overload resolution, see *note 4.6::), although it happens
+          implicitly.  Therefore, the freezing rules are not invoked on
+          the type (which is important so that representation items can
+          be given for the type).  
+
+15
+   * the corresponding bound of the base range.
+
+16
+A decimal_fixed_point_definition defines a decimal fixed point type
+whose base range includes at least the range -(10**digits-1)*delta ..
++(10**digits-1)*delta.  A decimal_fixed_point_definition also defines a
+constrained first subtype of the type.  If a real_range_specification is
+given, the bounds of the first subtype are given by a conversion of the
+values of the expressions of the real_range_specification.  Otherwise,
+the range of the first subtype is -(10**digits-1)*delta ..
++(10**digits-1)*delta.
+
+16.a.1/1
+          To be honest: The conversion mentioned above is not an
+          implicit subtype conversion (which is something that happens
+          at overload resolution, see *note 4.6::), although it happens
+          implicitly.  Therefore, the freezing rules are not invoked on
+          the type (which is important so that representation items can
+          be given for the type).  
+
+                          _Dynamic Semantics_
+
+17
+The elaboration of a fixed_point_definition creates the fixed point type
+and its first subtype.
+
+18
+For a digits_constraint on a decimal fixed point subtype with a given
+delta, if it does not have a range_constraint, then it specifies an
+implicit range -(10**D-1)*delta ..  +(10**D-1)*delta, where D is the
+value of the expression.  A digits_constraint is compatible with a
+decimal fixed point subtype if the value of the expression is no greater
+than the digits of the subtype, and if it specifies (explicitly or
+implicitly) a range that is compatible with the subtype.
+
+18.a
+          Discussion: Except for the requirement that the digits
+          specified be no greater than the digits of the subtype being
+          constrained, a digits_constraint is essentially equivalent to
+          a range_constraint.
+
+18.b
+          Consider the following example:
+
+18.c
+               type D is delta 0.01 digits 7 range -0.00 .. 9999.99;
+
+18.d/1
+          The compatibility rule implies that the digits_constraint
+          "digits 6" specifies an implicit range of "-9999.99 ..
+          9999.99".  Thus, "digits 6" is not compatible with the
+          constraint of D, but "digits 6 range 0.00 ..  9999.99" is
+          compatible.
+
+18.e/2
+          {AI95-00114-01AI95-00114-01} A value of a scalar type belongs
+          to a constrained subtype of the type if it belongs to the
+          range of the subtype.  Attributes like Digits and Delta have
+          no effect on this fundamental rule.  So the obsolescent forms
+          of digits_constraints and delta_constraints that are called
+          "accuracy constraints" in RM83 don't really represent
+          constraints on the values of the subtype, but rather primarily
+          affect compatibility of the "constraint" with the subtype
+          being "constrained."  In this sense, they might better be
+          called "subtype assertions" rather than "constraints."
+
+18.f
+          Note that the digits_constraint on a decimal fixed point
+          subtype is a combination of an assertion about the digits of
+          the subtype being further constrained, and a constraint on the
+          range of the subtype being defined, either explicit or
+          implicit.
+
+19
+The elaboration of a digits_constraint consists of the elaboration of
+the range_constraint, if any.  If a range_constraint is given, a check
+is made that the bounds of the range are both in the range
+-(10**D-1)*delta ..  +(10**D-1)*delta, where D is the value of the
+(static) expression given after the reserved word digits.  If this check
+fails, Constraint_Error is raised.
+
+                     _Implementation Requirements_
+
+20
+The implementation shall support at least 24 bits of precision
+(including the sign bit) for fixed point types.
+
+20.a
+          Reason: This is sufficient to represent Standard.Duration with
+          a small no more than 50 milliseconds.
+
+                     _Implementation Permissions_
+
+21
+Implementations are permitted to support only smalls that are a power of
+two.  In particular, all decimal fixed point type declarations can be
+disallowed.  Note however that conformance with the Information Systems
+Annex requires support for decimal smalls, and decimal fixed point type
+declarations with digits up to at least 18.
+
+21.a
+          Implementation Note: The accuracy requirements for
+          multiplication, division, and conversion (see *note G.2.1::,
+          "*note G.2.1:: Model of Floating Point Arithmetic") are such
+          that support for arbitrary smalls should be practical without
+          undue implementation effort.  Therefore, implementations
+          should support fixed point types with arbitrary values for
+          small (within reason).  One reasonable limitation would be to
+          limit support to fixed point types that can be converted to
+          the most precise floating point type without loss of precision
+          (so that Fixed_IO is implementable in terms of Float_IO).
+
+     NOTES
+
+22
+     41  The base range of an ordinary fixed point type need not include
+     the specified bounds themselves so that the range specification can
+     be given in a natural way, such as:
+
+23
+             type Fraction is delta 2.0**(-15) range -1.0 .. 1.0;
+  
+
+24
+     With 2's complement hardware, such a type could have a signed
+     16-bit representation, using 1 bit for the sign and 15 bits for
+     fraction, resulting in a base range of -1.0 ..  1.0-2.0**(-15).
+
+                              _Examples_
+
+25
+Examples of fixed point types and subtypes:
+
+26
+     type Volt is delta 0.125 range 0.0 .. 255.0;
+
+27
+       -- A pure fraction which requires all the available
+       -- space in a word can be declared as the type Fraction:
+     type Fraction is delta System.Fine_Delta range -1.0 .. 1.0;
+       -- Fraction'Last = 1.0 - System.Fine_Delta
+
+28
+     type Money is delta 0.01 digits 15;  -- decimal fixed point
+     subtype Salary is Money digits 10;
+       -- Money'Last = 10.0**13 - 0.01, Salary'Last = 10.0**8 - 0.01
+
+                     _Inconsistencies With Ada 83_
+
+28.a
+          In Ada 95, S'Small always equals S'Base'Small, so if an
+          implementation chooses a small for a fixed point type smaller
+          than required by the delta, the value of S'Small in Ada 95
+          might not be the same as it was in Ada 83.
+
+                        _Extensions to Ada 83_
+
+28.b/3
+          {AI05-0005-1AI05-0005-1} Decimal fixed point types are new,
+          though their capabilities are essentially similar to that
+          available in Ada 83 with a fixed point type whose small equals
+          its delta and both are a power of 10.  However, in the
+          Information Systems Annex, additional requirements are placed
+          on the support of decimal fixed point types (e.g.  a minimum
+          of 18 digits of precision).
+
+                     _Wording Changes from Ada 83_
+
+28.c
+          The syntax rules for fixed_point_constraint and
+          fixed_accuracy_definition are removed.  The syntax rule for
+          fixed_point_definition is new.  A syntax rule for
+          delta_constraint is included in the Obsolescent features (to
+          be compatible with Ada 83's fixed_point_constraint).
+
+                     _Wording Changes from Ada 95_
+
+28.d/2
+          {AI95-00100-01AI95-00100-01} Added wording to define the
+          machine numbers of fixed point types; this is needed by the
+          static evaluation rules.
+
+
+File: aarm2012.info,  Node: 3.5.10,  Prev: 3.5.9,  Up: 3.5
+
+3.5.10 Operations of Fixed Point Types
+--------------------------------------
+
+                          _Static Semantics_
+
+1
+The following attributes are defined for every fixed point subtype S:
+
+2/1
+S'Small
+               {8652/00058652/0005} {AI95-00054-01AI95-00054-01} S'Small
+               denotes the small of the type of S. The value of this
+               attribute is of the type universal_real.  Small may be
+               specified for nonderived ordinary fixed point types via
+               an attribute_definition_clause (*note 13.3: S0309.) (see
+               *note 13.3::); the expression of such a clause shall be
+               static.
+
+2.a/3
+          Aspect Description for Small: Scale factor for a fixed point
+          type.
+
+3
+S'Delta
+               S'Delta denotes the delta of the fixed point subtype S.
+               The value of this attribute is of the type
+               universal_real.
+
+3.a
+          Reason: The delta is associated with the subtype as opposed to
+          the type, because of the possibility of an (obsolescent)
+          delta_constraint.
+
+4
+S'Fore
+               S'Fore yields the minimum number of characters needed
+               before the decimal point for the decimal representation
+               of any value of the subtype S, 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 2.)  The value of
+               this attribute is of the type universal_integer.
+
+5
+S'Aft
+               S'Aft yields the number of decimal digits needed after
+               the decimal point to accommodate the delta of the subtype
+               S, unless the delta of the subtype S is greater than 0.1,
+               in which case the attribute yields the value one.
+               [(S'Aft is the smallest positive integer N for which
+               (10**N)*S'Delta is greater than or equal to one.)]  The
+               value of this attribute is of the type universal_integer.
+
+6
+The following additional attributes are defined for every decimal fixed
+point subtype S:
+
+7
+S'Digits
+               S'Digits denotes the digits of the decimal fixed point
+               subtype S, which corresponds to the number of decimal
+               digits that are representable in objects of the subtype.
+               The value of this attribute is of the type
+               universal_integer.  Its value is determined as follows: 
+
+8
+                  * For a first subtype or a subtype defined by a
+                    subtype_indication with a digits_constraint, the
+                    digits is the value of the expression given after
+                    the reserved word digits;
+
+9
+                  * For a subtype defined by a subtype_indication
+                    without a digits_constraint, the digits of the
+                    subtype is the same as that of the subtype denoted
+                    by the subtype_mark in the subtype_indication.
+
+9.a
+          Implementation Note: Although a decimal subtype can be both
+          range-constrained and digits-constrained, the digits
+          constraint is intended to control the Size attribute of the
+          subtype.  For decimal types, Size can be important because
+          input/output of decimal types is so common.
+
+10
+                  * The digits of a base subtype is the largest integer
+                    D such that the range -(10**D-1)*delta ..
+                    +(10**D-1)*delta is included in the base range of
+                    the type.
+
+11
+S'Scale
+               S'Scale denotes the scale of the subtype S, defined as
+               the value N such that S'Delta = 10.0**(-N). [The scale
+               indicates the position of the point relative to the
+               rightmost significant digits of values of subtype S.] The
+               value of this attribute is of the type universal_integer.
+
+11.a
+          Ramification: S'Scale is negative if S'Delta is greater than
+          one.  By contrast, S'Aft is always positive.
+
+12
+S'Round
+               S'Round denotes a function with the following
+               specification:
+
+13
+                    function S'Round(X : universal_real)
+                      return S'Base
+
+14
+               The function returns the value obtained by rounding X
+               (away from 0, if X is midway between two values of the
+               type of S).
+
+     NOTES
+
+15
+     42  All subtypes of a fixed point type will have the same value for
+     the Delta attribute, in the absence of delta_constraints (see *note
+     J.3::).
+
+16
+     43  S'Scale is not always the same as S'Aft for a decimal subtype;
+     for example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0.
+
+17
+     44  The predefined operations of a fixed point type include the
+     assignment operation, qualification, the membership tests, and
+     explicit conversion to and from other numeric types.  They also
+     include the relational operators and the following predefined
+     arithmetic operators: the binary and unary adding operators - and
+     +, multiplying operators, and the unary operator abs.
+
+18
+     45  As for all types, objects of a fixed point type have Size and
+     Address attributes (see *note 13.3::).  Other attributes of fixed
+     point types are defined in *note A.5.4::.
+
+                     _Wording Changes from Ada 95_
+
+18.a/2
+          {8652/00058652/0005} {AI95-00054-01AI95-00054-01} Corrigendum:
+          Clarified that small may be specified only for ordinary fixed
+          point types.
+
+
+File: aarm2012.info,  Node: 3.6,  Next: 3.7,  Prev: 3.5,  Up: 3
+
+3.6 Array Types
+===============
+
+1
+An array object is a composite object consisting of components which all
+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 the
+components.
+
+                               _Syntax_
+
+2
+     array_type_definition ::=
+        unconstrained_array_definition | constrained_array_definition
+
+3
+     unconstrained_array_definition ::=
+        array(index_subtype_definition {, index_subtype_definition}) of 
+     component_definition
+
+4
+     index_subtype_definition ::= subtype_mark range <>
+
+5
+     constrained_array_definition ::=
+        array (discrete_subtype_definition {, 
+     discrete_subtype_definition}) of component_definition
+
+6
+     discrete_subtype_definition ::= discrete_subtype_indication | range
+
+7/2
+     {AI95-00230-01AI95-00230-01} {AI95-00406-01AI95-00406-01}
+     component_definition ::=
+        [aliased] subtype_indication
+      | [aliased] access_definition
+
+                        _Name Resolution Rules_
+
+8
+For a discrete_subtype_definition that is a range, the range shall
+resolve to be of some specific discrete type[; which discrete type shall
+be determined without using any context other than the bounds of the
+range itself (plus the preference for root_integer -- see *note 8.6::).]
+
+                           _Legality Rules_
+
+9
+Each index_subtype_definition or discrete_subtype_definition in an
+array_type_definition defines an index subtype; its type (the index
+type) shall be discrete.
+
+9.a
+          Discussion: An index is a discrete quantity used to select
+          along a given dimension of an array.  A component is selected
+          by specifying corresponding values for each of the indices.
+
+10
+The subtype defined by the subtype_indication of a component_definition
+(the component subtype) shall be a definite subtype.
+
+10.a
+          Ramification: This applies to all uses of
+          component_definition, including in record_type_definitions and
+          protected_definitions.
+
+11/2
+This paragraph was deleted.{AI95-00363-01AI95-00363-01}
+
+                          _Static Semantics_
+
+12
+An array is characterized by the number of indices (the dimensionality
+of the array), the type and position of each index, the lower and upper
+bounds for each index, and the subtype of the components.  The order of
+the indices is significant.
+
+13
+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 index range.  The bounds
+of an array are the bounds of its index ranges.  The length of a
+dimension of an array is the number of values of the index range of the
+dimension (zero for a null range).  The length of a one-dimensional
+array is the length of its only dimension.
+
+14
+An array_type_definition defines an array type and its first subtype.
+For each object of this 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 of its type, except for
+null arrays (see *note 3.6.1::)].
+
+15
+An unconstrained_array_definition defines an array type with an
+unconstrained first subtype.  Each index_subtype_definition (*note 3.6:
+S0053.) defines the corresponding index subtype to be the subtype
+denoted by the subtype_mark (*note 3.2.2: S0028.).  [ The compound
+delimiter <> (called a box) of an index_subtype_definition stands for an
+undefined range (different objects of the type need not have the same
+bounds).]
+
+16
+A constrained_array_definition defines an array type with a constrained
+first subtype.  Each discrete_subtype_definition (*note 3.6: S0055.)
+defines the corresponding index subtype, as well as the corresponding
+index range for the constrained first subtype.  The constraint of the
+first subtype consists of the bounds of the index ranges.
+
+16.a/3
+          Discussion: {AI05-0005-1AI05-0005-1} Although there is no
+          nameable unconstrained array subtype in this case, the
+          predefined slicing and concatenation operations can operate on
+          and yield values that do not necessarily belong to the first
+          array subtype.  This is also true for Ada 83.
+
+17
+The discrete subtype defined by a discrete_subtype_definition (*note
+3.6: S0055.) is either that defined by the subtype_indication (*note
+3.2.2: S0027.), or a subtype determined by the range as follows:
+
+18
+   * If the type of the range resolves to root_integer, then the
+     discrete_subtype_definition defines a subtype of the predefined
+     type Integer with bounds given by a conversion to Integer of the
+     bounds of the range; 
+
+18.a
+          Reason: This ensures that indexing over the discrete subtype
+          can be performed with regular Integers, rather than only
+          universal_integers.
+
+18.b
+          Discussion: We considered doing this by simply creating a
+          "preference" for Integer when resolving the range.  However,
+          this can introduce Beaujolais effects when the
+          simple_expressions involve calls on functions visible due to
+          use clauses.
+
+19
+   * Otherwise, the discrete_subtype_definition defines a subtype of the
+     type of the range, with the bounds given by the range.
+
+20
+The component_definition of an array_type_definition defines the nominal
+subtype of the components.  If the reserved word aliased appears in the
+component_definition, then each component of the array is aliased (see
+*note 3.10::).
+
+                          _Dynamic Semantics_
+
+21
+The elaboration of an array_type_definition creates the array type and
+its first subtype, and consists of the elaboration of any
+discrete_subtype_definition (*note 3.6: S0055.)s and the
+component_definition (*note 3.6: S0056.).
+
+22/2
+{8652/00028652/0002} {AI95-00171-01AI95-00171-01}
+{AI95-00230-01AI95-00230-01} The elaboration of a
+discrete_subtype_definition that does not contain any per-object
+expressions creates the discrete subtype, and consists of the
+elaboration of the subtype_indication (*note 3.2.2: S0027.) or the
+evaluation of the range.  The elaboration of a
+discrete_subtype_definition that contains one or more per-object
+expressions is defined in *note 3.8::.  The elaboration of a
+component_definition (*note 3.6: S0056.) in an array_type_definition
+(*note 3.6: S0051.) consists of the elaboration of the
+subtype_indication (*note 3.2.2: S0027.) or access_definition.  The
+elaboration of any discrete_subtype_definition (*note 3.6: S0055.)s and
+the elaboration of the component_definition (*note 3.6: S0056.) are
+performed in an arbitrary order.
+
+                          _Static Semantics_
+
+22.1/3
+{AI05-0228-1AI05-0228-1} For an array type with a scalar component type,
+the following language-defined representation aspect may be specified
+with an aspect_specification (see *note 13.1.1::):
+
+22.2/3
+Default_Component_Value
+               This aspect shall be specified by a static expression,
+               and that expression shall be explicit, even if the aspect
+               has a boolean type.  Default_Component_Value shall be
+               specified only on a full_type_declaration.
+
+22.a/3
+          Reason: The part about requiring an explicit expression is to
+          disallow omitting the value for this aspect, which would
+          otherwise be allowed by the rules of *note 13.1.1::.
+
+22.b/3
+          This is a representation attribute in order to disallow
+          specifying it on a derived type that has inherited primitive
+          subprograms; that is necessary as the sizes of out parameters
+          could be different whether or not a Default_Value is specified
+          (see *note 6.4.1::).
+
+22.c/3
+          Aspect Description for Default_Component_Value: Default value
+          for the components of an array-of-scalar subtype.
+
+22.3/3
+{AI05-0228-1AI05-0228-1} If a derived type with no primitive subprograms
+inherits a boolean Default_Component_Value aspect, the aspect may be
+specified to have any value for the derived type.
+
+22.d/3
+          Reason: This overrides the *note 13.1.1:: rule that says that
+          a boolean aspect with a value True cannot be changed.
+
+                        _Name Resolution Rules_
+
+22.4/3
+{AI05-0228-1AI05-0228-1} The expected type for the expression specified
+for the Default_Component_Value aspect is the component type of the
+array type defined by the full_type_declaration on which it appears.
+
+     NOTES
+
+23
+     46  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.
+
+24
+     47  Each elaboration of an array_type_definition creates a distinct
+     array type.  A consequence of this is that each object whose
+     object_declaration contains an array_type_definition is of its own
+     unique type.
+
+                              _Examples_
+
+25
+Examples of type declarations with unconstrained array definitions:
+
+26
+     type Vector     is array(Integer  range <>) of Real;
+     type Matrix     is array(Integer  range <>, Integer range <>) of Real;
+     type Bit_Vector is array(Integer  range <>) of Boolean;
+     type Roman      is array(Positive range <>) of Roman_Digit; -- see *note 
3.5.2::
+
+27
+Examples of type declarations with constrained array definitions:
+
+28
+     type Table    is array(1 .. 10) of Integer;
+     type Schedule is array(Day) of Boolean;
+     type Line     is array(1 .. Max_Line_Size) of Character;
+
+29
+Examples of object declarations with array type definitions:
+
+30/2
+     {AI95-00433-01AI95-00433-01} Grid      : array(1 .. 80, 1 .. 100) of 
Boolean;
+     Mix       : array(Color range Red .. Green) of Boolean;
+     Msg_Table : constant array(Error_Code) of access constant String :=
+           (Too_Big => new String'("Result too big"), Too_Small => ...);
+     Page      : array(Positive range <>) of Line :=  --  an array of arrays
+       (1 | 50  => Line'(1 | Line'Last => '+', others => '-'),  -- see *note 
4.3.3::
+        2 .. 49 => Line'(1 | Line'Last => '|', others => ' '));
+         -- Page is constrained by its initial value to (1..50)
+
+                        _Extensions to Ada 83_
+
+30.a
+          The syntax rule for component_definition is modified to allow
+          the reserved word aliased.
+
+30.b
+          The syntax rules for unconstrained_array_definition and
+          constrained_array_definition are modified to use
+          component_definition (instead of
+          component_subtype_indication).  The effect of this change is
+          to allow the reserved word aliased before the component
+          subtype_indication.
+
+30.c
+          A range in a discrete_subtype_definition may use arbitrary
+          universal expressions for each bound (e.g.  -1 ..  3+5),
+          rather than strictly "implicitly convertible" operands.  The
+          subtype defined will still be a subtype of Integer.
+
+                     _Wording Changes from Ada 83_
+
+30.d
+          We introduce a new syntactic category,
+          discrete_subtype_definition, as distinct from discrete_range.
+          These two constructs have the same syntax, but their semantics
+          are quite different (one defines a subtype, with a preference
+          for Integer subtypes, while the other just selects a subrange
+          of an existing subtype).  We use this new syntactic category
+          in for loops and entry families.
+
+30.e
+          The syntax for index_constraint and discrete_range have been
+          moved to their own subclause, since they are no longer used
+          here.
+
+30.f
+          The syntax rule for component_definition (formerly
+          component_subtype_definition) is moved here from RM83-3.7.
+
+                        _Extensions to Ada 95_
+
+30.g/2
+          {AI95-00230-01AI95-00230-01} {AI95-00406-01AI95-00406-01}
+          Array components can have an anonymous access type.
+
+30.h/2
+          {AI95-00363-01AI95-00363-01} The prohibition against
+          unconstrained discriminated aliased components has been
+          lifted.  It has been replaced by a prohibition against the
+          actual troublemakers: general access discriminant constraints
+          (see *note 3.7.1::).
+
+                     _Wording Changes from Ada 95_
+
+30.i/2
+          {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+          Added wording to allow the elaboration of per-object
+          constraints for constrained arrays.
+
+                       _Extensions to Ada 2005_
+
+30.j/3
+          {AI05-0228-1AI05-0228-1} The new aspect
+          Default_Component_Value allows defining implicit initial
+          values (see *note 3.3.1::) for arrays of scalar types.
+
+* Menu:
+
+* 3.6.1 ::    Index Constraints and Discrete Ranges
+* 3.6.2 ::    Operations of Array Types
+* 3.6.3 ::    String Types
+
+
+File: aarm2012.info,  Node: 3.6.1,  Next: 3.6.2,  Up: 3.6
+
+3.6.1 Index Constraints and Discrete Ranges
+-------------------------------------------
+
+1
+An index_constraint determines the range of possible values for every
+index of an array subtype, and thereby the corresponding array bounds.
+
+                               _Syntax_
+
+2
+     index_constraint ::=  (discrete_range {, discrete_range})
+
+3
+     discrete_range ::= discrete_subtype_indication | range
+
+                        _Name Resolution Rules_
+
+4
+The type of a discrete_range is the type of the subtype defined by the
+subtype_indication, or the type of the range.  For an index_constraint,
+each discrete_range shall resolve to be of the type of the corresponding
+index.
+
+4.a
+          Discussion: In Ada 95, index_constraints only appear in a
+          subtype_indication; they no longer appear in
+          constrained_array_definitions.
+
+                           _Legality Rules_
+
+5
+An index_constraint shall appear only in a subtype_indication whose
+subtype_mark denotes either an unconstrained array subtype, or an
+unconstrained access subtype whose designated subtype is an
+unconstrained array subtype; in either case, the index_constraint shall
+provide a discrete_range for each index of the array type.
+
+                          _Static Semantics_
+
+6
+A discrete_range defines a range whose bounds are given by the range, or
+by the range of the subtype defined by the subtype_indication.
+
+                          _Dynamic Semantics_
+
+7
+An index_constraint is compatible with an unconstrained array subtype if
+and only if the index range defined by each discrete_range is compatible
+(see *note 3.5::) with the corresponding index subtype.  If any of the
+discrete_ranges defines a null range, any array thus constrained is a
+null array, having no components.  An array value satisfies an
+index_constraint if at each index position the array value and the
+index_constraint have the same index bounds.
+
+7.a
+          Ramification: There is no need to define compatibility with a
+          constrained array subtype, because one is not allowed to
+          constrain it again.
+
+8
+The elaboration of an index_constraint consists of the evaluation of the
+discrete_range(s), in an arbitrary order.  The evaluation of a
+discrete_range consists of the elaboration of the subtype_indication or
+the evaluation of the range.
+
+     NOTES
+
+9
+     48  The elaboration of a subtype_indication consisting of a
+     subtype_mark followed by an index_constraint checks the
+     compatibility of the index_constraint with the subtype_mark (see
+     *note 3.2.2::).
+
+10
+     49  Even if an array value does not satisfy the index constraint of
+     an array subtype, Constraint_Error is not raised on conversion to
+     the array subtype, so long as the length of each dimension of the
+     array value and the array subtype match.  See *note 4.6::.
+
+                              _Examples_
+
+11
+Examples of array declarations including an index constraint:
+
+12
+     Board     : Matrix(1 .. 8,  1 .. 8);  --  see *note 3.6::
+     Rectangle : Matrix(1 .. 20, 1 .. 30);
+     Inverse   : Matrix(1 .. N,  1 .. N);  --  N need not be static 
+
+13
+     Filter    : Bit_Vector(0 .. 31);
+
+14
+Example of array declaration with a constrained array subtype:
+
+15
+     My_Schedule : Schedule;  --  all arrays of type Schedule have the same 
bounds
+
+16
+Example of record type with a component that is an array:
+
+17
+     type Var_Line(Length : Natural) is
+        record
+           Image : String(1 .. Length);
+        end record;
+
+18
+     Null_Line : Var_Line(0);  --  Null_Line.Image is a null array
+
+                        _Extensions to Ada 83_
+
+18.a
+          We allow the declaration of a variable with a nominally
+          unconstrained array subtype, so long as it has an
+          initialization expression to determine its bounds.
+
+                     _Wording Changes from Ada 83_
+
+18.b
+          We have moved the syntax for index_constraint and
+          discrete_range here since they are no longer used in
+          constrained_array_definitions.  We therefore also no longer
+          have to describe the (special) semantics of index_constraints
+          and discrete_ranges that appear in
+          constrained_array_definitions.
+
+18.c
+          The rules given in RM83-3.6.1(5,7-10), which define the bounds
+          of an array object, are redundant with rules given elsewhere,
+          and so are not repeated here.  RM83-3.6.1(6), which requires
+          that the (nominal) subtype of an array variable be
+          constrained, no longer applies, so long as the variable is
+          explicitly initialized.
+
+
+File: aarm2012.info,  Node: 3.6.2,  Next: 3.6.3,  Prev: 3.6.1,  Up: 3.6
+
+3.6.2 Operations of Array Types
+-------------------------------
+
+                           _Legality Rules_
+
+1
+[The argument N used in the attribute_designators for the N-th dimension
+of an array shall be a static expression of some integer type.]  The
+value of N shall be positive (nonzero) and no greater than the
+dimensionality of the array.
+
+                          _Static Semantics_
+
+2/1
+{8652/00068652/0006} {AI95-00030-01AI95-00030-01} The following
+attributes are defined for a prefix A that is of an array type [(after
+any implicit dereference)], or denotes a constrained array subtype:
+
+2.a
+          Ramification: These attributes are not defined if A is a
+          subtype-mark for an access-to-array subtype.  They are defined
+          (by implicit dereference) for access-to-array values.
+
+3
+A'First
+               A'First denotes the lower bound of the first index range;
+               its type is the corresponding index type.
+
+4
+A'First(N)
+               A'First(N) denotes the lower bound of the N-th index
+               range; its type is the corresponding index type.
+
+5
+A'Last
+               A'Last denotes the upper bound of the first index range;
+               its type is the corresponding index type.
+
+6
+A'Last(N)
+               A'Last(N) denotes the upper bound of the N-th index
+               range; its type is the corresponding index type.
+
+7
+A'Range
+               A'Range is equivalent to the range A'First ..  A'Last,
+               except that the prefix A is only evaluated once.
+
+8
+A'Range(N)
+               A'Range(N) is equivalent to the range A'First(N) ..
+               A'Last(N), except that the prefix A is only evaluated
+               once.
+
+9
+A'Length
+               A'Length denotes the number of values of the first index
+               range (zero for a null range); its type is
+               universal_integer.
+
+10
+A'Length(N)
+               A'Length(N) denotes the number of values of the N-th
+               index range (zero for a null range); its type is
+               universal_integer.
+
+                        _Implementation Advice_
+
+11/3
+{AI05-0229-1AI05-0229-1} An implementation should normally represent
+multidimensional arrays in row-major order, consistent with the notation
+used for multidimensional array aggregates (see *note 4.3.3::).
+However, if convention Fortran is specified for a multidimensional array
+type, then column-major order should be used instead (see *note B.5::,
+"*note B.5:: Interfacing with Fortran").
+
+11.a/2
+          Implementation Advice: Multidimensional arrays should be
+          represented in row-major order, unless the array has
+          convention Fortran.
+
+     NOTES
+
+12
+     50  The attribute_references A'First and A'First(1) denote the same
+     value.  A similar relation exists for the attribute_references
+     A'Last, A'Range, and A'Length.  The following relation is satisfied
+     (except for a null array) by the above attributes if the index type
+     is an integer type:
+
+13
+             A'Length(N) = A'Last(N) - A'First(N) + 1
+
+14
+     51  An array type is limited if its component type is limited (see
+     *note 7.5::).
+
+15
+     52  The predefined operations of an array type include the
+     membership tests, qualification, and explicit conversion.  If the
+     array type is not limited, they also include assignment and the
+     predefined equality operators.  For a one-dimensional array type,
+     they include the predefined concatenation operators (if nonlimited)
+     and, if the component type is discrete, the predefined relational
+     operators; if the component type is boolean, the predefined logical
+     operators are also included.
+
+16/2
+     53  {AI95-00287-01AI95-00287-01} A component of an array can be
+     named with an indexed_component.  A value of an array type can be
+     specified with an array_aggregate.  For a one-dimensional array
+     type, a slice of the array can be named; also, string literals are
+     defined if the component type is a character type.
+
+                              _Examples_
+
+17
+Examples (using arrays declared in the examples of subclause *note
+3.6.1::):
+
+18
+     --  Filter'First      =   0   Filter'Last       =  31   Filter'Length =  
32
+     --  Rectangle'Last(1) =  20   Rectangle'Last(2) =  30
+
+
+File: aarm2012.info,  Node: 3.6.3,  Prev: 3.6.2,  Up: 3.6
+
+3.6.3 String Types
+------------------
+
+                          _Static Semantics_
+
+1
+A one-dimensional array type whose component type is a character type is
+called a string type.
+
+2/2
+{AI95-00285-01AI95-00285-01} [There are three predefined string types,
+String, Wide_String, and Wide_Wide_String, each indexed by values of the
+predefined subtype Positive; these are declared in the visible part of
+package Standard:]
+
+3
+     [subtype Positive is Integer range 1 .. Integer'Last;
+
+4/2
+     {AI95-00285-01AI95-00285-01} type String is array(Positive range <>) of 
Character;
+     type Wide_String is array(Positive range <>) of Wide_Character;
+     type Wide_Wide_String is array(Positive range <>) of Wide_Wide_Character;
+     ]
+
+     NOTES
+
+5
+     54  String literals (see *note 2.6:: and *note 4.2::) are defined
+     for all string types.  The concatenation operator & is predefined
+     for string types, as for all nonlimited one-dimensional array
+     types.  The ordering operators <, <=, >, and >= are predefined for
+     string types, as for all one-dimensional discrete array types;
+     these ordering operators correspond to lexicographic order (see
+     *note 4.5.2::).
+
+                              _Examples_
+
+6
+Examples of string objects:
+
+7
+     Stars      : String(1 .. 120) := (1 .. 120 => '*' );
+     Question   : constant String  := "How many characters?";
+        -- Question'First = 1, Question'Last = 20
+        -- Question'Length = 20 (the number of characters)
+
+8
+     Ask_Twice  : String  := Question & Question;   -- constrained to (1..40)
+     Ninety_Six : constant Roman   := "XCVI";   -- see *note 3.5.2:: and *note 
3.6::
+
+                     _Inconsistencies With Ada 83_
+
+8.a
+          The declaration of Wide_String in Standard hides a use-visible
+          declaration with the same defining_identifier.  In rare cases,
+          this might result in an inconsistency between Ada 83 and Ada
+          95.
+
+                    _Incompatibilities With Ada 83_
+
+8.b
+          Because both String and Wide_String are always directly
+          visible, an expression like
+
+8.c
+               "a" < "bc"
+
+8.d
+          is now ambiguous, whereas in Ada 83 both string literals could
+          be resolved to type String.
+
+                        _Extensions to Ada 83_
+
+8.e
+          The type Wide_String is new (though it was approved by ARG for
+          Ada 83 compilers as well).
+
+                     _Wording Changes from Ada 83_
+
+8.f
+          We define the term string type as a natural analogy to the
+          term character type.
+
+                     _Inconsistencies With Ada 95_
+
+8.g/2
+          {AI95-00285-01AI95-00285-01} The declaration of
+          Wide_Wide_String in Standard hides a use-visible declaration
+          with the same defining_identifier.  In the (very) unlikely
+          event that an Ada 95 program had depended on such a
+          use-visible declaration, and the program remains legal after
+          the substitution of Standard.Wide_Wide_String, the meaning of
+          the program will be different.
+
+                        _Extensions to Ada 95_
+
+8.h/2
+          {AI95-00285-01AI95-00285-01} The type Wide_Wide_String is new.
+
+
+File: aarm2012.info,  Node: 3.7,  Next: 3.8,  Prev: 3.6,  Up: 3
+
+3.7 Discriminants
+=================
+
+1/2
+{AI95-00251-01AI95-00251-01} {AI95-00326-01AI95-00326-01} [ A composite
+type (other than an array or interface type) can have discriminants,
+which parameterize the type.  A known_discriminant_part specifies the
+discriminants of a composite type.  A discriminant of an object is a
+component of the object, and is either of a discrete type or an access
+type.  An unknown_discriminant_part in the declaration of a view of a
+type specifies that the discriminants of the type are unknown for the
+given view; all subtypes of such a view are indefinite subtypes.]
+
+1.a/2
+          Glossary entry: A discriminant is a parameter for a composite
+          type.  It can control, for example, the bounds of a component
+          of the type if the component is an array.  A discriminant for
+          a task type can be used to pass data to a task of the type
+          upon creation.
+
+1.b/2
+          Discussion: {AI95-00114-01AI95-00114-01} A view of a type, and
+          all subtypes of the view, have unknown discriminants when the
+          number or names of the discriminants, if any, are unknown at
+          the point of the type declaration for the view.  A
+          discriminant_part of (<>) is used to indicate unknown
+          discriminants.
+
+                     _Language Design Principles_
+
+1.c/2
+          {AI95-00402-01AI95-00402-01} When an access discriminant is
+          initialized at the time of object creation with an allocator
+          of an anonymous type, the allocated object and the object with
+          the discriminant are tied together for their lifetime.  They
+          should be allocated out of the same storage pool, and then at
+          the end of the lifetime of the enclosing object, finalized and
+          reclaimed together.  In this case, the allocated object is
+          called a coextension (see *note 3.10.2::).
+
+1.d/2
+          Discussion: The above principle when applied to a nonlimited
+          type implies that such an object may be copied only to a
+          shorter-lived object, because attempting to assign it to a
+          longer-lived object would fail because the access
+          discriminants would not match.  In a copy, the lifetime
+          connection between the enclosing object and the allocated
+          object does not exist.  The allocated object is tied in the
+          above sense only to the original object.  Other copies have
+          only secondary references to it.
+
+1.e/2
+          Note that when an allocator appears as a constraint on an
+          access discriminant in a subtype_indication that is elaborated
+          independently from object creation, no such connection exists.
+          For example, if a named constrained subtype is declared via
+          "subtype Constr is Rec(Acc_Discrim => new T);" or if such an
+          allocator appears in the subtype_indication for a component,
+          the allocator is evaluated when the subtype_indication is
+          elaborated, and hence its lifetime is typically longer than
+          the objects or components that will later be subject to the
+          constraint.  In these cases, the allocated object should not
+          be reclaimed until the subtype_indication goes out of scope.
+
+                               _Syntax_
+
+2
+     discriminant_part ::= unknown_discriminant_part | 
+     known_discriminant_part
+
+3
+     unknown_discriminant_part ::= (<>)
+
+4
+     known_discriminant_part ::=
+        (discriminant_specification {; discriminant_specification})
+
+5/2
+     {AI95-00231-01AI95-00231-01} discriminant_specification ::=
+        defining_identifier_list : [null_exclusion] subtype_mark [:= 
+     default_expression]
+      | defining_identifier_list : access_definition [:= 
+     default_expression]
+
+6
+     default_expression ::= expression
+
+                        _Name Resolution Rules_
+
+7
+The expected type for the default_expression of a
+discriminant_specification is that of the corresponding discriminant.
+
+                           _Legality Rules_
+
+8/2
+{8652/00078652/0007} {AI95-00098-01AI95-00098-01}
+{AI95-00251-01AI95-00251-01} A discriminant_part is only permitted in a
+declaration for a composite type that is not an array or interface type
+[(this includes generic formal types)].  A type declared with a
+known_discriminant_part is called a discriminated type, as is a type
+that inherits (known) discriminants.
+
+8.a
+          Implementation Note: Discriminants on array types were
+          considered, but were omitted to ease (existing)
+          implementations.
+
+8.b
+          Discussion: Note that the above definition for "discriminated
+          type" does not include types declared with an
+          unknown_discriminant_part.  This seems consistent with Ada 83,
+          where such types (in a generic formal part) would not be
+          considered discriminated types.  Furthermore, the full type
+          for a type with unknown discriminants need not even be
+          composite, much less have any discriminants.
+
+8.b.1/1
+          {8652/00078652/0007} {AI95-00098-01AI95-00098-01} On the other
+          hand, unknown_discriminant_parts cannot be applied to type
+          declarations that cannot have a known_discriminant_part.
+          There is no point in having unknown discriminants on a type
+          that can never have discriminants (for instance, a formal
+          modular type), even when these are allowed syntactically.
+
+9/2
+{AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01} The subtype of
+a discriminant may be defined by an optional null_exclusion and a
+subtype_mark, in which case the subtype_mark shall denote a discrete or
+access subtype, or it may be defined by an access_definition.  A
+discriminant that is defined by an access_definition is called an access
+discriminant and is of an anonymous access type.
+
+9.a/2
+          This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+
+9.b
+          Reason: Note that discriminants of a named access type are not
+          considered "access discriminants."  Similarly, "access
+          parameter" only refers to a formal parameter defined by an
+          access_definition.
+
+9.1/3
+{AI95-00402-01AI95-00402-01} {AI05-0214-1AI05-0214-1}
+Default_expressions shall be provided either for all or for none of the
+discriminants of a known_discriminant_part (*note 3.7: S0061.).  No
+default_expression (*note 3.7: S0063.)s are permitted in a
+known_discriminant_part (*note 3.7: S0061.) in a declaration of a
+nonlimited tagged type [or a generic formal type].
+
+9.c/2
+          Reason: The all-or-none rule is related to the rule that a
+          discriminant constraint shall specify values for all
+          discriminants.  One could imagine a different rule that
+          allowed a constraint to specify only some of the
+          discriminants, with the others provided by default.  Having
+          defaults for discriminants has a special significance -- it
+          allows objects of the type to be unconstrained, with the
+          discriminants alterable as part of assigning to the object.
+
+9.d/3
+          {AI05-0214-1AI05-0214-1} Defaults for discriminants of tagged
+          types are disallowed so that every object of a nonlimited
+          tagged type is constrained, either by an explicit constraint,
+          or by its initial discriminant values.  This substantially
+          simplifies the semantic rules and the implementation of
+          inherited dispatching operations.  We don't need this rule for
+          limited tagged types, as the discriminants of such objects
+          cannot be changed after the object is created in any case --
+          no full-object assignment is supported, and that is required
+          to change discriminant values.  For generic formal types, the
+          restriction simplifies the type matching rules.  If one simply
+          wants a "default" value for the discriminants, a constrained
+          subtype can be declared for future use.
+
+10/3
+{AI95-00230-01AI95-00230-01} {AI95-00402-01AI95-00402-01}
+{AI95-00419-01AI95-00419-01} {AI05-0063-1AI05-0063-1} A
+discriminant_specification for an access discriminant may have a
+default_expression only in the declaration for an immutably limited type
+(see *note 7.5::).  In addition to the places where Legality Rules
+normally apply (see *note 12.3::), this rule applies also in the private
+part of an instance of a generic unit.
+
+10.a/3
+          Discussion: This rule implies that a type can have a default
+          for an access discriminant if the type is limited, but not if
+          the only reason it's limited is because of a limited
+          component.  Compare the definition of limited type and
+          immutably limited type in *note 7.5::.
+
+10.b/3
+          Ramification: A (nonformal) limited private type can always
+          have a default for an access discriminant, because having the
+          default itself makes the type immutably limited.  Such a
+          private type must necessarily have a full type with the same
+          access discriminant with a default, and thus the full type
+          will always be immutably limited (if legal).
+
+10.c/2
+          Reason: {AI95-00230-01AI95-00230-01} We considered the
+          following rules for access discriminants:
+
+10.d
+             * If a type has an access discriminant, this automatically
+               makes it limited, just like having a limited component
+               automatically makes a type limited.  This was rejected
+               because it decreases program readability, and because it
+               seemed error prone (two bugs in a previous version of the
+               RM9X were attributable to this rule).
+
+10.e/2
+             * A type with an access discriminant shall be limited.
+               This is equivalent to the rule we actually chose for Ada
+               95, except that it allows a type to have an access
+               discriminant if it is limited just because of a limited
+               component.  For example, any record containing a task
+               would be allowed to have an access discriminant, whereas
+               the actual rule requires "limited record".  This rule was
+               also rejected due to readability concerns, and because
+               would interact badly with the rules for limited types
+               that "become nonlimited".
+
+10.e.1/3
+             * {AI05-0063-1AI05-0063-1} A type may have an access
+               discriminant if it is an immutably limited type.  This
+               was the rule chosen for Ada 95.
+
+10.f/2
+             * Any type may have an access discriminant.  For nonlimited
+               type, there is no special accessibility for access
+               discriminants; they're the same as any other anonymous
+               access component.  For a limited type, they have the
+               special accessibility of Ada 95.  However, this doesn't
+               work because a limited partial view can have a nonlimited
+               full view -- giving the two views different
+               accessibility.
+
+10.f.1/3
+             * {AI05-0063-1AI05-0063-1} Any type may have an access
+               discriminant, as above.  However, special accessibility
+               rules only apply to types that are immutably limited
+               (task, protected, and explicitly limited records).
+               However, this breaks privacy; worse, Legality Rules
+               depend on the definition of accessibility.
+
+10.f.2/3
+             * {AI05-0063-1AI05-0063-1} Any type may have an access
+               discriminant, as above.  Limited types have special
+               accessibility, while nonlimited types have normal
+               accessibility.  However, a limited partial view with an
+               access discriminant can only be completed by an immutably
+               limited type.  That prevents accessibility from changing.
+               A runtime accessibility check is required on generic
+               formal types with access discriminants.  However,
+               changing between limited and nonlimited types would have
+               far-reaching consequences for access discriminants --
+               which is uncomfortable.
+
+10.g/2
+             * Any type may have an access discriminant.  All types have
+               special accessibility.  This was considered early during
+               the Ada 9X process, but was dropped for "unpleasant
+               complexities", which unfortunately aren't recorded.  It
+               does seem that an accessibility check would be needed on
+               assignment of such a type, to avoid copying an object
+               with a discriminant pointing to a local object into a
+               more global object (and thus creating a dangling
+               pointer).
+
+10.h/2
+             * Any type may have an access discriminant, but access
+               discriminants cannot have defaults.  All types have
+               special accessibility.  This gets rid of the problems on
+               assignment (you couldn't change such a discriminant), but
+               it would be horribly incompatible with Ada 95.
+
+10.h.1/3
+             * {AI05-0063-1AI05-0063-1} Any type may have an access
+               discriminant, but access discriminants may have defaults
+               only if they are of an immutably limited type.  This is
+               the rule chosen for Ada 2005, as it is not incompatible,
+               and it doesn't require weird accessibility checks.
+
+11/2
+This paragraph was deleted.{AI95-00402-01AI95-00402-01}
+
+12
+For a type defined by a derived_type_definition, if a
+known_discriminant_part is provided in its declaration, then:
+
+13
+   * The parent subtype shall be constrained;
+
+14
+   * If the parent type is not a tagged type, then each discriminant of
+     the derived type shall be used in the constraint defining the
+     parent subtype;
+
+14.a
+          Implementation Note: This ensures that the new discriminant
+          can share storage with an existing discriminant.
+
+15
+   * If a discriminant is used in the constraint defining the parent
+     subtype, the subtype of the discriminant shall be statically
+     compatible (see *note 4.9.1::) with the subtype of the
+     corresponding parent discriminant.
+
+15.a
+          Reason: This ensures that on conversion (or extension via an
+          extension aggregate) to a distantly related type, if the
+          discriminants satisfy the target type's requirements they
+          satisfy all the intermediate types' requirements as well.
+
+15.b
+          Ramification: There is no requirement that the new
+          discriminant have the same (or any) default_expression as the
+          parent's discriminant.
+
+16/3
+This paragraph was deleted.{AI05-0102-1AI05-0102-1}
+
+16.a/3
+          This paragraph was deleted.
+
+                          _Static Semantics_
+
+17
+A discriminant_specification declares a discriminant; the subtype_mark
+denotes its subtype unless it is an access discriminant, in which case
+the discriminant's subtype is the anonymous access-to-variable subtype
+defined by the access_definition.
+
+18
+[For a type defined by a derived_type_definition, each discriminant of
+the parent type is either inherited, constrained to equal some new
+discriminant of the derived type, or constrained to the value of an
+expression.]  When inherited or constrained to equal some new
+discriminant, the parent discriminant and the discriminant of the
+derived type are said to correspond.  Two discriminants also correspond
+if there is some common discriminant to which they both correspond.  A
+discriminant corresponds to itself as well.  If a discriminant of a
+parent type is constrained to a specific value by a
+derived_type_definition, then that discriminant is said to be specified
+by that derived_type_definition.
+
+18.a
+          Ramification: The correspondence relationship is transitive,
+          symmetric, and reflexive.  That is, if A corresponds to B, and
+          B corresponds to C, then A, B, and C each corresponds to A, B,
+          and C in all combinations.
+
+19
+A constraint that appears within the definition of a discriminated type
+depends on a discriminant of the type if it names the discriminant as a
+bound or discriminant value.  A component_definition depends on a
+discriminant if its constraint depends on the discriminant, or on a
+discriminant that corresponds to it.
+
+19.a
+          Ramification: A constraint in a task_body is not considered to
+          depend on a discriminant of the task type, even if it names
+          it.  It is only the constraints in the type definition itself
+          that are considered dependents.  Similarly for protected
+          types.
+
+20
+A component depends on a discriminant if:
+
+21
+   * Its component_definition depends on the discriminant; or
+
+21.a
+          Ramification: A component does not depend on a discriminant
+          just because its default_expression refers to the
+          discriminant.
+
+22
+   * It is declared in a variant_part that is governed by the
+     discriminant; or
+
+23
+   * It is a component inherited as part of a derived_type_definition,
+     and the constraint of the parent_subtype_indication depends on the
+     discriminant; or
+
+23.a
+          Reason: When the parent subtype depends on a discriminant, the
+          parent part of the derived type is treated like a
+          discriminant-dependent component.
+
+23.b
+          Ramification: Because of this rule, we don't really need to
+          worry about "corresponding" discriminants, since all the
+          inherited components will be discriminant-dependent if there
+          is a new known_discriminant_part whose discriminants are used
+          to constrain the old discriminants.
+
+24
+   * It is a subcomponent of a component that depends on the
+     discriminant.
+
+24.a
+          Reason: The concept of discriminant-dependent (sub)components
+          is primarily used in various rules that disallow renaming or
+          'Access, or specify that certain discriminant-changing
+          assignments are erroneous.  The goal is to allow
+          implementations to move around or change the size of
+          discriminant-dependent subcomponents upon a
+          discriminant-changing assignment to an enclosing object.  The
+          above definition specifies that all subcomponents of a
+          discriminant-dependent component or parent part are themselves
+          discriminant-dependent, even though their presence or size
+          does not in fact depend on a discriminant.  This is because it
+          is likely that they will move in a discriminant-changing
+          assignment if they are a component of one of several
+          discriminant-dependent parts of the same record.
+
+25
+Each value of a discriminated type includes a value for each component
+of the type that does not depend on a discriminant[; this includes the
+discriminants themselves].  The values of discriminants determine which
+other component values are present in the value of the discriminated
+type.
+
+25.a
+          To be honest: Which values are present might depend on
+          discriminants of some ancestor type that are constrained in an
+          intervening derived_type_definition.  That's why we say
+          "values of discriminants" instead of "values of the
+          discriminants" -- a subtle point.
+
+26
+A type declared with a known_discriminant_part is said to have known
+discriminants; its first subtype is unconstrained.  A type declared with
+an unknown_discriminant_part is said to have unknown discriminants.  A
+type declared without a discriminant_part has no discriminants, unless
+it is a derived type; if derived, such a type has the same sort of
+discriminants (known, unknown, or none) as its parent (or ancestor)
+type.  A tagged class-wide type also has unknown discriminants.  [Any
+subtype of a type with unknown discriminants is an unconstrained and
+indefinite subtype (see *note 3.2:: and *note 3.3::).]
+
+26.a/2
+          Discussion: {AI95-00114-01AI95-00114-01} An
+          unknown_discriminant_part "(<>)" is only permitted in the
+          declaration of a (generic or nongeneric) private type, private
+          extension, incomplete type, or formal derived type.  Hence,
+          only such types, descendants thereof, and class-wide types can
+          have unknown discriminants.  An unknown_discriminant_part is
+          used to indicate that the corresponding actual or full type
+          might have discriminants without defaults, or be an
+          unconstrained array subtype.  Tagged class-wide types are also
+          considered to have unknown discriminants because discriminants
+          can be added by type extensions, so the total number of
+          discriminants of any given value of a tagged class-wide type
+          is not known at compile time.
+
+26.b/2
+          {AI95-00287-01AI95-00287-01} A subtype with unknown
+          discriminants is indefinite, and hence an object of such a
+          subtype needs explicit initialization.  A limited private type
+          with unknown discriminants is "extremely" limited; objects of
+          such a type can be initialized only by subprograms (either
+          procedures with a parameter of the type, or a function
+          returning the type) declared in the package.  Subprograms
+          declared elsewhere can operate on and even return the type,
+          but they can only initialize the object by calling
+          (ultimately) a subprogram in the package declaring the type.
+          Such a type is useful for keeping complete control over object
+          creation within the package declaring the type.
+
+26.c
+          A partial view of a type might have unknown discriminants,
+          while the full view of the same type might have known,
+          unknown, or no discriminants.
+
+                          _Dynamic Semantics_
+
+27/2
+{AI95-00230-01AI95-00230-01} {AI95-00416-01AI95-00416-01} For an access
+discriminant, its access_definition is elaborated when the value of the
+access discriminant is defined: by evaluation of its default_expression,
+by elaboration of a discriminant_constraint, or by an assignment that
+initializes the enclosing object.  
+
+27.a/2
+          Ramification: {AI95-00231-01AI95-00231-01}
+          {AI95-00416-01AI95-00416-01} The conversion of the expression
+          defining the access discriminant to the anonymous access type
+          raises Program_Error for an object created by an allocator of
+          an access type T, if the initial value is an access parameter
+          that designates a view whose accessibility level is deeper
+          than that of T.
+
+     NOTES
+
+28
+     55  If a discriminated type has default_expressions for its
+     discriminants, then unconstrained variables of the type are
+     permitted, and the values of the discriminants can be changed by an
+     assignment to such a variable.  If defaults are not provided for
+     the discriminants, then all variables of the type are constrained,
+     either by explicit constraint or by their initial value; the values
+     of the discriminants of such a variable cannot be changed after
+     initialization.
+
+28.a
+          Discussion: This connection between discriminant defaults and
+          unconstrained variables can be a source of confusion.  For Ada
+          95, we considered various ways to break the connection between
+          defaults and unconstrainedness, but ultimately gave up for
+          lack of a sufficiently simple and intuitive alternative.
+
+28.b
+          An unconstrained discriminated subtype with defaults is called
+          a mutable subtype, and a variable of such a subtype is called
+          a mutable variable, because the discriminants of such a
+          variable can change.  There are no mutable arrays (that is,
+          the bounds of an array object can never change), because there
+          is no way in the language to define default values for the
+          bounds.  Similarly, there are no mutable class-wide subtypes,
+          because there is no way to define the default tag, and
+          defaults for discriminants are not allowed in the tagged case.
+          Mutable tags would also require a way for the maximum possible
+          size of such a class-wide subtype to be known.  (In some
+          implementations, all mutable variables are allocated with the
+          maximum possible size.  This approach is appropriate for
+          real-time applications where implicit use of the heap is
+          inappropriate.)
+
+29
+     56  The default_expression for a discriminant of a type is
+     evaluated when an object of an unconstrained subtype of the type is
+     created.
+
+30
+     57  Assignment to a discriminant of an object (after its
+     initialization) is not allowed, since the name of a discriminant is
+     a constant; neither assignment_statements nor assignments inherent
+     in passing as an in out or out parameter are allowed.  Note however
+     that the value of a discriminant can be changed by assigning to the
+     enclosing object, presuming it is an unconstrained variable.
+
+30.a/2
+          Discussion: {AI95-00114-01AI95-00114-01} An
+          unknown_discriminant_part is permitted only in the declaration
+          of a private type (including generic formal private), private
+          extension, incomplete type, or generic formal derived type.
+          These are the things that will have a corresponding completion
+          or generic actual, which will either define the discriminants,
+          or say there are none.  The (<>) indicates that the
+          actual/full subtype might be an indefinite subtype.  An
+          unknown_discriminant_part is not permitted in a normal
+          untagged derived type declaration, because there is no
+          separate full type declaration for such a type.  Note that
+          (<>) allows unconstrained array bounds; those are somewhat
+          like undefaulted discriminants.
+
+30.b
+          For a derived type, either the discriminants are inherited as
+          is, or completely respecified in a new discriminant_part.  In
+          this latter case, each discriminant of the parent type shall
+          be constrained, either to a specific value, or to equal one of
+          the new discriminants.  Constraining a parent type's
+          discriminant to equal one of the new discriminants is like a
+          renaming of the discriminant, except that the subtype of the
+          new discriminant can be more restrictive than that of the
+          parent's one.  In any case, the new discriminant can share
+          storage with the parent's discriminant.
+
+31
+     58  A discriminant that is of a named access type is not called an
+     access discriminant; that term is used only for discriminants
+     defined by an access_definition.
+
+                              _Examples_
+
+32
+Examples of discriminated types:
+
+33
+     type Buffer(Size : Buffer_Size := 100)  is        -- see *note 3.5.4::
+        record
+           Pos   : Buffer_Size := 0;
+           Value : String(1 .. Size);
+        end record;
+
+34
+     type Matrix_Rec(Rows, Columns : Integer) is
+        record
+           Mat : Matrix(1 .. Rows, 1 .. Columns);       -- see *note 3.6::
+        end record;
+
+35
+     type Square(Side : Integer) is new
+        Matrix_Rec(Rows => Side, Columns => Side);
+
+36
+     type Double_Square(Number : Integer) is
+        record
+           Left  : Square(Number);
+           Right : Square(Number);
+        end record;
+
+37/3
+     {AI95-00433-01AI95-00433-01} {AI05-0229-1AI05-0229-1} task type 
Worker(Prio : System.Priority; Buf : access Buffer)
+        with Priority => Prio is -- see *note D.1::
+        -- discriminants used to parameterize the task type (see *note 9.1::)
+        entry Fill;
+        entry Drain;
+     end Worker;
+
+                        _Extensions to Ada 83_
+
+37.a
+          The syntax for a discriminant_specification is modified to
+          allow an access discriminant, with a type specified by an
+          access_definition (see *note 3.10::).
+
+37.b/2
+          {AI95-00251-01AI95-00251-01} Discriminants are allowed on all
+          composite types other than array and interface types.
+
+37.c
+          Discriminants may be of an access type.
+
+                     _Wording Changes from Ada 83_
+
+37.d
+          Discriminant_parts are not elaborated, though an
+          access_definition is elaborated when the discriminant is
+          initialized.
+
+                        _Extensions to Ada 95_
+
+37.e/2
+          {AI95-00230-01AI95-00230-01} {AI95-00402-01AI95-00402-01}
+          {AI95-00416-01AI95-00416-01} Access discriminants (anonymous
+          access types used as a discriminant) can be used on any type
+          allowing discriminants.  Defaults aren't allowed on
+          discriminants of nonlimited types, however, so that
+          accessibility problems don't happen on assignment.
+
+37.f/2
+          {AI95-00231-01AI95-00231-01} null_exclusion can be used in the
+          declaration of a discriminant.
+
+                     _Wording Changes from Ada 95_
+
+37.g/2
+          {8652/00078652/0007} {AI95-00098-01AI95-00098-01} Corrigendum:
+          The wording was clarified so that types that cannot have
+          discriminants cannot have an unknown_discriminant_part.
+
+37.h/2
+          {AI95-00251-01AI95-00251-01} Added wording to prevent
+          interfaces from having discriminants.  We don't want
+          interfaces to have any components.
+
+37.i/2
+          {AI95-00254-01AI95-00254-01} Removed wording which implied or
+          required an access discriminant to have an access-to-object
+          type (anonymous access types can now be access-to-subprogram
+          types as well).
+
+37.j/3
+          {AI95-00326-01AI95-00326-01} {AI05-0299-1AI05-0299-1} Fixed
+          the wording of the introduction to this subclause to reflect
+          that both incomplete and partial views can have unknown
+          discriminants.  That was always true, but for some reason this
+          wording specified partial views.
+
+37.k/2
+          {AI95-00419-01AI95-00419-01} Changed the wording to use the
+          new term "explicitly limited record", which makes the intent
+          much clearer (and eliminates confusion with derived types that
+          happen to contain the reserved word limited).
+
+                   _Incompatibilities With Ada 2005_
+
+37.l/3
+          {AI05-0063-1AI05-0063-1} Correction: Changed the rules for
+          when access discriminants can have defaults to depend on the
+          new definition for immutably limited types; this will help
+          ensure that unusual corner cases are properly handled.  Note
+          that the Ada 2005 rule was unintentionally incompatible with
+          the Ada 95 rule (as enforced by the ACATS); this change brings
+          it back into alignment with actual practice.  So there should
+          be no practical incompatibility.
+
+                       _Extensions to Ada 2005_
+
+37.m/3
+          {AI05-0214-1AI05-0214-1} A limited tagged type may now have
+          defaults for its discriminants.
+
+                    _Wording Changes from Ada 2005_
+
+37.n/3
+          {AI05-0102-1AI05-0102-1} Correction: Moved implicit conversion
+          Legality Rule to *note 8.6::.
+
+* Menu:
+
+* 3.7.1 ::    Discriminant Constraints
+* 3.7.2 ::    Operations of Discriminated Types
+
+
+File: aarm2012.info,  Node: 3.7.1,  Next: 3.7.2,  Up: 3.7
+
+3.7.1 Discriminant Constraints
+------------------------------
+
+1
+A discriminant_constraint specifies the values of the discriminants for
+a given discriminated type.
+
+                     _Language Design Principles_
+
+1.a/3
+          {AI05-0299-1AI05-0299-1} The rules in this subclause are
+          intentionally parallel to those given in *note 4.3.1::, "*note
+          4.3.1:: Record Aggregates".
+
+                               _Syntax_
+
+2
+     discriminant_constraint ::=
+        (discriminant_association {, discriminant_association})
+
+3
+     discriminant_association ::=
+        [discriminant_selector_name {| discriminant_selector_name} =>] 
+     expression
+
+4
+     A discriminant_association is said to be named if it has one or
+     more discriminant_selector_names; it is otherwise said to be
+     positional.  In a discriminant_constraint, any positional
+     associations shall precede any named associations.
+
+                        _Name Resolution Rules_
+
+5
+Each selector_name of a named discriminant_association (*note 3.7.1:
+S0065.) shall resolve to denote a discriminant of the subtype being
+constrained; the discriminants so named are the associated discriminants
+of the named association.  For a positional association, the associated
+discriminant is the one whose discriminant_specification (*note 3.7:
+S0062.) occurred in the corresponding position in the
+known_discriminant_part (*note 3.7: S0061.) that defined the
+discriminants of the subtype being constrained.
+
+6
+The expected type for the expression in a discriminant_association is
+that of the associated discriminant(s).
+
+                           _Legality Rules_
+
+7/3
+{8652/00088652/0008} {AI95-00168-01AI95-00168-01}
+{AI95-00363-01AI95-00363-01} {AI05-0041-1AI05-0041-1} A
+discriminant_constraint is only allowed in a subtype_indication whose
+subtype_mark denotes either an unconstrained discriminated subtype, or
+an unconstrained access subtype whose designated subtype is an
+unconstrained discriminated subtype.  However, in the case of an access
+subtype, a discriminant_constraint (*note 3.7.1: S0064.) is legal only
+if any dereference of a value of the access type is known to be
+constrained (see *note 3.3::).  In addition to the places where Legality
+Rules normally apply (see *note 12.3::), these rules apply also in the
+private part of an instance of a generic unit.
+
+7.a.1/2
+          This paragraph was deleted.{8652/00088652/0008}
+          {AI95-00168-01AI95-00168-01} {AI95-00363-01AI95-00363-01}
+
+7.a/2
+          Reason: {AI95-00363-01AI95-00363-01} The second rule is
+          necessary to prevent objects from changing so that they no
+          longer match their constraint.  In Ada 95, we attempted to
+          prevent this by banning every case where an aliased object
+          could be unconstrained or be changed by an enclosing
+          assignment.  New ways to cause this problem were being
+          discovered frequently, meaning that new rules had to be
+          dreamed up to cover them.  Meanwhile, aliased objects and
+          components were getting more and more limited.  In Ada 2005,
+          we sweep away all of that cruft and replace it by a simple
+          rule "thou shalt not create an access subtype that can point
+          to an item whose discriminants can be changed by assignment".
+
+7.b/3
+          Discussion: {AI05-0041-1AI05-0041-1} The second rule will only
+          use the indefinite or dereference bullets in the definition of
+          "known to be constrained".  The rule is worded in terms of
+          "known to be constrained" in order to capture the special
+          rules that apply in generic bodies (rather than repeating them
+          and getting them subtly wrong).
+
+8
+A named discriminant_association with more than one selector_name is
+allowed only if the named discriminants are all of the same type.  A
+discriminant_constraint shall provide exactly one value for each
+discriminant of the subtype being constrained.
+
+9/3
+This paragraph was deleted.{AI05-0102-1AI05-0102-1}
+
+9.a/3
+          Ramification: In addition, *note 8.6:: requires that the
+          expression associated with an access discriminant is
+          convertible (see *note 4.6::) to the anonymous access type.
+          This implies both convertibility of designated types, and
+          static accessibility.  This implies that if an object of type
+          T with an access discriminant is created by an allocator for
+          an access type A, then it requires that the type of the
+          expression associated with the access discriminant have an
+          accessibility level that is not statically deeper than that of
+          A. This is to avoid dangling references.
+
+                          _Dynamic Semantics_
+
+10
+A discriminant_constraint is compatible with an unconstrained
+discriminated subtype if each discriminant value belongs to the subtype
+of the corresponding discriminant.
+
+10.a
+          Ramification: The "dependent compatibility check" has been
+          eliminated in Ada 95.  Any checking on subcomponents is
+          performed when (and if) an object is created.
+
+10.b
+          Discussion: There is no need to define compatibility with a
+          constrained discriminated subtype, because one is not allowed
+          to constrain it again.
+
+11
+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.
+
+12
+For the elaboration of a discriminant_constraint, the expressions in the
+discriminant_associations are evaluated in an arbitrary order and
+converted to the type of the associated discriminant (which might raise
+Constraint_Error -- see *note 4.6::); the expression of a named
+association is evaluated (and converted) once for each associated
+discriminant.  The result of each evaluation and conversion is the value
+imposed by the constraint for the associated discriminant.
+
+12.a
+          Reason: We convert to the type, not the subtype, so that the
+          definition of compatibility of discriminant constraints is not
+          vacuous.
+
+     NOTES
+
+13
+     59  The rules of the language ensure that a discriminant of an
+     object always has a value, either from explicit or implicit
+     initialization.
+
+13.a
+          Discussion: Although it is illegal to constrain a class-wide
+          tagged subtype, it is possible to have a partially constrained
+          class-wide subtype: If the subtype S is defined by T(A => B),
+          then S'Class is partially constrained in the sense that
+          objects of subtype S'Class have to have discriminants
+          corresponding to A equal to B, but there can be other
+          discriminants defined in extensions that are not constrained
+          to any particular value.
+
+                              _Examples_
+
+14/3
+{AI05-0299-1AI05-0299-1} Examples (using types declared above in
+subclause *note 3.7::):
+
+15
+     Large   : Buffer(200);  --  constrained, always 200 characters
+                             --   (explicit discriminant value)
+     Message : Buffer;       --  unconstrained, initially 100 characters
+                             --   (default discriminant value)
+     Basis   : Square(5);    --  constrained, always 5 by 5
+     Illegal : Square;       --  illegal, a Square has to be constrained
+
+                     _Inconsistencies With Ada 83_
+
+15.a
+          Dependent compatibility checks are no longer performed on
+          subtype declaration.  Instead they are deferred until object
+          creation (see *note 3.3.1::).  This is upward compatible for a
+          program that does not raise Constraint_Error.
+
+                     _Wording Changes from Ada 83_
+
+15.b
+          Everything in RM83-3.7.2(7-12), which specifies the initial
+          values for discriminants, is now redundant with 3.3.1, 6.4.1,
+          8.5.1, and 12.4.  Therefore, we don't repeat it here.  Since
+          the material is largely intuitive, but nevertheless
+          complicated to state formally, it doesn't seem worth putting
+          it in a "NOTE."
+
+                    _Incompatibilities With Ada 95_
+
+15.c/2
+          {8652/00088652/0008} {AI95-00168-01AI95-00168-01}
+          {AI95-00363-01AI95-00363-01} The Corrigendum added a
+          restriction on discriminant_constraints for general access
+          subtypes.  Such constraints are prohibited if the designated
+          type can be treated as constrained somewhere in the program.
+          Ada 2005 goes further and prohibits such
+          discriminant_constraints if the designated type has (or might
+          have, in the case of a formal type) defaults for its
+          discriminants.  The use of general access subtypes is rare,
+          and this eliminates a boatload of problems that required many
+          restrictions on the use of aliased objects and components (now
+          lifted).  Similarly, Ada 2005 prohibits
+          discriminant_constraints on any access type whose designated
+          type has a partial view that is constrained.  Such a type will
+          not be constrained in the heap to avoid privacy problems.
+          Again, the use of such subtypes is rare (they can only happen
+          within the package and its child units).
+
+                    _Wording Changes from Ada 2005_
+
+15.d/3
+          {AI05-0041-1AI05-0041-1} Correction: Revised the rules on
+          access subtypes having discriminant constraints to depend on
+          the "known to be constrained" rules.  This centralizes the
+          rules so that future fixes need to be made in only one place,
+          as well as fixing bugs in obscure cases.
+
+15.e/3
+          {AI05-0102-1AI05-0102-1} Correction: Moved implicit conversion
+          Legality Rule to *note 8.6::.
+
+
+File: aarm2012.info,  Node: 3.7.2,  Prev: 3.7.1,  Up: 3.7
+
+3.7.2 Operations of Discriminated Types
+---------------------------------------
+
+1
+[If a discriminated type has default_expressions for its discriminants,
+then unconstrained variables of the type are permitted, and the
+discriminants of such a variable can be changed by assignment to the
+variable.  For a formal parameter of such a type, an attribute is
+provided to determine whether the corresponding actual parameter is
+constrained or unconstrained.]
+
+                          _Static Semantics_
+
+2
+For a prefix A that is of a discriminated type [(after any implicit
+dereference)], the following attribute is defined:
+
+3/3
+A'Constrained
+               {AI05-0214-1AI05-0214-1} Yields the value True if A
+               denotes a constant, a value, a tagged object, or a
+               constrained variable, and False otherwise.
+
+3.a/3
+          Implementation Note: {AI05-0214-1AI05-0214-1} This attribute
+          is primarily used on parameters, to determine whether the
+          discriminants can be changed as part of an assignment.  The
+          Constrained attribute is statically True for in parameters.
+          For in out and out parameters of a discriminated type, the
+          value of this attribute needs to be passed as an implicit
+          parameter, in general.  However, if the type is tagged or does
+          not have defaults for its discriminants, the attribute is
+          statically True, so no implicit parameter is needed.
+          Parameters of a limited untagged type with defaulted
+          discriminants need this implicit parameter, unless there are
+          no nonlimited views, because they might be passed to a
+          subprogram whose body has visibility on a nonlimited view of
+          the type, and hence might be able to assign to the object and
+          change its discriminants.
+
+3.b/3
+          Reason: {AI05-0214-1AI05-0214-1} All tagged objects are known
+          to be constrained (as nonlimited tagged types cannot have
+          discriminant defaults, and limited tagged objects are
+          immutably limited), and are always considered constrained by
+          this attribute to avoid distributed overhead for parameters of
+          limited classwide types, as limited tagged objects may
+          technically be unconstrained if they use defaulted
+          discriminants.  Such objects still cannot have their
+          discriminants changed, as assignment is not supported for
+          them, so there is no use for this attribute that would justify
+          the overhead of passing it with all classwide parameters.
+
+3.c/3
+          Discussion: {AI05-0005-1AI05-0005-1} {AI05-0214-1AI05-0214-1}
+          If the type of A is a type derived from an untagged partial
+          view of a tagged type such that it is not a tagged type, then
+          A is not considered a tagged object, and A'Constrained can
+          return either True or False depending on the nature of the
+          object.
+
+                         _Erroneous Execution_
+
+4
+The execution of a construct is erroneous if the construct has a
+constituent that is a name denoting a subcomponent that depends on
+discriminants, and the value of any of these discriminants is changed by
+this execution between evaluating the name and the last use (within this
+execution) of the subcomponent denoted by the name.
+
+4.a
+          Ramification: This rule applies to assignment_statements,
+          calls (except when the discriminant-dependent subcomponent is
+          an in parameter passed by copy), indexed_components, and
+          slices.  Ada 83 only covered the first two cases.  AI83-00585
+          pointed out the situation with the last two cases.  The cases
+          of object_renaming_declarations and generic formal in out
+          objects are handled differently, by disallowing the situation
+          at compile time.
+
+                        _Extensions to Ada 83_
+
+4.b/1
+          For consistency with other attributes, we are allowing the
+          prefix of Constrained to be a value as well as an object of a
+          discriminated type, and also an implicit dereference.  These
+          extensions are not important capabilities, but there seems no
+          reason to make this attribute different from other similar
+          attributes.  We are curious what most Ada 83 compilers do with
+          F(1).X'Constrained.
+
+4.c
+          We now handle in a general way the cases of erroneousness
+          identified by AI83-00585, where the prefix of an
+          indexed_component or slice is discriminant-dependent, and the
+          evaluation of the index or discrete range changes the value of
+          a discriminant.
+
+                     _Wording Changes from Ada 83_
+
+4.d
+          We have moved all discussion of erroneous use of names that
+          denote discriminant-dependent subcomponents to this subclause.
+          In Ada 83, it used to appear separately under
+          assignment_statements and subprogram calls.
+
+                    _Wording Changes from Ada 2005_
+
+4.e/3
+          {AI05-0214-1AI05-0214-1} A'Constrained is now defined to
+          return True for any A that is a tagged object.  This doesn't
+          change the result for any A allowed by previous versions of
+          Ada; the change is necessary to avoid unnecessary overhead for
+          limited tagged parameters.
+
+
+File: aarm2012.info,  Node: 3.8,  Next: 3.9,  Prev: 3.7,  Up: 3
+
+3.8 Record Types
+================
+
+1
+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 the components.  
+
+                               _Syntax_
+
+2
+     record_type_definition ::= [[abstract] tagged] [limited] 
+     record_definition
+
+3
+     record_definition ::=
+         record
+            component_list
+         end record
+       | null record
+
+4
+     component_list ::=
+           component_item {component_item}
+        | {component_item} variant_part
+        |  null;
+
+5/1
+     {8652/00098652/0009} {AI95-00137-01AI95-00137-01} component_item
+     ::= component_declaration | aspect_clause
+
+6/3
+     {AI05-0183-1AI05-0183-1} component_declaration ::=
+        defining_identifier_list : component_definition [:= 
+     default_expression]
+             [aspect_specification];
+
+                        _Name Resolution Rules_
+
+7
+The expected type for the default_expression, if any, in a
+component_declaration is the type of the component.
+
+                           _Legality Rules_
+
+8/2
+This paragraph was deleted.{AI95-00287-01AI95-00287-01}
+
+9/2
+{AI95-00366-01AI95-00366-01} 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 shall
+be distinct.]
+
+9.a/3
+          Proof: {AI05-0299-1AI05-0299-1} The identifiers of all
+          components of a record type have to be distinct because they
+          are all declared immediately within the same declarative
+          region.  See Clause *note 8::.
+
+10
+Within a type_declaration, a name that denotes a component, protected
+subprogram, or entry of the type is allowed only in the following cases:
+
+11/3
+   * {AI05-0004-1AI05-0004-1} {AI05-0295-1AI05-0295-1} A name that
+     denotes any component, protected subprogram, or entry is allowed
+     within an aspect_specification, an operational item, or a
+     representation item that occurs within the declaration of the
+     composite type.
+
+12/3
+   * {AI05-0264-1AI05-0264-1} A name that denotes a noninherited
+     discriminant is allowed within the declaration of the type, but not
+     within the discriminant_part.  If the discriminant is used to
+     define the constraint of a component, the bounds of an entry
+     family, or the constraint of the parent subtype in a
+     derived_type_definition, then its name shall appear alone as a
+     direct_name (not as part of a larger expression or expanded name).
+     A discriminant shall not be used to define the constraint of a
+     scalar component.
+
+12.a
+          Reason: The penultimate restriction simplifies implementation,
+          and allows the outer discriminant and the inner discriminant
+          or bound to possibly share storage.
+
+12.b
+          Ramification: Other rules prevent such a discriminant from
+          being an inherited one.
+
+12.c
+          Reason: The last restriction is inherited from Ada 83.  The
+          restriction is not really necessary from a language design
+          point of view, but we did not remove it, in order to avoid
+          unnecessary changes to existing compilers.
+
+12.d
+          Discussion: Note that a discriminant can be used to define the
+          constraint for a component that is of an access-to-composite
+          type.
+
+12.e/2
+          Reason: {AI95-00373-01AI95-00373-01} The above rules, and a
+          similar one in *note 6.1:: for formal parameters, are intended
+          to allow initializations of components or parameters to occur
+          in a (nearly) arbitrary order -- whatever order is most
+          efficient (subject to the restrictions of *note 3.3.1::),
+          since one default_expression cannot depend on the value of
+          another one.  They also prevent circularities.
+
+12.f/3
+          Ramification: {AI05-0295-1AI05-0295-1} Inherited discriminants
+          are not allowed to be denoted, except within
+          aspect_specifications and representation items.  However, the
+          discriminant_selector_name of the parent subtype_indication is
+          allowed to denote a discriminant of the parent.
+
+13
+If the name of the current instance of a type (see *note 8.6::) is used
+to define the constraint of a component, then it shall appear as a
+direct_name that is the prefix of an attribute_reference whose result is
+of an access type, and the attribute_reference shall appear alone.
+
+13.a
+          Reason: This rule allows T'Access or T'Unchecked_Access, but
+          disallows, for example, a range constraint (1..T'Size).
+          Allowing things like (1..T'Size) would mean that a per-object
+          constraint could affect the size of the object, which would be
+          bad.
+
+                          _Static Semantics_
+
+13.1/3
+{AI95-00318-02AI95-00318-02} {AI05-0004-1AI05-0004-1} If a
+record_type_definition includes the reserved word limited, the type is
+called an explicitly limited record type.
+
+14
+The component_definition of a component_declaration defines the
+(nominal) subtype of the component.  If the reserved word aliased
+appears in the component_definition, then the component is aliased (see
+*note 3.10::).
+
+15
+If the component_list of a record type is defined by the reserved word
+null and there are no discriminants, then the record type has no
+components and all records of the type are null records.  A
+record_definition of null record is equivalent to record null; end
+record.
+
+15.a
+          Ramification: This short-hand is available both for declaring
+          a record type and a record extension -- see *note 3.9.1::.
+
+                          _Dynamic Semantics_
+
+16
+The elaboration of a record_type_definition creates the record type and
+its first subtype, and consists of the elaboration of the
+record_definition.  The elaboration of a record_definition consists of
+the elaboration of its component_list, if any.
+
+17
+The elaboration of a component_list consists of the elaboration of the
+component_items and variant_part, if any, in the order in which they
+appear.  The elaboration of a component_declaration consists of the
+elaboration of the component_definition.
+
+17.a
+          Discussion: If the defining_identifier_list has more than one
+          defining_identifier, we presume here that the transformation
+          explained in *note 3.3.1:: has already taken place.
+          Alternatively, we could say that the component_definition is
+          elaborated once for each defining_identifier in the list.
+
+18/2
+{8652/00028652/0002} {AI95-00171-01AI95-00171-01}
+{AI95-00230-01AI95-00230-01} Within the definition of a composite type,
+if a component_definition or discrete_subtype_definition (see *note
+9.5.2::) includes a name that denotes a discriminant of the type, or
+that is an attribute_reference whose prefix denotes the current instance
+of the type, the expression containing the name is called a per-object
+expression, and the constraint or range being defined is called a
+per-object constraint.  For the elaboration of a component_definition of
+a component_declaration or the discrete_subtype_definition (*note 3.6:
+S0055.) of an entry_declaration (*note 9.5.2: S0218.) for an entry
+family (see *note 9.5.2::), if the component subtype is defined by an
+access_definition or if the constraint or range of the
+subtype_indication or discrete_subtype_definition (*note 3.6: S0055.) is
+not a per-object constraint, then the access_definition,
+subtype_indication, or discrete_subtype_definition (*note 3.6: S0055.)
+is elaborated.  On the other hand, if the constraint or range is a
+per-object constraint, then the elaboration consists of the evaluation
+of any included expression that is not part of a per-object expression.
+Each such expression is evaluated once unless it is part of a named
+association in a discriminant constraint, in which case it is evaluated
+once for each associated discriminant.
+
+18.1/1
+{8652/00028652/0002} {AI95-00171-01AI95-00171-01} When a per-object
+constraint is elaborated [(as part of creating an object)], each
+per-object expression of the constraint is evaluated.  For other
+expressions, the values determined during the elaboration of the
+component_definition (*note 3.6: S0056.) or entry_declaration (*note
+9.5.2: S0218.) are used.  Any checks associated with the enclosing
+subtype_indication or discrete_subtype_definition are performed[,
+including the subtype compatibility check (see *note 3.2.2::),] and the
+associated subtype is created.
+
+18.a
+          Discussion: The evaluation of other expressions that appear in
+          component_definitions and discrete_subtype_definitions is
+          performed when the type definition is elaborated.  The
+          evaluation of expressions that appear as default_expressions
+          is postponed until an object is created.  Expressions in
+          representation items that appear within a composite type
+          definition are evaluated according to the rules of the
+          particular representation item.
+
+     NOTES
+
+19
+     60  A component_declaration with several identifiers is equivalent
+     to a sequence of single component_declarations, as explained in
+     *note 3.3.1::.
+
+20
+     61  The default_expression of a record component is only evaluated
+     upon the creation of a default-initialized object of the record
+     type (presuming the object has the component, if it is in a
+     variant_part -- see *note 3.3.1::).
+
+21
+     62  The subtype defined by a component_definition (see *note 3.6::)
+     has to be a definite subtype.
+
+22
+     63  If a record type does not have a variant_part, then the same
+     components are present in all values of the type.
+
+23
+     64  A record type is limited if it has the reserved word limited in
+     its definition, or if any of its components are limited (see *note
+     7.5::).
+
+24
+     65  The predefined operations of a record type include membership
+     tests, qualification, and explicit conversion.  If the record type
+     is nonlimited, they also include assignment and the predefined
+     equality operators.
+
+25/2
+     66  {AI95-00287-01AI95-00287-01} A component of a record can be
+     named with a selected_component.  A value of a record can be
+     specified with a record_aggregate.
+
+                              _Examples_
+
+26
+Examples of record type declarations:
+
+27
+     type Date is
+        record
+           Day   : Integer range 1 .. 31;
+           Month : Month_Name;
+           Year  : Integer range 0 .. 4000;
+        end record;
+
+28
+     type Complex is
+        record
+           Re : Real := 0.0;
+           Im : Real := 0.0;
+        end record;
+
+29
+Examples of record variables:
+
+30
+     Tomorrow, Yesterday : Date;
+     A, B, C : Complex;
+
+31
+     -- both components of A, B, and C are implicitly initialized to zero 
+
+                        _Extensions to Ada 83_
+
+31.a
+          The syntax rule for component_declaration is modified to use
+          component_definition (instead of
+          component_subtype_definition).  The effect of this change is
+          to allow the reserved word aliased before the
+          component_subtype_definition.
+
+31.b
+          A short-hand is provided for defining a null record type (and
+          a null record extension), as these will be more common for
+          abstract root types (and derived types without additional
+          components).
+
+31.c
+          The syntax rule for record_type_definition is modified to
+          allow the reserved words tagged and limited.  Tagging is new.
+          Limitedness is now orthogonal to privateness.  In Ada 83 the
+          syntax implied that limited private was sort of more private
+          than private.  However, limitedness really has nothing to do
+          with privateness; limitedness simply indicates the lack of
+          assignment capabilities, and makes perfect sense for
+          nonprivate types such as record types.
+
+                     _Wording Changes from Ada 83_
+
+31.d/1
+          {8652/00098652/0009} {AI95-00137-01AI95-00137-01} The syntax
+          rules now allow aspect_clauses to appear in a
+          record_definition.  This is not a language extension, because
+          Legality Rules prevent all language-defined representation
+          clauses from appearing there.  However, an
+          implementation-defined attribute_definition_clause could
+          appear there.  The reason for this change is to allow the
+          rules for aspect_clauses and representation pragmas to be as
+          similar as possible.
+
+                        _Extensions to Ada 95_
+
+31.e/2
+          {AI95-00287-01AI95-00287-01} Record components can have an
+          anonymous access type.
+
+31.f/2
+          {AI95-00287-01AI95-00287-01} Limited components can be
+          initialized, so long as the expression is one that allows
+          building the object in place (such as an aggregate or
+          function_call).
+
+                     _Wording Changes from Ada 95_
+
+31.g/2
+          {8652/00028652/0002} {AI95-00171-01AI95-00171-01} Corrigendum:
+          Improved the description of the elaboration of per-object
+          constraints.
+
+31.h/2
+          {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+          Changed representation clauses to aspect clauses to reflect
+          that they are used for more than just representation.
+
+31.i/2
+          {AI95-00318-02AI95-00318-02} Defined explicitly limited record
+          type to use in other rules.
+
+                       _Extensions to Ada 2005_
+
+31.j/3
+          {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+          be used in a component_declaration.  This is described in
+          *note 13.1.1::.
+
+* Menu:
+
+* 3.8.1 ::    Variant Parts and Discrete Choices
+
+
+File: aarm2012.info,  Node: 3.8.1,  Up: 3.8
+
+3.8.1 Variant Parts and Discrete Choices
+----------------------------------------
+
+1
+A record type with a variant_part specifies alternative lists of
+components.  Each variant defines the components for the value or values
+of the discriminant covered by its discrete_choice_list.
+
+1.a
+          Discussion: Discrete_choice_lists and discrete_choices are
+          said to cover values as defined below; which
+          discrete_choice_list covers a value determines which of
+          various alternatives is chosen.  These are used in
+          variant_parts, array_aggregates, and case_statements.
+
+                     _Language Design Principles_
+
+1.b
+          The definition of "cover" in this subclause and the rules
+          about discrete choices are designed so that they are also
+          appropriate for array aggregates and case statements.
+
+1.c
+          The rules of this subclause intentionally parallel those for
+          case statements.
+
+                               _Syntax_
+
+2
+     variant_part ::=
+        case discriminant_direct_name is
+            variant
+           {variant}
+        end case;
+
+3
+     variant ::=
+        when discrete_choice_list =>
+           component_list
+
+4
+     discrete_choice_list ::= discrete_choice {| discrete_choice}
+
+5/3
+     {AI05-0153-3AI05-0153-3} {AI05-0158-1AI05-0158-1} discrete_choice
+     ::= choice_expression | discrete_subtype_indication | 
+     range | others
+
+                        _Name Resolution Rules_
+
+6
+The discriminant_direct_name shall resolve to denote a discriminant
+(called the discriminant of the variant_part) specified in the
+known_discriminant_part of the full_type_declaration that contains the
+variant_part.  The expected type for each discrete_choice in a variant
+is the type of the discriminant of the variant_part.
+
+6.a
+          Ramification: A full_type_declaration with a variant_part has
+          to have a (new) known_discriminant_part; the discriminant of
+          the variant_part cannot be an inherited discriminant.
+
+                           _Legality Rules_
+
+7
+The discriminant of the variant_part shall be of a discrete type.
+
+7.a
+          Ramification: It shall not be of an access type, named or
+          anonymous.
+
+8/3
+{AI05-0153-3AI05-0153-3} The choice_expressions, subtype_indications,
+and ranges given as discrete_choices in a variant_part shall be static.
+The discrete_choice others shall appear alone in a discrete_choice_list,
+and such a discrete_choice_list, if it appears, shall be the last one in
+the enclosing construct.
+
+9
+A discrete_choice is defined to cover a value in the following cases:
+
+10/3
+   * {AI05-0262-1AI05-0262-1} A discrete_choice that is a
+     choice_expression covers a value if the value equals the value of
+     the choice_expression converted to the expected type.
+
+10.1/3
+   * {AI05-0153-3AI05-0153-3} {AI05-0262-1AI05-0262-1} A discrete_choice
+     that is a subtype_indication covers all values (possibly none) that
+     belong to the subtype and that satisfy the static predicate of the
+     subtype (see *note 3.2.4::).
+
+10.a/3
+          Ramification: {AI05-0262-1AI05-0262-1} A dynamic predicate is
+          never allowed in this case (for variants, case_statements, and
+          case_expressions, a subtype with a dynamic predicate isn't
+          static and thus isn't allowed in a discrete_choice, and for a
+          choice in an array_aggregate, a dynamic predicate is
+          explicitly disallowed -- see *note 3.2.4::).
+
+11/3
+   * {AI05-0153-3AI05-0153-3} A discrete_choice that is a range covers
+     all values (possibly none) that belong to the range.
+
+12
+   * The discrete_choice others covers all values of its expected type
+     that are not covered by previous discrete_choice_lists of the same
+     construct.
+
+12.a
+          Ramification: For case_statements, this includes values
+          outside the range of the static subtype (if any) to be covered
+          by the choices.  It even includes values outside the base
+          range of the case expression's type, since values of numeric
+          types (and undefined values of any scalar type?)  can be
+          outside their base range.
+
+13
+A discrete_choice_list covers a value if one of its discrete_choices
+covers the value.
+
+14
+The possible values of the discriminant of a variant_part shall be
+covered as follows:
+
+15/3
+   * {AI05-0153-3AI05-0153-3} {AI05-0188-1AI05-0188-1}
+     {AI05-0262-1AI05-0262-1} If the discriminant is of a static
+     constrained scalar subtype then, except within an instance of a
+     generic unit, each non-others discrete_choice (*note 3.8.1: S0074.)
+     shall cover only values in that subtype that satisfy its predicate,
+     and each value of that subtype that satisfies its predicate shall
+     be covered by some discrete_choice (*note 3.8.1: S0074.) [(either
+     explicitly or by others)];
+
+15.a/3
+          Reason: {AI05-0188-1AI05-0188-1} The exemption for a
+          discriminated type declared in an instance allows the
+          following example:
+
+15.b/3
+               generic
+                  type T is new Integer;
+               package G is
+                  type Rec (Discrim : T) is record
+                     case Discrim is
+                        when -10 .. -1 =>
+                           Foo : Float;
+                        when others =>
+                           null;
+                     end case;
+                  end record;
+               end G;
+
+15.c/3
+               package I is new G (Natural); -- Legal
+
+16/3
+   * {AI05-0264-1AI05-0264-1} If the type of the discriminant is a
+     descendant of a generic formal scalar type, then the variant_part
+     shall have an others discrete_choice;
+
+16.a
+          Reason: The base range is not known statically in this case.
+
+17
+   * Otherwise, each value of the base range of the type of the
+     discriminant shall be covered [(either explicitly or by others)].
+
+18
+Two distinct discrete_choices of a variant_part shall not cover the same
+value.
+
+                          _Static Semantics_
+
+19
+If the component_list of a variant is specified by null, the variant has
+no components.
+
+20
+The discriminant of a variant_part is said to govern the variant_part
+and its variants.  In addition, the discriminant of a derived type
+governs a variant_part and its variants if it corresponds (see *note
+3.7::) to the discriminant of the variant_part.
+
+                          _Dynamic Semantics_
+
+21
+A record value contains the values of the components of a particular
+variant only if the value of the discriminant governing the variant is
+covered by the discrete_choice_list of the variant.  This rule applies
+in turn to any further variant that is, itself, included in the
+component_list of the given variant.
+
+21.1/3
+{AI05-0290-1AI05-0290-1} When an object of a discriminated type T is
+initialized by default, Constraint_Error is raised if no
+discrete_choice_list of any variant of a variant_part of T covers the
+value of the discriminant that governs the variant_part.  When a
+variant_part appears in the component_list of another variant V, this
+test is only applied if the value of the discriminant governing V is
+covered by the discrete_choice_list of V.
+
+21.a/3
+          Implementation Note: This is not a "check"; it cannot be
+          suppressed.  However, in most cases it is not necessary to
+          generate any code to raise this exception.  A test is needed
+          (and can fail) in the case where the discriminant subtype has
+          a Static_Predicate specified, it also has predicate checking
+          disabled, and the discriminant governs a variant_part which
+          lacks a when others choice.
+
+21.b/3
+          The test also could fail for a static discriminant subtype
+          with range checking suppressed and the discriminant governs a
+          variant_part which lacks a when others choice.  But execution
+          is erroneous if a range check that would have failed is
+          suppressed (see *note 11.5::), so an implementation does not
+          have to generate code to check this case.  (An unchecked
+          failed predicate does not cause erroneous execution, so the
+          test is required in that case.)
+
+21.c/3
+          Like the checks associated with a per-object constraint, this
+          test is not made during the elaboration of a
+          subtype_indication.
+
+22
+The elaboration of a variant_part consists of the elaboration of the
+component_list of each variant in the order in which they appear.
+
+                              _Examples_
+
+23
+Example of record type with a variant part:
+
+24
+     type Device is (Printer, Disk, Drum);
+     type State  is (Open, Closed);
+
+25
+     type Peripheral(Unit : Device := Disk) is
+        record
+           Status : State;
+           case Unit is
+              when Printer =>
+                 Line_Count : Integer range 1 .. Page_Size;
+              when others =>
+                 Cylinder   : Cylinder_Index;
+                 Track      : Track_Number;
+              end case;
+           end record;
+
+26
+Examples of record subtypes:
+
+27
+     subtype Drum_Unit is Peripheral(Drum);
+     subtype Disk_Unit is Peripheral(Disk);
+
+28
+Examples of constrained record variables:
+
+29
+     Writer   : Peripheral(Unit  => Printer);
+     Archive  : Disk_Unit;
+
+                        _Extensions to Ada 83_
+
+29.a
+          In Ada 83, the discriminant of a variant_part is not allowed
+          to be of a generic formal type.  This restriction is removed
+          in Ada 95; an others discrete_choice is required in this case.
+
+                     _Wording Changes from Ada 83_
+
+29.b
+          The syntactic category choice is removed.  The syntax rules
+          for variant, array_aggregate, and case_statement now use
+          discrete_choice_list or discrete_choice instead.  The syntax
+          rule for record_aggregate now defines its own syntax for named
+          associations.
+
+29.c/3
+          {AI05-0299-1AI05-0299-1} We have added the term Discrete
+          Choice to the title since this is where they are talked about.
+          This is analogous to the name of the subclause "Index
+          Constraints and Discrete Ranges" in the subclause on Array
+          Types.
+
+29.d
+          The rule requiring that the discriminant denote a discriminant
+          of the type being defined seems to have been left implicit in
+          RM83.
+
+                   _Incompatibilities With Ada 2005_
+
+29.e/3
+          {AI05-0158-1AI05-0158-1} Membership tests are no longer
+          allowed as a discrete_choice, in order that those tests can be
+          expanded to allow multiple tests in a single expression
+          without ambiguity.  Since a membership test has a boolean
+          type, they are very unlikely to be used as a discrete_choice.
+
+                       _Extensions to Ada 2005_
+
+29.f/3
+          {AI05-0153-3AI05-0153-3} Subtypes with static predicates can
+          be used in discrete_choices, and the coverage rules are
+          modified to respect the predicates.
+
+29.g/3
+          {AI05-0188-1AI05-0188-1} Variants in generic specifications
+          are no longer rejected if the subtype of the actual type does
+          not include all of the case choices.  This probably isn't
+          useful, but it is consistent with the treatment of
+          case_expressions.
+
+                    _Wording Changes from Ada 2005_
+
+29.h/3
+          {AI05-0290-1AI05-0290-1} Added a test that some variant covers
+          the value of a discriminant that governs a variant_part.  This
+          is similar to the test that some case limb covers the value of
+          the Selecting_expression of a case_statement.  This test
+          cannot change the behavior of any nonerroneous Ada 2005
+          program, so it is not an inconsistency.
+
+
+File: aarm2012.info,  Node: 3.9,  Next: 3.10,  Prev: 3.8,  Up: 3
+
+3.9 Tagged Types and Type Extensions
+====================================
+
+1
+[ Tagged types and type extensions support object-oriented programming,
+based on inheritance with extension and run-time polymorphism via
+dispatching operations.  ]
+
+                     _Language Design Principles_
+
+1.a/2
+          {AI95-00251-01AI95-00251-01} The intended implementation model
+          is for the static portion of a tag to be represented as a
+          pointer to a statically allocated and link-time initialized
+          type descriptor.  The type descriptor contains the address of
+          the code for each primitive operation of the type.  It
+          probably also contains other information, such as might make
+          membership tests convenient and efficient.  Tags for nested
+          type extensions must also have a dynamic part that identifies
+          the particular elaboration of the type.
+
+1.b
+          The primitive operations of a tagged type are known at its
+          first freezing point; the type descriptor is laid out at that
+          point.  It contains linker symbols for each primitive
+          operation; the linker fills in the actual addresses.
+
+1.b.1/2
+          {AI95-00251-01AI95-00251-01} Primitive operations of type
+          extensions that are declared at a level deeper than the level
+          of the ultimate ancestor from which they are derived can be
+          represented by wrappers that use the dynamic part of the tag
+          to call the actual primitive operation.  The dynamic part
+          would generally be some way to represent the static link or
+          display necessary for making a nested call.  One
+          implementation strategy would be to store that information in
+          the extension part of such nested type extensions, and use the
+          dynamic part of the tag to point at it.  (That way, the
+          "dynamic" part of the tag could be static, at the cost of
+          indirect access.)
+
+1.b.2/2
+          {AI95-00251-01AI95-00251-01} If the tagged type is descended
+          from any interface types, it also will need to include
+          "subtags" (one for each interface) that describe the mapping
+          of the primitive operations of the interface to the primitives
+          of the type.  These subtags could directly reference the
+          primitive operations (for faster performance), or simply
+          provide the tag "slot" numbers for the primitive operations
+          (for easier derivation).  In either case, the subtags would be
+          used for calls that dispatch through a class-wide type of the
+          interface.
+
+1.c
+          Other implementation models are possible.
+
+1.d
+          The rules ensure that "dangling dispatching" is impossible;
+          that is, when a dispatching call is made, there is always a
+          body to execute.  This is different from some other
+          object-oriented languages, such as Smalltalk, where it is
+          possible to get a run-time error from a missing method.
+
+1.e/2
+          {AI95-00251-01AI95-00251-01} Dispatching calls should be
+          efficient, and should have a bounded worst-case execution
+          time.  This is important in a language intended for real-time
+          applications.  In the intended implementation model, a
+          dispatching call involves calling indirect through the
+          appropriate slot in the dispatch table.  No complicated
+          "method lookup" is involved although a call which is
+          dispatching on an interface may require a lookup of the
+          appropriate interface subtag.
+
+1.f
+          The programmer should have the choice at each call site of a
+          dispatching operation whether to do a dispatching call or a
+          statically determined call (i.e.  whether the body executed
+          should be determined at run time or at compile time).
+
+1.g
+          The same body should be executed for a call where the tag is
+          statically determined to be T'Tag as for a dispatching call
+          where the tag is found at run time to be T'Tag.  This allows
+          one to test a given tagged type with statically determined
+          calls, with some confidence that run-time dispatching will
+          produce the same behavior.
+
+1.h
+          All views of a type should share the same type descriptor and
+          the same tag.
+
+1.i
+          The visibility rules determine what is legal at compile time;
+          they have nothing to do with what bodies can be executed at
+          run time.  Thus, it is possible to dispatch to a subprogram
+          whose declaration is not visible at the call site.  In fact,
+          this is one of the primary facts that gives object-oriented
+          programming its power.  The subprogram that ends up being
+          dispatched to by a given call might even be designed long
+          after the call site has been coded and compiled.
+
+1.j
+          Given that Ada has overloading, determining whether a given
+          subprogram overrides another is based both on the names and
+          the type profiles of the operations.
+
+1.k/2
+          {AI95-00401-01AI95-00401-01} When a type extension is
+          declared, if there is any place within its immediate scope
+          where a certain subprogram of the parent or progenitor is
+          visible, then a matching subprogram should override.  If there
+          is no such place, then a matching subprogram should be totally
+          unrelated, and occupy a different slot in the type descriptor.
+          This is important to preserve the privacy of private parts;
+          when an operation declared in a private part is inherited, the
+          inherited version can be overridden only in that private part,
+          in the package body, and in any children of the package.
+
+1.l
+          If an implementation shares code for instances of generic
+          bodies, it should be allowed to share type descriptors of
+          tagged types declared in the generic body, so long as they are
+          not extensions of types declared in the specification of the
+          generic unit.
+
+                          _Static Semantics_
+
+2/2
+{AI95-00345-01AI95-00345-01} A record type or private type that has the
+reserved word tagged in its declaration is called a tagged type.  In
+addition, an interface type is a tagged type, as is a task or protected
+type derived from an interface (see *note 3.9.4::).  [When deriving from
+a tagged type, as for any derived type, additional primitive subprograms
+may be defined, and inherited primitive subprograms may be overridden.]  
+The derived type is called an extension of its ancestor types, or simply
+a type extension.
+
+2.1/2
+{AI95-00345-01AI95-00345-01} Every type extension is also a tagged type,
+and is a record extension or a private extension of some other tagged
+type, or a noninterface synchronized tagged type (see *note 3.9.4::).  A
+record extension is defined by a derived_type_definition with a
+record_extension_part (see *note 3.9.1::)[, which may include the
+definition of additional components].  A private extension, which is a
+partial view of a record extension or of a synchronized tagged type, can
+be declared in the visible part of a package (see *note 7.3::) or in a
+generic formal part (see *note 12.5.1::).
+
+2.a
+          Glossary entry: The objects of a tagged type have a run-time
+          type tag, which indicates the specific type with which the
+          object was originally created.  An operand of a class-wide
+          tagged type can be used in a dispatching call; the tag
+          indicates which subprogram body to invoke.  Nondispatching
+          calls, in which the subprogram body to invoke is determined at
+          compile time, are also allowed.  Tagged types may be extended
+          with additional components.
+
+2.b/2
+          Ramification: {AI95-00218-03AI95-00218-03} If a tagged type is
+          declared other than in a package_specification, it is
+          impossible to add new primitive subprograms for that type,
+          although it can inherit primitive subprograms, and those can
+          be overridden.  If the user incorrectly thinks a certain
+          subprogram is primitive when it is not, and tries to call it
+          with a dispatching call, an error message will be given at the
+          call site.  Similarly, by using an overriding_indicator (see
+          *note 6.1::), the user can declare that a subprogram is
+          intended to be overriding, and get an error message when they
+          made a mistake.  The use of overriding_indicators is highly
+          recommended in new code that does not need to be compatible
+          with Ada 95.
+
+3
+An object of a tagged type has an associated (run-time) tag that
+identifies the specific tagged type used to create the object
+originally.  [ The tag of an operand of a class-wide tagged type T'Class
+controls which subprogram body is to be executed when a primitive
+subprogram of type T is applied to the operand (see *note 3.9.2::);
+using a tag to control which body to execute is called dispatching.]  
+
+4/2
+{AI95-00344-01AI95-00344-01} The tag of a specific tagged type
+identifies the full_type_declaration of the type, and for a type
+extension, is sufficient to uniquely identify the type among all
+descendants of the same ancestor.  If a declaration for a tagged type
+occurs within a generic_package_declaration, then the corresponding type
+declarations in distinct instances of the generic package are associated
+with distinct tags.  For a tagged type that is local to a generic
+package body and with all of its ancestors (if any) also local to the
+generic body, the language does not specify whether repeated
+instantiations of the generic body result in distinct tags.
+
+4.a/2
+          This paragraph was deleted.{AI95-00344-01AI95-00344-01}
+
+4.a.1/2
+          Implementation Note: {AI95-00344-01AI95-00344-01} In most
+          cases, a tag need only identify a particular tagged type
+          declaration, and can therefore be a simple link-time-known
+          address.  However, for tag checks (see *note 3.9.2::) it is
+          essential that each descendant (that currently exists) of a
+          given type have a unique tag.  Hence, for types declared in
+          shared generic bodies where an ancestor comes from outside the
+          generic, or for types declared at a deeper level than an
+          ancestor, the tag needs to be augmented with some kind of
+          dynamic descriptor (which may be a static link, global
+          display, instance descriptor pointer, or combination).  This
+          implies that type Tag may need to be two words, the second of
+          which is normally null, but in these identified special cases
+          needs to include a static link or equivalent.  Within an
+          object of one of these types with a two-word tag, the two
+          parts of the tag would typically be separated, one part as the
+          first word of the object, the second placed in the first
+          extension part that corresponds to a type declared more nested
+          than its parent or declared in a shared generic body when the
+          parent is declared outside.  Alternatively, by using an extra
+          level of indirection, the type Tag could remain a single-word.
+
+4.b/2
+          {AI95-00344-01AI95-00344-01} For types that are not type
+          extensions (even for ones declared in nested scopes), we do
+          not require that repeated elaborations of the same
+          full_type_declaration correspond to distinct tags.  This was
+          done so that Ada 2005 implementations of tagged types could
+          maintain representation compatibility with Ada 95
+          implementations.  Only type extensions that were not allowed
+          in Ada 95 require additional information with the tag.
+
+4.c/2
+          To be honest: {AI95-00344-01AI95-00344-01} The wording "is
+          sufficient to uniquely identify the type among all descendants
+          of the same ancestor" only applies to types that currently
+          exist.  It is not necessary to distinguish between descendants
+          that currently exist, and descendants of the same type that no
+          longer exist.  For instance, the address of the stack frame of
+          the subprogram that created the tag is sufficient to meet the
+          requirements of this rule, even though it is possible, after
+          the subprogram returns, that a later call of the subprogram
+          could have the same stack frame and thus have an identical
+          tag.
+
+5
+The following language-defined library package exists:
+
+6/2
+     {AI95-00362-01AI95-00362-01} package Ada.Tags is
+         pragma Preelaborate(Tags);
+         type Tag is private;
+         pragma Preelaborable_Initialization(Tag);
+
+6.1/2
+     {AI95-00260-02AI95-00260-02}     No_Tag : constant Tag;
+
+7/2
+     {AI95-00400-01AI95-00400-01}     function Expanded_Name(T : Tag) return 
String;
+         function Wide_Expanded_Name(T : Tag) return Wide_String;
+         function Wide_Wide_Expanded_Name(T : Tag) return Wide_Wide_String;
+         function External_Tag(T : Tag) return String;
+         function Internal_Tag(External : String) return Tag;
+
+7.1/2
+     {AI95-00344-01AI95-00344-01}     function Descendant_Tag(External : 
String; Ancestor : Tag) return Tag;
+         function Is_Descendant_At_Same_Level(Descendant, Ancestor : Tag)
+             return Boolean;
+
+7.2/2
+     {AI95-00260-02AI95-00260-02}     function Parent_Tag (T : Tag) return Tag;
+
+7.3/2
+     {AI95-00405-01AI95-00405-01}     type Tag_Array is array (Positive range 
<>) of Tag;
+
+7.4/2
+     {AI95-00405-01AI95-00405-01}     function Interface_Ancestor_Tags (T : 
Tag) return Tag_Array;
+
+7.5/3
+     {AI05-0173-1AI05-0173-1}     function Is_Abstract (T : Tag) return 
Boolean;
+
+8
+         Tag_Error : exception;
+
+9
+     private
+        ... -- not specified by the language
+     end Ada.Tags;
+
+9.a
+          Reason: Tag is a nonlimited, definite subtype, because it
+          needs the equality operators, so that tag checking makes
+          sense.  Also, equality, assignment, and object declaration are
+          all useful capabilities for this subtype.
+
+9.b
+          For an object X and a type T, "X'Tag = T'Tag" is not needed,
+          because a membership test can be used.  However, comparing the
+          tags of two objects cannot be done via membership.  This is
+          one reason to allow equality for type Tag.
+
+9.1/2
+{AI95-00260-02AI95-00260-02} No_Tag is the default initial value of type
+Tag.
+
+9.c/2
+          Reason: {AI95-00260-02AI95-00260-02} This is similar to the
+          requirement that all access values be initialized to null.
+
+10/2
+{AI95-00400-01AI95-00400-01} The function Wide_Wide_Expanded_Name
+returns the full expanded name of the first subtype of the specific type
+identified by the tag, in upper case, starting with a root library unit.
+The result is implementation defined if the type is declared within an
+unnamed block_statement.
+
+10.a
+          To be honest: This name, as well as each prefix of it, does
+          not denote a renaming_declaration.
+
+10.b/2
+          Implementation defined: The result of
+          Tags.Wide_Wide_Expanded_Name for types declared within an
+          unnamed block_statement.
+
+10.1/2
+{AI95-00400-01AI95-00400-01} The function Expanded_Name (respectively,
+Wide_Expanded_Name) returns the same sequence of graphic characters as
+that defined for Wide_Wide_Expanded_Name, if all the graphic characters
+are defined in Character (respectively, Wide_Character); otherwise, the
+sequence of characters is implementation defined, but no shorter than
+that returned by Wide_Wide_Expanded_Name for the same value of the
+argument.
+
+10.c/2
+          Implementation defined: The sequence of characters of the
+          value returned by Tags.Expanded_Name (respectively,
+          Tags.Wide_Expanded_Name) when some of the graphic characters
+          of Tags.Wide_Wide_Expanded_Name are not defined in Character
+          (respectively, Wide_Character).
+
+11
+The function External_Tag returns a string to be used in an external
+representation for the given tag.  The call External_Tag(S'Tag) is
+equivalent to the attribute_reference S'External_Tag (see *note 13.3::).
+
+11.a
+          Reason: It might seem redundant to provide both the function
+          External_Tag and the attribute External_Tag.  The function is
+          needed because the attribute can't be applied to values of
+          type Tag.  The attribute is needed so that it can be specified
+          via an attribute_definition_clause.
+
+11.1/2
+{AI95-00417-01AI95-00417-01} The string returned by the functions
+Expanded_Name, Wide_Expanded_Name, Wide_Wide_Expanded_Name, and
+External_Tag has lower bound 1.
+
+12/2
+{AI95-00279-01AI95-00279-01} The function Internal_Tag returns a tag
+that corresponds to the given external tag, or raises Tag_Error if the
+given string is not the external tag for any specific type of the
+partition.  Tag_Error is also raised if the specific type identified is
+a library-level type whose tag has not yet been created (see *note
+13.14::).
+
+12.a/3
+          Reason: {AI95-00279-01AI95-00279-01} {AI05-0005-1AI05-0005-1}
+          The check for uncreated library-level types prevents a
+          reference to the type before execution reaches the freezing
+          point of the type.  This is important so that T'Class'Input or
+          an instance of Tags.Generic_Dispatching_Constructor do not try
+          to create an object of a type that hasn't been frozen (which
+          might not have yet elaborated its constraints).  We don't
+          require this behavior for non-library-level types as the tag
+          can be created multiple times and possibly multiple copies can
+          exist at the same time, making the check complex.
+
+12.1/3
+{AI95-00344-01AI95-00344-01} {AI05-0113-1AI05-0113-1} The function
+Descendant_Tag returns the (internal) tag for the type that corresponds
+to the given external tag and is both a descendant of the type
+identified by the Ancestor tag and has the same accessibility level as
+the identified ancestor.  Tag_Error is raised if External is not the
+external tag for such a type.  Tag_Error is also raised if the specific
+type identified is a library-level type whose tag has not yet been
+created, or if the given external tag identifies more than one type that
+has the appropriate Ancestor and accessibility level.
+
+12.b/2
+          Reason: Descendant_Tag is used by T'Class'Input to identify
+          the type identified by an external tag.  Because there can be
+          multiple elaborations of a given type declaration,
+          Internal_Tag does not have enough information to choose a
+          unique such type.  Descendant_Tag does not return the tag for
+          types declared at deeper accessibility levels than the
+          ancestor because there could be ambiguity in the presence of
+          recursion or multiple tasks.  Descendant_Tag can be used in
+          constructing a user-defined replacement for T'Class'Input.
+
+12.b.1/3
+          {AI05-0113-1AI05-0113-1} Rules for specifying external tags
+          will usually prevent an external tag from identifying more
+          than one type.  However, an external tag can identify multiple
+          types if a generic body contains a derivation of a tagged type
+          declared outside of the generic, and there are multiple
+          instances at the same accessibility level as the type.  (The
+          Standard allows default external tags to not be unique in this
+          case.)
+
+12.2/2
+{AI95-00344-01AI95-00344-01} The function Is_Descendant_At_Same_Level
+returns True if the Descendant tag identifies a type that is both a
+descendant of the type identified by Ancestor and at the same
+accessibility level.  If not, it returns False.
+
+12.c/2
+          Reason: Is_Descendant_At_Same_Level (or something similar to
+          it) is used by T'Class'Output to determine whether the item
+          being written is at the same accessibility level as T. It may
+          be used to determine prior to using T'Class'Output whether
+          Tag_Error will be raised, and also can be used in constructing
+          a user-defined replacement for T'Class'Output.
+
+12.3/3
+{AI05-0115-1AI05-0115-1} For the purposes of the dynamic semantics of
+functions Descendant_Tag and Is_Descendant_At_Same_Level, a tagged type
+T2 is a descendant of a type T1 if it is the same as T1, or if its
+parent type or one of its progenitor types is a descendant of type T1 by
+this rule[, even if at the point of the declaration of T2, one of the
+derivations in the chain is not visible].
+
+12.c.1/3
+          Discussion: In other contexts, "descendant" is dependent on
+          visibility, and the particular view a derived type has of its
+          parent type.  See *note 7.3.1::.
+
+12.4/3
+{AI95-00260-02AI95-00260-02} The function Parent_Tag returns the tag of
+the parent type of the type whose tag is T. If the type does not have a
+parent type (that is, it was not declared by a
+derived_type_declaration), then No_Tag is returned.
+
+12.d/2
+          Ramification: The parent type is always the parent of the full
+          type; a private extension appears to define a parent type, but
+          it does not (only the various forms of derivation do that).
+          As this is a run-time operation, ignoring privateness is OK.
+
+12.5/3
+{AI95-00405-01AI95-00405-01} The function Interface_Ancestor_Tags
+returns an array containing the tag of each interface ancestor type of
+the type whose tag is T, other than T itself.  The lower bound of the
+returned array is 1, and the order of the returned tags is unspecified.
+Each tag appears in the result exactly once.[ If the type whose tag is T
+has no interface ancestors, a null array is returned.]
+
+12.e/2
+          Ramification: The result of Interface_Ancestor_Tags includes
+          the tag of the parent type, if the parent is an interface.
+
+12.f/2
+          Indirect interface ancestors are included in the result of
+          Interface_Ancestor_Tags.  That's because where an interface
+          appears in the derivation tree has no effect on the semantics
+          of the type; the only interesting property is whether the type
+          has an interface as an ancestor.
+
+12.6/3
+{AI05-0173-1AI05-0173-1} The function Is_Abstract returns True if the
+type whose tag is T is abstract, and False otherwise.
+
+13
+For every subtype S of a tagged type T (specific or class-wide), the
+following attributes are defined:
+
+14
+S'Class
+               S'Class denotes a subtype of the class-wide type (called
+               T'Class in this International Standard) for the class
+               rooted at T (or if S already denotes a class-wide
+               subtype, then S'Class is the same as S).
+
+15
+               S'Class is unconstrained.  However, if S is constrained,
+               then the values of S'Class are only those that when
+               converted to the type T belong to S.
+
+15.a
+          Ramification: This attribute is defined for both specific and
+          class-wide subtypes.  The definition is such that
+          S'Class'Class is the same as S'Class.
+
+15.b
+          Note that if S is constrained, S'Class is only partially
+          constrained, since there might be additional discriminants
+          added in descendants of T which are not constrained.
+
+15.c/2
+          Reason: {AI95-00326-01AI95-00326-01} The Class attribute is
+          not defined for untagged subtypes (except for incomplete types
+          and private types whose full view is tagged -- see *note
+          J.11:: and *note 7.3.1::) so as to preclude implicit
+          conversion in the absence of run-time type information.  If it
+          were defined for untagged subtypes, it would correspond to the
+          concept of universal types provided for the predefined numeric
+          classes.
+
+16
+S'Tag
+               S'Tag denotes the tag of the type T (or if T is
+               class-wide, the tag of the root type of the corresponding
+               class).  The value of this attribute is of type Tag.
+
+16.a
+          Reason: S'Class'Tag equals S'Tag, to avoid generic contract
+          model problems when S'Class is the actual type associated with
+          a generic formal derived type.
+
+17
+Given a prefix X that is of a class-wide tagged type [(after any
+implicit dereference)], the following attribute is defined:
+
+18
+X'Tag
+               X'Tag denotes the tag of X. The value of this attribute
+               is of type Tag.
+
+18.a
+          Reason: X'Tag is not defined if X is of a specific type.  This
+          is primarily to avoid confusion that might result about
+          whether the Tag attribute should reflect the tag of the type
+          of X, or the tag of X. No such confusion is possible if X is
+          of a class-wide type.
+
+18.1/2
+{AI95-00260-02AI95-00260-02} {AI95-00441-01AI95-00441-01} The following
+language-defined generic function exists:
+
+18.2/3
+     {AI05-0229-1AI05-0229-1} generic
+         type T (<>) is abstract tagged limited private;
+         type Parameters (<>) is limited private;
+         with function Constructor (Params : not null access Parameters)
+             return T is abstract;
+     function Ada.Tags.Generic_Dispatching_Constructor
+        (The_Tag : Tag;
+         Params  : not null access Parameters) return T'Class
+        with Convention => Intrinsic;
+     pragma Preelaborate(Generic_Dispatching_Constructor);
+
+18.3/2
+{AI95-00260-02AI95-00260-02} Tags.Generic_Dispatching_Constructor
+provides a mechanism to create an object of an appropriate type from
+just a tag value.  The function Constructor is expected to create the
+object given a reference to an object of type Parameters.
+
+18.b/2
+          Discussion: This specification is designed to make it easy to
+          create dispatching constructors for streams; in particular,
+          this can be used to construct overridings for T'Class'Input.
+
+18.c/2
+          Note that any tagged type will match T (see *note 12.5.1::).
+
+                          _Dynamic Semantics_
+
+19
+The tag associated with an object of a tagged type is determined as
+follows:
+
+20
+   * The tag of a stand-alone object, a component, or an aggregate of a
+     specific tagged type T identifies T.
+
+20.a
+          Discussion: The tag of a formal parameter of type T is not
+          necessarily the tag of T, if, for example, the actual was a
+          type conversion.
+
+21
+   * The tag of an object created by an allocator for an access type
+     with a specific designated tagged type T, identifies T.
+
+21.a
+          Discussion: The tag of an object designated by a value of such
+          an access type might not be T, if, for example, the access
+          value is the result of a type conversion.
+
+22
+   * The tag of an object of a class-wide tagged type is that of its
+     initialization expression.
+
+22.a
+          Ramification: The tag of an object (even a class-wide one)
+          cannot be changed after it is initialized, since a
+          "class-wide" assignment_statement raises Constraint_Error if
+          the tags don't match, and a "specific" assignment_statement
+          does not affect the tag.
+
+23
+   * The tag of the result returned by a function whose result type is a
+     specific tagged type T identifies T.
+
+23.a/2
+          Implementation Note: {AI95-00318-02AI95-00318-02} For a
+          limited tagged type, the return object is "built in place" in
+          the ultimate result object with the appropriate tag.  For a
+          nonlimited type, a new anonymous object with the appropriate
+          tag is created as part of the function return.  See *note
+          6.5::, "*note 6.5:: Return Statements".
+
+24/2
+   * {AI95-00318-02AI95-00318-02} The tag of the result returned by a
+     function with a class-wide result type is that of the return
+     object.
+
+25
+The tag is preserved by type conversion and by parameter passing.  The
+tag of a value is the tag of the associated object (see *note 6.2::).
+
+25.1/3
+{AI95-00260-02AI95-00260-02} {AI95-00344-01AI95-00344-01}
+{AI95-00405-01AI95-00405-01} {AI05-0092-1AI05-0092-1}
+{AI05-0262-1AI05-0262-1} Tag_Error is raised by a call of
+Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tags,
+Is_Abstract, Is_Descendant_At_Same_Level, Parent_Tag,
+Wide_Expanded_Name, or Wide_Wide_Expanded_Name if any tag passed is
+No_Tag.
+
+25.2/2
+{AI95-00260-02AI95-00260-02} An instance of
+Tags.Generic_Dispatching_Constructor raises Tag_Error if The_Tag does
+not represent a concrete descendant of T or if the innermost master (see
+*note 7.6.1::) of this descendant is not also a master of the instance.
+Otherwise, it dispatches to the primitive function denoted by the formal
+Constructor for the type identified by The_Tag, passing Params, and
+returns the result.  Any exception raised by the function is propagated.
+
+25.a/2
+          Ramification: The tag check checks both that The_Tag is in
+          T'Class, and that it is not abstract.  These checks are
+          similar to the ones required by streams for T'Class'Input (see
+          *note 13.13.2::).  In addition, there is a check that the tag
+          identifies a type declared on the current dynamic call chain,
+          and not a more nested type or a type declared by another task.
+          This check is not necessary for streams, because the stream
+          attributes are declared at the same dynamic level as the type
+          used.
+
+                         _Erroneous Execution_
+
+25.3/2
+{AI95-00260-02AI95-00260-02} If an internal tag provided to an instance
+of Tags.Generic_Dispatching_Constructor or to any subprogram declared in
+package Tags identifies either a type that is not library-level and
+whose tag has not been created (see *note 13.14::), or a type that does
+not exist in the partition at the time of the call, then execution is
+erroneous.
+
+25.b/2
+          Ramification: One reason that a type might not exist in the
+          partition is that the tag refers to a type whose declaration
+          was elaborated as part of an execution of a subprogram_body
+          which has been left (see *note 7.6.1::).
+
+25.c/2
+          We exclude tags of library-level types from the current
+          execution of the partition, because misuse of such tags should
+          always be detected.  T'Tag freezes the type (and thus creates
+          the tag), and Internal_Tag and Descendant_Tag cannot return
+          the tag of a library-level type that has not been created.
+          All ancestors of a tagged type must be frozen no later than
+          the (full) declaration of a type that uses them, so Parent_Tag
+          and Interface_Ancestor_Tags cannot return a tag that has not
+          been created.  Finally, library-level types never cease to
+          exist while the partition is executing.  Thus, if the tag
+          comes from a library-level type, there cannot be erroneous
+          execution (the use of Descendant_Tag rather than Internal_Tag
+          can help ensure that the tag is of a library-level type).
+          This is also similar to the rules for T'Class'Input (see *note
+          13.13.2::).
+
+25.d/2
+          Discussion: {AI95-00344-01AI95-00344-01} Ada 95 allowed
+          Tag_Error in this case, or expected the functions to work.
+          This worked because most implementations used tags constructed
+          at link-time, and each elaboration of the same
+          type_declaration produced the same tag.  However, Ada 2005
+          requires at least part of the tags to be dynamically
+          constructed for a type derived from a type at a shallower
+          level.  For dynamically constructed tags, detecting the error
+          can be expensive and unreliable.  To see this, consider a
+          program containing two tasks.  Task A creates a nested tagged
+          type, passes the tag to task B (which saves it), and then
+          terminates.  The nested tag (if dynamic) probably will need to
+          refer in some way to the stack frame for task A. If task B
+          later tries to use the tag created by task A, the tag's
+          reference to the stack frame of A probably is a dangling
+          pointer.  Avoiding this would require some sort of protected
+          tag manager, which would be a bottleneck in a program's
+          performance.  Moreover, we'd still have a race condition; if
+          task A terminated after the tag check, but before the tag was
+          used, we'd still have a problem.  That means that all of these
+          operations would have to be serialized.  That could be a
+          significant performance drain, whether or not nested tagged
+          types are ever used.  Therefore, we allow execution to become
+          erroneous as we do for other dangling pointers.  If the
+          implementation can detect the error, we recommend that
+          Tag_Error be raised.
+
+                     _Implementation Permissions_
+
+26/2
+{AI95-00260-02AI95-00260-02} {AI95-00279-01AI95-00279-01} The
+implementation of Internal_Tag and Descendant_Tag may raise Tag_Error if
+no specific type corresponding to the string External passed as a
+parameter exists in the partition at the time the function is called, or
+if there is no such type whose innermost master is a master of the point
+of the function call.
+
+26.a/2
+          Reason: {AI95-00260-02AI95-00260-02}
+          {AI95-00279-01AI95-00279-01} {AI95-00344-01AI95-00344-01}
+          Locking would be required to ensure that the mapping of
+          strings to tags never returned tags of types which no longer
+          exist, because types can cease to exist (because they belong
+          to another task, as described above) during the execution of
+          these operations.  Moreover, even if these functions did use
+          locking, that would not prevent the type from ceasing to exist
+          at the instant that the function returned.  Thus, we do not
+          require the overhead of locking; hence the word "may" in this
+          rule.
+
+                        _Implementation Advice_
+
+26.1/3
+{AI95-00260-02AI95-00260-02} {AI05-0113-1AI05-0113-1} Internal_Tag
+should return the tag of a type, if one exists, whose innermost master
+is a master of the point of the function call.
+
+26.b/3
+          Implementation Advice: Tags.Internal_Tag should return the tag
+          of a type, if one exists, whose innermost master is a master
+          of the point of the function call..
+
+26.c/2
+          Reason: {AI95-00260-02AI95-00260-02}
+          {AI95-00344-01AI95-00344-01} It's not helpful if Internal_Tag
+          returns the tag of some type in another task when one is
+          available in the task that made the call.  We don't require
+          this behavior (because it requires the same implementation
+          techniques we decided not to insist on previously), but
+          encourage it.
+
+26.d/3
+          Discussion: {AI05-0113-1AI05-0113-1} There is no Advice for
+          the result of Internal_Tag if no such type exists.  In most
+          cases, the Implementation Permission can be used to raise
+          Tag_Error, but some other tag can be returned as well.
+
+     NOTES
+
+27
+     67  A type declared with the reserved word tagged should normally
+     be declared in a package_specification, so that new primitive
+     subprograms can be declared for it.
+
+28
+     68  Once an object has been created, its tag never changes.
+
+29
+     69  Class-wide types are defined to have unknown discriminants (see
+     *note 3.7::).  This means that objects of a class-wide type have to
+     be explicitly initialized (whether created by an object_declaration
+     or an allocator), and that aggregates have to be explicitly
+     qualified with a specific type when their expected type is
+     class-wide.
+
+30/2
+     70  {AI95-00260-02AI95-00260-02} {AI95-00326-01AI95-00326-01} The
+     capability provided by Tags.Generic_Dispatching_Constructor is
+     sometimes known as a factory.
+
+                              _Examples_
+
+31
+Examples of tagged record types:
+
+32
+     type Point is tagged
+       record
+         X, Y : Real := 0.0;
+       end record;
+
+33
+     type Expression is tagged null record;
+       -- Components will be added by each extension
+
+                        _Extensions to Ada 83_
+
+33.a
+          Tagged types are a new concept.
+
+                     _Inconsistencies With Ada 95_
+
+33.b/2
+          {AI95-00279-01AI95-00279-01} Amendment Correction: Added
+          wording specifying that Internal_Tag must raise Tag_Error if
+          the tag of a library-level type has not yet been created.  Ada
+          95 gave an Implementation Permission to do this; we require it
+          to avoid erroneous execution when streaming in an object of a
+          library-level type that has not yet been elaborated.  This is
+          technically inconsistent; a program that used Internal_Tag
+          outside of streaming and used a compiler that didn't take
+          advantage of the Implementation Permission would not have
+          raised Tag_Error, and may have returned a useful tag.  (If the
+          tag was used in streaming, the program would have been
+          erroneous.)  Since such a program would not have been portable
+          to a compiler that did take advantage of the Implementation
+          Permission, this is not a significant inconsistency.
+
+33.c/2
+          {AI95-00417-01AI95-00417-01} We now define the lower bound of
+          the string returned from [[Wide_]Wide_]Expanded_Name and
+          External_Name.  This makes working with the returned string
+          easier, and is consistent with many other string-returning
+          functions in Ada.  This is technically an inconsistency; if a
+          program depended on some other lower bound for the string
+          returned from one of these functions, it could fail when
+          compiled with Ada 2005.  Such code is not portable even
+          between Ada 95 implementations, so it should be very rare.
+
+                    _Incompatibilities With Ada 95_
+
+33.d/3
+          {AI95-00260-02AI95-00260-02} {AI95-00344-01AI95-00344-01}
+          {AI95-00400-01AI95-00400-01} {AI95-00405-01AI95-00405-01}
+          {AI05-0005-1AI05-0005-1} Constant No_Tag, and functions
+          Parent_Tag, Interface_Ancestor_Tags, Descendant_Tag,
+          Is_Descendant_At_Same_Level, Wide_Expanded_Name, and
+          Wide_Wide_Expanded_Name are added to Ada.Tags.  If Ada.Tags is
+          referenced in a use_clause, and an entity E with the same
+          defining_identifier as a new entity in Ada.Tags is defined in
+          a package that is also referenced in a use_clause, the entity
+          E may no longer be use-visible, resulting in errors.  This
+          should be rare and is easily fixed if it does occur.
+
+                        _Extensions to Ada 95_
+
+33.e/2
+          {AI95-00362-01AI95-00362-01} Ada.Tags is now defined to be
+          preelaborated.
+
+33.f/2
+          {AI95-00260-02AI95-00260-02} Generic function
+          Tags.Generic_Dispatching_Constructor is new.
+
+                     _Wording Changes from Ada 95_
+
+33.g/2
+          {AI95-00318-02AI95-00318-02} We talk about return objects
+          rather than return expressions, as functions can return using
+          an extended_return_statement.
+
+33.h/2
+          {AI95-00344-01AI95-00344-01} Added wording to define that tags
+          for all descendants of a tagged type must be distinct.  This
+          is needed to ensure that more nested type extensions will work
+          properly.  The wording does not require implementation changes
+          for types that were allowed in Ada 95.
+
+                    _Inconsistencies With Ada 2005_
+
+33.i/3
+          {AI05-0113-1AI05-0113-1} Correction: Added wording specifying
+          that Dependent_Tag must raise Tag_Error if there is more than
+          one type which matches the requirements.  If an implementation
+          had returned a random tag of the matching types, a program may
+          have worked properly.  However, such a program would not be
+          portable (another implementation may return a different tag)
+          and the conditions that would cause the problem are unlikely
+          (most likely, a tagged type extension declared in a generic
+          body with multiple instances in the same scope).
+
+                   _Incompatibilities With Ada 2005_
+
+33.j/3
+          {AI05-0173-1AI05-0173-1} Function Is_Abstract is added to
+          Ada.Tags.  If Ada.Tags is referenced in a use_clause, and an
+          entity E with the defining_identifier Is_Abstract is defined
+          in a package that is also referenced in a use_clause, the
+          entity E may no longer be use-visible, resulting in errors.
+          This should be rare and is easily fixed if it does occur.
+
+                    _Wording Changes from Ada 2005_
+
+33.k/3
+          {AI05-0115-1AI05-0115-1} Correction: We explicitly define the
+          meaning of "descendant" at runtime, so that it does not depend
+          on visibility as does the usual meaning.
+
+* Menu:
+
+* 3.9.1 ::    Type Extensions
+* 3.9.2 ::    Dispatching Operations of Tagged Types
+* 3.9.3 ::    Abstract Types and Subprograms
+* 3.9.4 ::    Interface Types
+
+
+File: aarm2012.info,  Node: 3.9.1,  Next: 3.9.2,  Up: 3.9
+
+3.9.1 Type Extensions
+---------------------
+
+1/2
+{AI95-00345-01AI95-00345-01} [ Every type extension is a tagged type,
+and is a record extension or a private extension of some other tagged
+type, or a noninterface synchronized tagged type.]
+
+                     _Language Design Principles_
+
+1.a
+          We want to make sure that we can extend a generic formal
+          tagged type, without knowing its discriminants.
+
+1.b
+          We don't want to allow components in an extension aggregate to
+          depend on discriminants inherited from the parent value, since
+          such dependence requires staticness in aggregates, at least
+          for variants.
+
+                               _Syntax_
+
+2
+     record_extension_part ::= with record_definition
+
+                           _Legality Rules_
+
+3/2
+{AI95-00344-01AI95-00344-01} {AI95-00345-01AI95-00345-01}
+{AI95-00419-01AI95-00419-01} The parent type of a record extension shall
+not be a class-wide type nor shall it be a synchronized tagged type (see
+*note 3.9.4::).  If the parent type or any progenitor is nonlimited,
+then each of the components of the record_extension_part shall be
+nonlimited.  In addition to the places where Legality Rules normally
+apply (see *note 12.3::), these rules apply also in the private part of
+an instance of a generic unit.
+
+3.a
+          Reason: If the parent is a limited formal type, then the
+          actual might be nonlimited.
+
+3.b/2
+          {AI95-00344-01AI95-00344-01} Ada 95 required the record
+          extensions to be the same level as the parent type.  Now we
+          use accessibility checks on class-wide allocators and return
+          statements to prevent objects from living longer than their
+          type.
+
+3.c/2
+          {AI95-00345-01AI95-00345-01} Synchronized tagged types cannot
+          be extended.  We have this limitation so that all of the data
+          of a task or protected type is defined within the type.  Data
+          defined outside of the type wouldn't be subject to the mutual
+          exclusion properties of a protected type, and couldn't be used
+          by a task, and thus doesn't seem to be worth the potential
+          impact on implementations.
+
+4/2
+{AI95-00344-01AI95-00344-01} Within the body of a generic unit, or the
+body of any of its descendant library units, a tagged type shall not be
+declared as a descendant of a formal type declared within the formal
+part of the generic unit.
+
+4.a
+          Reason: This paragraph ensures that a dispatching call will
+          never attempt to execute an inaccessible subprogram body.
+
+4.a.1/2
+          {AI95-00344-01AI95-00344-01} The convoluted wording ("formal
+          type declared within the formal part") is necessary to include
+          tagged types that are formal parameters of formal packages of
+          the generic unit, as well as formal tagged and tagged formal
+          derived types of the generic unit.
+
+4.b/2
+          {AI95-00344-01AI95-00344-01} This rule is necessary in order
+          to preserve the contract model.
+
+4.c/2
+          {AI05-0005-1AI05-0005-1} {AI95-00344-01AI95-00344-01} If an
+          ancestor is a formal of the generic unit , we have a problem
+          because it might have an unknown number of subprograms that
+          require overriding, as in the following example:
+
+4.d/2
+               package P is
+                   type T is tagged null record;
+                   function F return T; -- Inherited versions will require 
overriding.
+               end P;
+
+4.e
+               generic
+                   type TT is tagged private;
+               package Gp is
+                   type NT is abstract new TT with null record;
+                   procedure Q(X : in NT) is abstract;
+               end Gp;
+
+4.f/2
+               package body Gp is
+                   type NT2 is new NT with null record; -- Illegal!
+                   procedure Q(X : in NT2) is begin null; end Q;
+                   -- Is this legal or not? Can't decide because
+                   -- we don't know whether TT had any functions that require
+                   -- overriding on extension.
+               end Gp;
+
+4.g
+               package I is new Gp(TT => P.T);
+
+4.h/2
+          I.NT is an abstract type with two abstract subprograms: F
+          (inherited as abstract) and Q (explicitly declared as
+          abstract).  But the generic body doesn't know about F, so we
+          don't know that it needs to be overridden to make a
+          nonabstract extension of NT.Hence, we have to disallow this
+          case.
+
+4.h.1/2
+          Similarly, since the actual type for a formal tagged limited
+          private type can be a nonlimited type, we would have a problem
+          if a type extension of a limited private formal type could be
+          declared in a generic body.  Such an extension could have a
+          task component, for example, and an object of that type could
+          be passed to a dispatching operation of a nonlimited ancestor
+          type.  That operation could try to copy the object with the
+          task component.  That would be bad.  So we disallow this as
+          well.
+
+4.i
+          If TT were declared as abstract, then we could have the same
+          problem with abstract procedures.
+
+4.j
+          We considered disallowing all tagged types in a generic body,
+          for simplicity.  We decided not to go that far, in order to
+          avoid unnecessary restrictions.
+
+4.k
+          We also considered trying make the accessibility level part of
+          the contract; i.e.  invent some way of saying (in the
+          generic_declaration) "all instances of this generic unit will
+          have the same accessibility level as the generic_declaration."
+          Unfortunately, that doesn't solve the part of the problem
+          having to do with abstract types.
+
+4.l/2
+          This paragraph was deleted.
+
+4.m/2
+          Ramification: {AI95-00344AI95-00344} This rule applies to
+          types with ancestors (directly or indirectly) of formal
+          interface types (see *note 12.5.5::), formal tagged private
+          types (see *note 12.5.1::), and formal derived private types
+          whose ancestor type is tagged (see *note 12.5.1::).
+
+                          _Static Semantics_
+
+4.1/2
+{AI95-00391-01AI95-00391-01} A record extension is a null extension if
+its declaration has no known_discriminant_part and its
+record_extension_part includes no component_declarations.
+
+                          _Dynamic Semantics_
+
+5
+The elaboration of a record_extension_part consists of the elaboration
+of the record_definition.
+
+     NOTES
+
+6
+     71  The term "type extension" refers to a type as a whole.  The
+     term "extension part" refers to the piece of text that defines the
+     additional components (if any) the type extension has relative to
+     its specified ancestor type.
+
+6.a
+          Discussion: We considered other terminology, such as "extended
+          type."  However, the terms "private extended type" and "record
+          extended type" did not convey the proper meaning.  Hence, we
+          have chosen to uniformly use the term "extension" as the type
+          resulting from extending a type, with "private extension"
+          being one produced by privately extending the type, and
+          "record extension" being one produced by extending the type
+          with an additional record-like set of components.  Note also
+          that the term "type extension" refers to the result of
+          extending a type in the language Oberon as well (though there
+          the term "extended type" is also used, interchangeably,
+          perhaps because Oberon doesn't have the concept of a "private
+          extension").
+
+7/2
+     72  {AI95-00344-01AI95-00344-01} When an extension is declared
+     immediately within a body, primitive subprograms are inherited and
+     are overridable, but new primitive subprograms cannot be added.
+
+8
+     73  A name that denotes a component (including a discriminant) of
+     the parent type is not allowed within the record_extension_part.
+     Similarly, a name that denotes a component defined within the
+     record_extension_part is not allowed within the
+     record_extension_part.  It is permissible to use a name that
+     denotes a discriminant of the record extension, providing there is
+     a new known_discriminant_part in the enclosing type declaration.
+     (The full rule is given in *note 3.8::.)
+
+8.a
+          Reason: The restriction against depending on discriminants of
+          the parent is to simplify the definition of extension
+          aggregates.  The restriction against using parent components
+          in other ways is methodological; it presumably simplifies
+          implementation as well.
+
+9
+     74  Each visible component of a record extension has to have a
+     unique name, whether the component is (visibly) inherited from the
+     parent type or declared in the record_extension_part (see *note
+     8.3::).
+
+                              _Examples_
+
+10
+Examples of record extensions (of types defined above in *note 3.9::):
+
+11
+     type Painted_Point is new Point with
+       record
+         Paint : Color := White;
+       end record;
+         -- Components X and Y are inherited
+
+12
+     Origin : constant Painted_Point := (X | Y => 0.0, Paint => Black);
+
+13
+     type Literal is new Expression with
+       record                 -- a leaf in an Expression tree
+         Value : Real;
+       end record;
+
+14
+     type Expr_Ptr is access all Expression'Class;
+                                    -- see *note 3.10::
+
+15
+     type Binary_Operation is new Expression with
+       record                 -- an internal node in an Expression tree
+         Left, Right : Expr_Ptr;
+       end record;
+
+16
+     type Addition is new Binary_Operation with null record;
+     type Subtraction is new Binary_Operation with null record;
+       -- No additional components needed for these extensions
+
+17
+     Tree : Expr_Ptr :=         -- A tree representation of "5.0 + (13.0-7.0)"
+        new Addition'(
+           Left  => new Literal'(Value => 5.0),
+           Right => new Subtraction'(
+              Left  => new Literal'(Value => 13.0),
+              Right => new Literal'(Value => 7.0)));
+
+                        _Extensions to Ada 83_
+
+17.a
+          Type extension is a new concept.
+
+                        _Extensions to Ada 95_
+
+17.b/2
+          {AI95-00344-01AI95-00344-01} Type extensions now can be
+          declared in more nested scopes than their parent types.
+          Additional accessibility checks on allocators and return
+          statements prevent objects from outliving their type.
+
+                     _Wording Changes from Ada 95_
+
+17.c/2
+          {AI95-00345-01AI95-00345-01} Added wording to prevent
+          extending synchronized tagged types.
+
+17.d/2
+          {AI95-00391-01AI95-00391-01} Defined null extension for use
+          elsewhere.
+
+
+File: aarm2012.info,  Node: 3.9.2,  Next: 3.9.3,  Prev: 3.9.1,  Up: 3.9
+
+3.9.2 Dispatching Operations of Tagged Types
+--------------------------------------------
+
+1/2
+{AI95-00260-02AI95-00260-02} {AI95-00335-01AI95-00335-01} The primitive
+subprograms of a tagged type, the subprograms declared by
+formal_abstract_subprogram_declaration (*note 12.6: S0297.)s, and the
+stream attributes of a specific tagged type that are available (see
+*note 13.13.2::) at the end of the declaration list where the type is
+declared are called dispatching operations.  [A dispatching operation
+can be called using a statically determined controlling tag, in which
+case the body to be executed is determined at compile time.
+Alternatively, the controlling tag can be dynamically determined, in
+which case the call dispatches to a body that is determined at run
+time;] such a call is termed a dispatching call.  [As explained below,
+the properties of the operands and the context of a particular call on a
+dispatching operation determine how the controlling tag is determined,
+and hence whether or not the call is a dispatching call.  Run-time
+polymorphism is achieved when a dispatching operation is called by a
+dispatching call.]  
+
+1.a.1/2
+          Reason: {AI95-00335-01AI95-00335-01} For the stream attributes
+          of a type declared immediately within a package_specification
+          that has a partial view, the declaration list to consider is
+          the visible part of the package.  Stream attributes that are
+          not available in the same declaration list are not dispatching
+          as there is no guarantee that descendants of the type have
+          available attributes (there is such a guarantee for visibly
+          available attributes).  If we allowed dispatching for any
+          available attribute, then for attributes defined in the
+          private part we could end up executing a nonexistent body.
+
+                     _Language Design Principles_
+
+1.a
+          The controlling tag determination rules are analogous to the
+          overload resolution rules, except they deal with run-time type
+          identification (tags) rather than compile-time type
+          resolution.  As with overload resolution, controlling tag
+          determination may depend on operands or result context.
+
+                          _Static Semantics_
+
+2/3
+{AI95-00260-02AI95-00260-02} {AI95-00416-01AI95-00416-01}
+{AI05-0076-1AI05-0076-1} A call on a dispatching operation is a call
+whose name or prefix denotes the declaration of a dispatching operation.
+A controlling operand in a call on a dispatching operation of a tagged
+type T is one whose corresponding formal parameter is of type T or is of
+an anonymous access type with designated type T; the corresponding
+formal parameter is called a controlling formal parameter.  If the
+controlling formal parameter is an access parameter, the controlling
+operand is the object designated by the actual parameter, rather than
+the actual parameter itself.  If the call is to a (primitive) function
+with result type T (a function with a controlling result), then the call
+has a controlling result -- the context of the call can control the
+dispatching.  Similarly, if the call is to a function with an access
+result type designating T (a function with a controlling access result),
+then the call has a controlling access result, and the context can
+similarly control dispatching.
+
+2.a
+          Ramification: This definition implies that a call through the
+          dereference of an access-to-subprogram value is never
+          considered a call on a dispatching operation.  Note also that
+          if the prefix denotes a renaming_declaration, the place where
+          the renaming occurs determines whether it is primitive; the
+          thing being renamed is irrelevant.
+
+3
+A name or expression of a tagged type is either statically tagged,
+dynamically tagged, or tag indeterminate, according to whether, when
+used as a controlling operand, the tag that controls dispatching is
+determined statically by the operand's (specific) type, dynamically by
+its tag at run time, or from context.  A qualified_expression or
+parenthesized expression is statically, dynamically, or indeterminately
+tagged according to its operand.  For other kinds of names and
+expressions, this is determined as follows:
+
+4/2
+   * {AI95-00416-01AI95-00416-01} The name or expression is statically
+     tagged if it is of a specific tagged type and, if it is a call with
+     a controlling result or controlling access result, it has at least
+     one statically tagged controlling operand;
+
+4.a
+          Discussion: It is illegal to have both statically tagged and
+          dynamically tagged controlling operands in the same call --
+          see below.
+
+5/2
+   * {AI95-00416-01AI95-00416-01} The name or expression is dynamically
+     tagged if it is of a class-wide type, or it is a call with a
+     controlling result or controlling access result and at least one
+     dynamically tagged controlling operand;
+
+6/2
+   * {AI95-00416-01AI95-00416-01} The name or expression is tag
+     indeterminate if it is a call with a controlling result or
+     controlling access result, all of whose controlling operands (if
+     any) are tag indeterminate.
+
+7/1
+{8652/00108652/0010} {AI95-00127-01AI95-00127-01} [A type_conversion is
+statically or dynamically tagged according to whether the type
+determined by the subtype_mark is specific or class-wide, respectively.]
+For an object that is designated by an expression whose expected type is
+an anonymous access-to-specific tagged type, the object is dynamically
+tagged if the expression, ignoring enclosing parentheses, is of the form
+X'Access, where X is of a class-wide type, or is of the form new
+T'(...), where T denotes a class-wide subtype.  Otherwise, the object is
+statically or dynamically tagged according to whether the designated
+type of the type of the expression is specific or class-wide,
+respectively.
+
+7.a
+          Ramification: A type_conversion is never tag indeterminate,
+          even if its operand is.  A designated object is never tag
+          indeterminate.
+
+7.a.1/1
+          {8652/00108652/0010} {AI95-00127-01AI95-00127-01} Allocators
+          and access attributes of class-wide types can be used as the
+          controlling parameters of dispatching calls.
+
+                           _Legality Rules_
+
+8
+A call on a dispatching operation shall not have both dynamically tagged
+and statically tagged controlling operands.
+
+8.a
+          Reason: This restriction is intended to minimize confusion
+          between whether the dynamically tagged operands are implicitly
+          converted to, or tag checked against the specific type of the
+          statically tagged operand(s).
+
+9/1
+{8652/00108652/0010} {AI95-00127-01AI95-00127-01} If the expected type
+for an expression or name is some specific tagged type, then the
+expression or name shall not be dynamically tagged unless it is a
+controlling operand in a call on a dispatching operation.  Similarly, if
+the expected type for an expression is an anonymous access-to-specific
+tagged type, then the object designated by the expression shall not be
+dynamically tagged unless it is a controlling operand in a call on a
+dispatching operation.
+
+9.a
+          Reason: This prevents implicit "truncation" of a
+          dynamically-tagged value to the specific type of the target
+          object/formal.  An explicit conversion is required to request
+          this truncation.
+
+9.b/2
+          Ramification: {AI95-00252-01AI95-00252-01} This rule applies
+          to all expressions or names with a specific expected type, not
+          just those that are actual parameters to a dispatching call.
+          This rule does not apply to a membership test whose expression
+          is class-wide, since any type that covers the tested type is
+          explicitly allowed.  See *note 4.5.2::.  This rule also
+          doesn't apply to a selected_component whose selector_name is a
+          subprogram, since the rules explicitly say that the prefix may
+          be class-wide (see *note 4.1.3::).
+
+10/2
+{8652/00118652/0011} {AI95-00117-01AI95-00117-01}
+{AI95-00430-01AI95-00430-01} In the declaration of a dispatching
+operation of a tagged type, everywhere a subtype of the tagged type
+appears as a subtype of the profile (see *note 6.1::), it shall
+statically match the first subtype of the tagged type.  If the
+dispatching operation overrides an inherited subprogram, it shall be
+subtype conformant with the inherited subprogram.  The convention of an
+inherited dispatching operation is the convention of the corresponding
+primitive operation of the parent or progenitor type.  The default
+convention of a dispatching operation that overrides an inherited
+primitive operation is the convention of the inherited operation; if the
+operation overrides multiple inherited operations, then they shall all
+have the same convention.  An explicitly declared dispatching operation
+shall not be of convention Intrinsic.
+
+10.a
+          Reason: These rules ensure that constraint checks can be
+          performed by the caller in a dispatching call, and parameter
+          passing conventions match up properly.  A special rule on
+          aggregates prevents values of a tagged type from being created
+          that are outside of its first subtype.
+
+11/2
+{AI95-00416-01AI95-00416-01} The default_expression for a controlling
+formal parameter of a dispatching operation shall be tag indeterminate.
+
+11.a/2
+          Reason: {AI95-00416-01AI95-00416-01} This rule ensures that
+          the default_expression always produces the "correct" tag when
+          called with or without dispatching, or when inherited by a
+          descendant.  If it were statically tagged, the default would
+          be useless for a dispatching call; if it were dynamically
+          tagged, the default would be useless for a nondispatching
+          call.
+
+11.1/2
+{AI95-00404-01AI95-00404-01} If a dispatching operation is defined by a
+subprogram_renaming_declaration or the instantiation of a generic
+subprogram, any access parameter of the renamed subprogram or the
+generic subprogram that corresponds to a controlling access parameter of
+the dispatching operation, shall have a subtype that excludes null.
+
+12
+A given subprogram shall not be a dispatching operation of two or more
+distinct tagged types.
+
+12.a
+          Reason: This restriction minimizes confusion since multiple
+          dispatching is not provided.  The normal solution is to
+          replace all but one of the tagged types with their class-wide
+          types.
+
+12.a.1/1
+          Ramification: {8652/00988652/0098}
+          {AI95-00183-01AI95-00183-01} This restriction applies even if
+          the partial view (see *note 7.3::) of one or both of the types
+          is untagged.  This follows from the definition of dispatching
+          operation: the operation is a dispatching operation anywhere
+          the full views of the (tagged) types are visible.
+
+13
+The explicit declaration of a primitive subprogram of a tagged type
+shall occur before the type is frozen (see *note 13.14::).  [For
+example, new dispatching operations cannot be added after objects or
+values of the type exist, nor after deriving a record extension from it,
+nor after a body.]
+
+13.a/2
+          Reason: {AI95-00344-01AI95-00344-01} This rule is needed
+          because (1) we don't want people dispatching to things that
+          haven't been declared yet, and (2) we want to allow the static
+          part of tagged type descriptors to be static (allocated
+          statically, and initialized to link-time-known symbols).
+          Suppose T2 inherits primitive P from T1, and then overrides P.
+          Suppose P is called before the declaration of the overriding
+          P. What should it dispatch to?  If the answer is the new P,
+          we've violated the first principle above.  If the answer is
+          the old P, we've violated the second principle.  (A call to
+          the new one necessarily raises Program_Error, but that's
+          beside the point.)
+
+13.b
+          Note that a call upon a dispatching operation of type T will
+          freeze T.
+
+13.c
+          We considered applying this rule to all derived types, for
+          uniformity.  However, that would be upward incompatible, so we
+          rejected the idea.  As in Ada 83, for an untagged type, the
+          above call upon P will call the old P (which is arguably
+          confusing).
+
+13.d/2
+          Implementation Note: {AI95-00326-01AI95-00326-01} Because of
+          this rule, the type descriptor can be created (presumably
+          containing linker symbols pointing at the not-yet-compiled
+          bodies) at the first freezing point of the type.  It also
+          prevents, for a (nonincomplete) tagged type declared in a
+          package_specification, overriding in the body or by a child
+          subprogram.
+
+13.e/2
+          Ramification: {AI95-00251-01AI95-00251-01} A consequence is
+          that for a tagged type declaration in a declarative_part, only
+          the last (overriding) primitive subprogram can be declared by
+          a subprogram_body.  (Other overridings must be provided by
+          subprogram_declarations.)
+
+13.f/3
+          To be honest: {AI05-0222-1AI05-0222-1} This rule applies only
+          to "original" declarations and not to the completion of a
+          primitive subprogram, even though a completion is technically
+          an explicit declaration, and it may declare a primitive
+          subprogram.
+
+                          _Dynamic Semantics_
+
+14
+For the execution of a call on a dispatching operation of a type T, the
+controlling tag value determines which subprogram body is executed.  The
+controlling tag value is defined as follows:
+
+15
+   * If one or more controlling operands are statically tagged, then the
+     controlling tag value is statically determined to be the tag of T.
+
+16
+   * If one or more controlling operands are dynamically tagged, then
+     the controlling tag value is not statically determined, but is
+     rather determined by the tags of the controlling operands.  If
+     there is more than one dynamically tagged controlling operand, a
+     check is made that they all have the same tag.  If this check
+     fails, Constraint_Error is raised unless the call is a
+     function_call whose name denotes the declaration of an equality
+     operator (predefined or user defined) that returns Boolean, in
+     which case the result of the call is defined to indicate
+     inequality, and no subprogram_body is executed.  This check is
+     performed prior to evaluating any tag-indeterminate controlling
+     operands.
+
+16.a
+          Reason: Tag mismatch is considered an error (except for "="
+          and "/=") since the corresponding primitive subprograms in
+          each specific type expect all controlling operands to be of
+          the same type.  For tag mismatch with an equality operator,
+          rather than raising an exception, "=" returns False and "/="
+          returns True.  No equality operator is actually invoked, since
+          there is no common tag value to control the dispatch.
+          Equality is a special case to be consistent with the existing
+          Ada 83 principle that equality comparisons, even between
+          objects with different constraints, never raise
+          Constraint_Error.
+
+17/2
+   * {AI95-00196-01AI95-00196-01} If all of the controlling operands (if
+     any) are tag-indeterminate, then:
+
+18/2
+             * {AI95-00239-01AI95-00239-01} {AI95-00416-01AI95-00416-01}
+               If the call has a controlling result or controlling
+               access result and is itself, or designates, a (possibly
+               parenthesized or qualified) controlling operand of an
+               enclosing call on a dispatching operation of a descendant
+               of type T, then its controlling tag value is determined
+               by the controlling tag value of this enclosing call;
+
+18.a/2
+          Discussion: {AI95-00239-01AI95-00239-01} For code that a user
+          can write explicitly, the only contexts that can control
+          dispatching of a function with a controlling result of type T
+          are those that involve controlling operands of the same type
+          T: if the two types differ there is an illegality and the
+          dynamic semantics are irrelevant.
+
+18.b/2
+          In the case of an inherited subprogram however, if a default
+          expression is a function call, it may be of type T while the
+          parameter is of a type derived from T. To cover this case, we
+          talk about "a descendant of T" above.  This is safe, because
+          if the type of the parameter is descended from the type of the
+          function result, it is guaranteed to inherit or override the
+          function, and this ensures that there will be an appropriate
+          body to dispatch to.  Note that abstract functions are not an
+          issue here because the call to the function is a dispatching
+          call, so it is guaranteed to always land on a concrete body.
+
+18.1/2
+             * {AI95-00196-01AI95-00196-01} {AI95-00416-01AI95-00416-01}
+               If the call has a controlling result or controlling
+               access result and (possibly parenthesized, qualified, or
+               dereferenced) is the expression of an
+               assignment_statement whose target is of a class-wide
+               type, then its controlling tag value is determined by the
+               target;
+
+19
+             * Otherwise, the controlling tag value is statically
+               determined to be the tag of type T.
+
+19.a
+          Ramification: This includes the cases of a tag-indeterminate
+          procedure call, and a tag-indeterminate function_call that is
+          used to initialize a class-wide formal parameter or class-wide
+          object.
+
+20/3
+{AI95-00345-01AI95-00345-01} {AI05-0126-1AI05-0126-1} For the execution
+of a call on a dispatching operation, the action performed is determined
+by the properties of the corresponding dispatching operation of the
+specific type identified by the controlling tag value:
+
+20.1/3
+   * {AI05-0126-1AI05-0126-1} if the corresponding operation is
+     explicitly declared for this type, [even if the declaration occurs
+     in a private part], then the action comprises an invocation of the
+     explicit body for the operation;
+
+20.2/3
+   * {AI95-00345-01AI95-00345-01} {AI05-0126-1AI05-0126-1} if the
+     corresponding operation is implicitly declared for this type and is
+     implemented by an entry or protected subprogram (see *note 9.1::
+     and *note 9.4::), then the action comprises a call on this entry or
+     protected subprogram, with the target object being given by the
+     first actual parameter of the call, and the actual parameters of
+     the entry or protected subprogram being given by the remaining
+     actual parameters of the call, if any;
+
+20.3/3
+   * {AI05-0197-1AI05-0197-1} if the corresponding operation is a
+     predefined operator then the action comprises an invocation of that
+     operator;
+
+20.4/3
+   * {AI95-00345-01AI95-00345-01} {AI05-0126-1AI05-0126-1}
+     {AI05-0197-1AI05-0197-1} {AI05-0250-1AI05-0250-1}
+     {AI05-0254-1AI05-0254-1} otherwise, the action is the same as the
+     action for the corresponding operation of the parent type or
+     progenitor type from which the operation was inherited except that
+     additional invariant checks (see *note 7.3.2::) and class-wide
+     postcondition checks (see *note 6.1.1::) may apply.  If there is
+     more than one such corresponding operation, the action is that for
+     the operation that is not a null procedure, if any; otherwise, the
+     action is that of an arbitrary one of the operations.
+
+20.a/3
+          This paragraph was deleted.{AI05-0126-1AI05-0126-1}
+
+20.a.1/3
+          Ramification: {AI05-0005-1AI05-0005-1}
+          {AI05-0126-1AI05-0126-1} "Corresponding dispatching operation"
+          refers to the inheritance relationship between subprograms.
+          Primitive operations are always inherited for a type T, but
+          they might not be declared if the primitive operation is never
+          visible within the immediate scope of the type T. If no
+          corresponding operation is declared, the last bullet is used
+          and the corresponding operation of the parent type is executed
+          (an explicit body that happens to have the same name and
+          profile is not called in that case).
+
+20.a.2/3
+          {AI05-0005-1AI05-0005-1} {AI05-0126-1AI05-0126-1} We have to
+          talk about progenitors in the last bullet in case the
+          corresponding operation is a null procedure inherited from an
+          interface.  In that case, the parent type might not even have
+          the operation in question.
+
+20.a.3/3
+          {AI05-0197-1AI05-0197-1} For the last bullet, if there are
+          multiple corresponding operations for the parent and
+          progenitors, all but one of them have to be a null procedure.
+          (If the progenitors declared abstract routines, there would
+          have to be an explicit overriding of the operation, and then
+          the first bullet would apply.)  We call the nonnull routine if
+          one exists.
+
+20.a.4/3
+          {AI05-0126-1AI05-0126-1} Any explicit declaration for an
+          inherited corresponding operation has to be an overriding
+          routine.  These rules mean that a dispatching call executes
+          the overriding routine (if any) for the specific type.
+
+20.b/3
+          Reason: {AI05-0005-1AI05-0005-1} The wording of the above
+          rules is intended to ensure that the same body is executed for
+          a given tag, whether that tag is determined statically or
+          dynamically.  For a type declared in a package, it doesn't
+          matter whether a given subprogram is overridden in the visible
+          part or the private part, and it doesn't matter whether the
+          call is inside or outside the package.  For example:
+
+20.c
+               package P1 is
+                   type T1 is tagged null record;
+                   procedure Op_A(Arg : in T1);
+                   procedure Op_B(Arg : in T1);
+               end P1;
+
+20.d
+               with P1; use P1;
+               package P2 is
+                   type T2 is new T1 with null record;
+                   procedure Op_A(Param : in T2);
+               private
+                   procedure Op_B(Param : in T2);
+               end P2;
+
+20.e/1
+               with P1; with P2;
+               procedure Main is
+                   X : P2.T2;
+                   Y : P1.T1'Class := X;
+               begin
+                   P2.Op_A(Param => X); -- Nondispatching call to a 
dispatching operation.
+                   P1.Op_A(Arg => Y); -- Dispatching call.
+                   P2.Op_B(Arg => X); -- Nondispatching call to a dispatching 
operation.
+                   P1.Op_B(Arg => Y); -- Dispatching call.
+               end Main;
+
+20.f
+          The two calls to Op_A both execute the body of Op_A that has
+          to occur in the body of package P2.  Similarly, the two calls
+          to Op_B both execute the body of Op_B that has to occur in the
+          body of package P2, even though Op_B is overridden in the
+          private part of P2.  Note, however, that the formal parameter
+          names are different for P2.Op_A versus P2.Op_B. The overriding
+          declaration for P2.Op_B is not visible in Main, so the name in
+          the call actually denotes the implicit declaration of Op_B
+          inherited from T1.
+
+20.g
+          If a call occurs in the program text before an overriding,
+          which can happen only if the call is part of a default
+          expression, the overriding will still take effect for that
+          call.
+
+20.h
+          Implementation Note: Even when a tag is not statically
+          determined, a compiler might still be able to figure it out
+          and thereby avoid the overhead of run-time dispatching.
+
+     NOTES
+
+21
+     75  The body to be executed for a call on a dispatching operation
+     is determined by the tag; it does not matter whether that tag is
+     determined statically or dynamically, and it does not matter
+     whether the subprogram's declaration is visible at the place of the
+     call.
+
+22/2
+     76  {AI95-00260-02AI95-00260-02} This subclause covers calls on
+     dispatching subprograms of a tagged type.  Rules for tagged type
+     membership tests are described in *note 4.5.2::.  Controlling tag
+     determination for an assignment_statement is described in *note
+     5.2::.
+
+23
+     77  A dispatching call can dispatch to a body whose declaration is
+     not visible at the place of the call.
+
+24
+     78  A call through an access-to-subprogram value is never a
+     dispatching call, even if the access value designates a dispatching
+     operation.  Similarly a call whose prefix denotes a
+     subprogram_renaming_declaration cannot be a dispatching call unless
+     the renaming itself is the declaration of a primitive subprogram.
+
+                        _Extensions to Ada 83_
+
+24.a
+          The concept of dispatching operations is new.
+
+                    _Incompatibilities With Ada 95_
+
+24.b/2
+          {AI95-00404-01AI95-00404-01} If a dispatching operation is
+          defined by a subprogram_renaming_declaration, and it has a
+          controlling access parameter, Ada 2005 requires the subtype of
+          the parameter to exclude null.  The same applies to
+          instantiations.  This is required so that all calls to the
+          subprogram operate the same way (controlling access parameters
+          have to exclude null so that dispatching calls will work).
+          Since Ada 95 didn't have the notion of access subtypes that
+          exclude null, and all access parameters excluded null, it had
+          no such rules.  These rules will require the addition of an
+          explicit not null on nondispatching operations that are later
+          renamed to be dispatching, or on a generic that is used to
+          define a dispatching operation.
+
+                        _Extensions to Ada 95_
+
+24.c/2
+          {AI95-00416-01AI95-00416-01} Functions that have an access
+          result type can be dispatching in the same way as a function
+          that returns a tagged object directly.
+
+                     _Wording Changes from Ada 95_
+
+24.d/3
+          {8652/00108652/0010} {AI95-00127-01AI95-00127-01}
+          {AI05-0299-1AI05-0299-1} Corrigendum: Allocators and access
+          attributes of objects of class-wide types can be used as the
+          controlling parameter in a dispatching calls.  This was an
+          oversight in the definition of Ada 95.  (See *note 3.10.2::
+          and *note 4.8::).
+
+24.e/2
+          {8652/00118652/0011} {AI95-00117-01AI95-00117-01}
+          {AI95-00430-01AI95-00430-01} Corrigendum: Corrected the
+          conventions of dispatching operations.  This is extended in
+          Ada 2005 to cover operations inherited from progenitors, and
+          to ensure that the conventions of all inherited operations are
+          the same.
+
+24.f/2
+          {AI95-00196-01AI95-00196-01} Clarified the wording to ensure
+          that functions with no controlling operands are
+          tag-indeterminate, and to describe that the controlling tag
+          can come from the target of an assignment_statement.
+
+24.g/2
+          {AI95-00239-01AI95-00239-01} Fixed the wording to cover
+          default expressions inherited by derived subprograms.  A
+          literal reading of the old wording would have implied that
+          operations would be called with objects of the wrong type.
+
+24.h/2
+          {AI95-00260-02AI95-00260-02} An abstract formal subprogram is
+          a dispatching operation, even though it is not a primitive
+          operation.  See *note 12.6::, "*note 12.6:: Formal
+          Subprograms".
+
+24.i/2
+          {AI95-00345-01AI95-00345-01} Dispatching calls include
+          operations implemented by entries and protected operations, so
+          we have to update the wording to reflect that.
+
+24.j/2
+          {AI95-00335-01AI95-00335-01} A stream attribute of a tagged
+          type is usually a dispatching operation, even though it is not
+          a primitive operation.  If they weren't dispatching,
+          T'Class'Input and T'Class'Output wouldn't work.
+
+                    _Wording Changes from Ada 2005_
+
+24.k/3
+          {AI05-0076-1AI05-0076-1} Correction: Defined "function with a
+          controlling result", as it is used in *note 3.9.3::.
+
+24.l/3
+          {AI05-0126-1AI05-0126-1} {AI05-0197-1AI05-0197-1} Correction:
+          Corrected holes in the definition of dynamic dispatching: the
+          behavior for operations that are never declared and/or
+          inherited from a progenitor were not specified.
+
+
+File: aarm2012.info,  Node: 3.9.3,  Next: 3.9.4,  Prev: 3.9.2,  Up: 3.9
+
+3.9.3 Abstract Types and Subprograms
+------------------------------------
+
+1/2
+{AI95-00345-01AI95-00345-01} [ An abstract type is a tagged type
+intended for use as an ancestor of other types, but which is not allowed
+to have objects of its own.  An abstract subprogram is a subprogram that
+has no body, but is intended to be overridden at some point when
+inherited.  Because objects of an abstract type cannot be created, a
+dispatching call to an abstract subprogram always dispatches to some
+overriding body.]
+
+1.a.1/2
+          Glossary entry: An abstract type is a tagged type intended for
+          use as an ancestor of other types, but which is not allowed to
+          have objects of its own.
+
+                     _Language Design Principles_
+
+1.a/3
+          {AI05-0299-1AI05-0299-1} An abstract subprogram has no body,
+          so the rules in this subclause are designed to ensure (at
+          compile time) that the body will never be invoked.  We do so
+          primarily by disallowing the creation of values of the
+          abstract type.  Therefore, since type conversion and parameter
+          passing don't change the tag, we know we will never get a
+          class-wide value with a tag identifying an abstract type.
+          This means that we only have to disallow nondispatching calls
+          on abstract subprograms (dispatching calls will never reach
+          them).
+
+                               _Syntax_
+
+1.1/3
+     {AI95-00218-03AI95-00218-03} {AI95-00348-01AI95-00348-01}
+     {AI05-0183-1AI05-0183-1} abstract_subprogram_declaration ::=
+         [overriding_indicator]
+         subprogram_specification is abstract
+             [aspect_specification];
+
+                          _Static Semantics_
+
+1.2/2
+{AI95-00345-01AI95-00345-01} Interface types (see *note 3.9.4::) are
+abstract types.  In addition, a tagged type that has the reserved word
+abstract in its declaration is an abstract type.  The class-wide type
+(see *note 3.4.1::) rooted at an abstract type is not itself an abstract
+type.
+
+                           _Legality Rules_
+
+2/2
+{AI95-00345-01AI95-00345-01} Only a tagged type shall have the reserved
+word abstract in its declaration.
+
+2.a
+          Ramification: Untagged types are never abstract, even though
+          they can have primitive abstract subprograms.  Such
+          subprograms cannot be called, unless they also happen to be
+          dispatching operations of some tagged type, and then only via
+          a dispatching call.
+
+2.b
+          Class-wide types are never abstract.  If T is abstract, then
+          it is illegal to declare a stand-alone object of type T, but
+          it is OK to declare a stand-alone object of type T'Class; the
+          latter will get a tag from its initial value, and this tag
+          will necessarily be different from T'Tag.
+
+3/2
+{AI95-00260-02AI95-00260-02} {AI95-00348-01AI95-00348-01} A subprogram
+declared by an abstract_subprogram_declaration (*note 3.9.3: S0076.) or
+a formal_abstract_subprogram_declaration (*note 12.6: S0297.) (see *note
+12.6::) is an abstract subprogram.  If it is a primitive subprogram of a
+tagged type, then the tagged type shall be abstract.
+
+3.a
+          Ramification: Note that for a private type, this applies to
+          both views.  The following is illegal:
+
+3.b
+               package P is
+                   type T is abstract tagged private;
+                   function Foo (X : T) return Boolean is abstract; -- Illegal!
+               private
+                   type T is tagged null record; -- Illegal!
+                   X : T;
+                   Y : Boolean := Foo (T'Class (X));
+               end P;
+
+3.c
+          The full view of T is not abstract, but has an abstract
+          operation Foo, which is illegal.  The two lines marked "--
+          Illegal!"  are illegal when taken together.
+
+3.d/2
+          Reason: {AI95-00310-01AI95-00310-01} We considered disallowing
+          untagged types from having abstract primitive subprograms.
+          However, we rejected that plan, because it introduced some
+          silly anomalies, and because such subprograms are harmless.
+          For example:
+
+3.e/1
+               package P is
+                  type Field_Size is range 0..100;
+                  type T is abstract tagged null record;
+                  procedure Print(X : in T; F : in Field_Size := 0) is 
abstract;
+                 . . .
+               package Q is
+                  type My_Field_Size is new Field_Size;
+                  -- implicit declaration of Print(X : T; F : My_Field_Size := 
0) is abstract;
+               end Q;
+
+3.f
+          It seemed silly to make the derivative of My_Field_Size
+          illegal, just because there was an implicitly declared
+          abstract subprogram that was not primitive on some tagged
+          type.  Other rules could be formulated to solve this problem,
+          but the current ones seem like the simplest.
+
+3.g/2
+          {AI95-00310-01AI95-00310-01} In Ada 2005, abstract primitive
+          subprograms of an untagged type may be used to "undefine" an
+          operation.
+
+3.h/2
+          Ramification: {AI95-00260-02AI95-00260-02} Note that the
+          second sentence does not apply to abstract formal subprograms,
+          as they are never primitive operations of a type.
+
+4/3
+{AI95-00251-01AI95-00251-01} {AI95-00334-01AI95-00334-01}
+{AI95-00391-01AI95-00391-01} {AI05-0097-1AI05-0097-1}
+{AI05-0198-1AI05-0198-1} If a type has an implicitly declared primitive
+subprogram that is inherited or is a predefined operator, and the
+corresponding primitive subprogram of the parent or ancestor type is
+abstract or is a function with a controlling access result, or if a type
+other than a nonabstract null extension inherits a function with a
+controlling result, then:
+
+4.a/3
+          Ramification: {AI05-0068-1AI05-0068-1} These rules apply to
+          each view of the type individually.  That is necessary to
+          preserve privacy.  For instance, in the following example:
+
+4.b/3
+               package P is
+                  type I is interface;
+                  procedure Op (X : I) is abstract;
+               end P;
+
+4.c/3
+               with P;
+               package Q is
+                  type T is abstract new P.I with private;
+                  -- Op inherited here.
+               private
+                  type T is abstract new P.I with null record;
+                  procedure Op (X : T) is null;
+               end Q;
+
+4.d/3
+               with Q;
+               package R is
+                  type T2 is new Q.T with null record;
+                  -- Illegal. Op inherited here, but requires overriding.
+               end R;
+
+4.e/3
+          If this did not depend on the view, this would be legal.  But
+          in that case, the fact that Op is overridden in the private
+          part would be visible; package R would have to be illegal if
+          no overriding was in the private part.
+
+4.f/3
+          Note that this means that whether an inherited subprogram is
+          abstract or concrete depends on where it inherited.  In the
+          case of Q, Q.Op in the visible part is abstract, while Q.Op in
+          the private part is concrete.  That is, R is illegal since it
+          is an unrelated unit (and thus it cannot see the private
+          part), but if R had been a private child of Q, it would have
+          been legal.
+
+5/2
+   * {AI95-00251-01AI95-00251-01} {AI95-00334-01AI95-00334-01} If the
+     type is abstract or untagged, the implicitly declared subprogram is
+     abstract.
+
+5.a
+          Ramification: Note that it is possible to override a concrete
+          subprogram with an abstract one.
+
+6/2
+   * {AI95-00391-01AI95-00391-01} Otherwise, the subprogram shall be
+     overridden with a nonabstract subprogram or, in the case of a
+     private extension inheriting a function with a controlling result,
+     have a full type that is a null extension[; for a type declared in
+     the visible part of a package, the overriding may be either in the
+     visible or the private part].  Such a subprogram is said to require
+     overriding.  However, if the type is a generic formal type, the
+     subprogram need not be overridden for the formal type itself; [a
+     nonabstract version will necessarily be provided by the actual
+     type.]
+
+6.a/2
+          Reason: {AI95-00228-01AI95-00228-01}
+          {AI95-00391-01AI95-00391-01} A function that returns the
+          parent type requires overriding for a type extension (or
+          becomes abstract for an abstract type) because conversion from
+          a parent type to a type extension is not defined, and function
+          return semantics is defined in terms of conversion (other than
+          for a null extension; see below).  (Note that parameters of
+          mode in out or out do not have this problem, because the tag
+          of the actual is not changed.)
+
+6.b
+          Note that the overriding required above can be in the private
+          part, which allows the following:
+
+6.c
+               package Pack1 is
+                   type Ancestor is abstract ...;
+                   procedure Do_Something(X : in Ancestor) is abstract;
+               end Pack1;
+
+6.d
+               with Pack1; use Pack1;
+               package Pack2 is
+                   type T1 is new Ancestor with record ...;
+                       -- A concrete type.
+                   procedure Do_Something(X : in T1); -- Have to override.
+               end Pack2;
+
+6.e
+               with Pack1; use Pack1;
+               with Pack2; use Pack2;
+               package Pack3 is
+                   type T2 is new Ancestor with private;
+                       -- A concrete type.
+               private
+                   type T2 is new T1 with -- Parent different from ancestor.
+                     record ... end record;
+                   -- Here, we inherit Pack2.Do_Something.
+               end Pack3;
+    
+
+6.f/2
+          {AI95-00228-01AI95-00228-01} T2 inherits an abstract
+          Do_Something, but T2 is not abstract, so Do_Something has to
+          be overridden.  However, it is OK to override it in the
+          private part.  In this case, we override it by inheriting a
+          concrete version from a different type.  Nondispatching calls
+          to Pack3.Do_Something are allowed both inside and outside
+          package Pack3, as the client "knows" that the subprogram was
+          necessarily overridden somewhere.
+
+6.g/2
+          {AI95-00391-01AI95-00391-01} For a null extension, the result
+          of a function with a controlling result is defined in terms of
+          an extension_aggregate with a null record extension part (see
+          *note 3.4::).  This means that these restrictions on functions
+          with a controlling result do not have to apply to null
+          extensions.
+
+6.h/2
+          {AI95-00391-01AI95-00391-01} However, functions with
+          controlling access results still require overriding.  Changing
+          the tag in place might clobber a preexisting object, and
+          allocating new memory would possibly change the pool of the
+          object, leading to storage leaks.  Moreover, copying the
+          object isn't possible for limited types.  We don't need to
+          restrict functions that have an access return type of an
+          untagged type, as derived types with primitive subprograms
+          have to have the same representation as their parent type.
+
+7
+A call on an abstract subprogram shall be a dispatching call;
+[nondispatching calls to an abstract subprogram are not allowed.]
+
+7.a/2
+          Ramification: {AI95-00310-01AI95-00310-01} If an abstract
+          subprogram is not a dispatching operation of some tagged type,
+          then it cannot be called at all.  In Ada 2005, such
+          subprograms are not even considered by name resolution (see
+          *note 6.4::).
+
+8/3
+{AI05-0073-1AI05-0073-1} {AI05-0203-1AI05-0203-1} The type of an
+aggregate, or of an object created by an object_declaration or an
+allocator, or a generic formal object of mode in, shall not be abstract.
+The type of the target of an assignment operation (see *note 5.2::)
+shall not be abstract.  The type of a component shall not be abstract.
+If the result type of a function is abstract, then the function shall be
+abstract.  If a function has an access result type designating an
+abstract type, then the function shall be abstract.  The type denoted by
+a return_subtype_indication (see *note 6.5::) shall not be abstract.  A
+generic function shall not have an abstract result type or an access
+result type designating an abstract type.
+
+8.a
+          Reason: This ensures that values of an abstract type cannot be
+          created, which ensures that a dispatching call to an abstract
+          subprogram will not try to execute the nonexistent body.
+
+8.b
+          Generic formal objects of mode in are like constants;
+          therefore they should be forbidden for abstract types.
+          Generic formal objects of mode in out are like renamings;
+          therefore, abstract types are OK for them, though probably not
+          terribly useful.
+
+8.c/3
+          {AI05-0073-1AI05-0073-1} Generic functions returning a formal
+          abstract type are illegal because any instance would have to
+          be instantiated with a nonabstract type in order to avoid
+          violating the function rule (generic functions cannot be
+          declared abstract).  But that would be an implied contract; it
+          would be better for the contract to be explicit by the formal
+          type not being declared abstract.  Moreover, the implied
+          contract does not add any capability.
+
+9
+If a partial view is not abstract, the corresponding full view shall not
+be abstract.  If a generic formal type is abstract, then for each
+primitive subprogram of the formal that is not abstract, the
+corresponding primitive subprogram of the actual shall not be abstract.
+
+9.a
+          Discussion: By contrast, we allow the actual type to be
+          nonabstract even if the formal type is declared abstract.
+          Hence, the most general formal tagged type possible is "type
+          T(<>) is abstract tagged limited private;".
+
+9.b
+          For an abstract private extension declared in the visible part
+          of a package, it is only possible for the full type to be
+          nonabstract if the private extension has no abstract
+          dispatching operations.
+
+9.c/2
+          To be honest: {AI95-00294-01AI95-00294-01} In the sentence
+          about primitive subprograms above, there is some ambiguity as
+          to what is meant by "corresponding" in the case where an
+          inherited operation is overridden.  This is best explained by
+          an example, where the implicit declarations are shown as
+          comments:
+
+9.d/2
+               package P1 is
+                  type T1 is abstract tagged null record;
+                  procedure P (X : T1); -- (1)
+               end P1;
+
+9.e/2
+               package P2 is
+                  type T2 is abstract new P1.T1 with null record;
+                  -- procedure P (X : T2); -- (2)
+                  procedure P (X : T2) is abstract; -- (3)
+               end P2;
+
+9.f/2
+               generic
+                  type D is abstract new P1.T1 with private;
+                  -- procedure P (X : D); -- (4)
+               procedure G (X : D);
+
+9.g/2
+               procedure I is new G (P2.T2); -- Illegal.
+
+9.h/2
+          Type T2 inherits a nonabstract procedure P (2) from the
+          primitive procedure P (1) of T1.  P (2) is overridden by the
+          explicitly declared abstract procedure P (3).  Type D inherits
+          a nonabstract procedure P (4) from P (1).  In instantiation I,
+          the operation corresponding to P (4) is the one which is not
+          overridden, that is, P (3): the overridden operation P (2)
+          does not "reemerge".  Therefore, the instantiation is illegal.
+
+10/3
+{AI05-0073-1AI05-0073-1} For an abstract type declared in a visible
+part, an abstract primitive subprogram shall not be declared in the
+private part, unless it is overriding an abstract subprogram implicitly
+declared in the visible part.  For a tagged type declared in a visible
+part, a primitive function with a controlling result or a controlling
+access result shall not be declared in the private part, unless it is
+overriding a function implicitly declared in the visible part.
+
+10.a
+          Reason: The "visible part" could be that of a package or a
+          generic package.  This rule is needed because a nonabstract
+          type extension declared outside the package would not know
+          about any abstract primitive subprograms or primitive
+          functions with controlling results declared in the private
+          part, and wouldn't know that they need to be overridden with
+          nonabstract subprograms.  The rule applies to a tagged record
+          type or record extension declared in a visible part, just as
+          to a tagged private type or private extension.  The rule
+          applies to explicitly and implicitly declared abstract
+          subprograms:
+
+10.b
+               package Pack is
+                   type T is abstract new T1 with private;
+               private
+                   type T is abstract new T2 with record ... end record;
+                   ...
+               end Pack;
+
+10.c
+          The above example would be illegal if T1 has a nonabstract
+          primitive procedure P, but T2 overrides P with an abstract
+          one; the private part should override P with a nonabstract
+          version.  On the other hand, if the P were abstract for both
+          T1 and T2, the example would be legal as is.
+
+11/2
+{AI95-00260-02AI95-00260-02} A generic actual subprogram shall not be an
+abstract subprogram unless the generic formal subprogram is declared by
+a formal_abstract_subprogram_declaration.  The prefix of an
+attribute_reference for the Access, Unchecked_Access, or Address
+attributes shall not denote an abstract subprogram.
+
+11.a
+          Ramification: An abstract_subprogram_declaration is not
+          syntactically a subprogram_declaration.  Nonetheless, an
+          abstract subprogram is a subprogram, and an
+          abstract_subprogram_declaration is a declaration of a
+          subprogram.
+
+11.b/2
+          {AI95-00260-02AI95-00260-02} The part about generic actual
+          subprograms includes those given by default.  Of course, an
+          abstract formal subprogram's actual subprogram can be
+          abstract.
+
+                          _Dynamic Semantics_
+
+11.1/2
+{AI95-00348-01AI95-00348-01} The elaboration of an
+abstract_subprogram_declaration has no effect.
+
+     NOTES
+
+12
+     79  Abstractness is not inherited; to declare an abstract type, the
+     reserved word abstract has to be used in the declaration of the
+     type extension.
+
+12.a
+          Ramification: A derived type can be abstract even if its
+          parent is not.  Similarly, an inherited concrete subprogram
+          can be overridden with an abstract subprogram.
+
+13
+     80  A class-wide type is never abstract.  Even if a class is rooted
+     at an abstract type, the class-wide type for the class is not
+     abstract, and an object of the class-wide type can be created; the
+     tag of such an object will identify some nonabstract type in the
+     class.
+
+                              _Examples_
+
+14
+Example of an abstract type representing a set of natural numbers:
+
+15
+     package Sets is
+         subtype Element_Type is Natural;
+         type Set is abstract tagged null record;
+         function Empty return Set is abstract;
+         function Union(Left, Right : Set) return Set is abstract;
+         function Intersection(Left, Right : Set) return Set is abstract;
+         function Unit_Set(Element : Element_Type) return Set is abstract;
+         procedure Take(Element : out Element_Type;
+                        From : in out Set) is abstract;
+     end Sets;
+
+     NOTES
+
+16
+     81  Notes on the example: Given the above abstract type, one could
+     then derive various (nonabstract) extensions of the type,
+     representing alternative implementations of a set.  One might use a
+     bit vector, but impose an upper bound on the largest element
+     representable, while another might use a hash table, trading off
+     space for flexibility.
+
+16.a
+          Discussion: One way to export a type from a package with some
+          components visible and some components private is as follows:
+
+16.b
+               package P is
+                   type Public_Part is abstract tagged
+                       record
+                           ...
+                       end record;
+                   type T is new Public_Part with private;
+                   ...
+               private
+                   type T is new Public_Part with
+                       record
+                           ...
+                       end record;
+               end P;
+
+16.c
+          The fact that Public_Part is abstract tells clients they have
+          to create objects of type T instead of Public_Part.  Note that
+          the public part has to come first; it would be illegal to
+          declare a private type Private_Part, and then a record
+          extension T of it, unless T were in the private part after the
+          full declaration of Private_Part, but then clients of the
+          package would not have visibility to T.
+
+                        _Extensions to Ada 95_
+
+16.d/2
+          {AI95-00391-01AI95-00391-01} It is not necessary to override
+          functions with a controlling result for a null extension.
+          This makes it easier to derive a tagged type to complete a
+          private type.
+
+                     _Wording Changes from Ada 95_
+
+16.e/2
+          {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01}
+          Updated the wording to reflect the addition of interface types
+          (see *note 3.9.4::).
+
+16.f/2
+          {AI95-00260-02AI95-00260-02} Updated the wording to reflect
+          the addition of abstract formal subprograms (see *note
+          12.6::).
+
+16.g/2
+          {AI95-00334-01AI95-00334-01} The wording of
+          shall-be-overridden was clarified so that it clearly applies
+          to abstract predefined equality.
+
+16.h/2
+          {AI95-00348-01AI95-00348-01} Moved the syntax and elaboration
+          rule for abstract_subprogram_declaration here, so the syntax
+          and most of the semantics are together (which is consistent
+          with null procedures).
+
+16.i/2
+          {AI95-00391-01AI95-00391-01} We define the term require
+          overriding to make other wording easier to understand.
+
+                   _Incompatibilities With Ada 2005_
+
+16.j/3
+          {AI05-0073-1AI05-0073-1} Correction: Added rules to eliminate
+          holes with controlling access results and generic functions
+          that return abstract types.  While these changes are
+          technically incompatible, it is unlikely that they could be
+          used in a program without violating some other rule of the use
+          of abstract types.
+
+16.k/3
+          {AI05-0097-1AI05-0097-1} Correction: Corrected a minor glitch
+          having to do with abstract null extensions.  The Ada 2005 rule
+          allowed such extensions to inherit concrete operations in some
+          rare cases.  It is unlikely that these cases exist in user
+          code.
+
+                       _Extensions to Ada 2005_
+
+16.l/3
+          {AI05-0183-1AI05-0183-1} An optional aspect_specification can
+          be used in an abstract_subprogram_declaration.  This is
+          described in *note 13.1.1::.
+
+                    _Wording Changes from Ada 2005_
+
+16.m/3
+          {AI05-0198-1AI05-0198-1} Correction: Clarified that the
+          predefined operator corresponding to an inherited abstract
+          operator is also abstract.  The Ada 2005 rules caused the
+          predefined operator and the inherited operator to override
+          each other, which is weird.  But the effect is the same either
+          way (the operator is not considered for resolution).
+
+16.n/3
+          {AI05-0203-1AI05-0203-1} Correction: Added wording to disallow
+          abstract return objects.  These were illegal in Ada 2005 by
+          other rules; the extension to support class-wide type better
+          opened a hole which has now been plugged.
+
+
+File: aarm2012.info,  Node: 3.9.4,  Prev: 3.9.3,  Up: 3.9
+
+3.9.4 Interface Types
+---------------------
+
+1/2
+{AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01} [An interface
+type is an abstract tagged type that provides a restricted form of
+multiple inheritance.  A tagged type, task type, or protected type may
+have one or more interface types as ancestors.]
+
+1.a/2
+          Glossary entry: An interface type is a form of abstract tagged
+          type which has no components or concrete operations except
+          possibly null procedures.  Interface types are used for
+          composing other interfaces and tagged types and thereby
+          provide multiple inheritance.  Only an interface type can be
+          used as a progenitor of another type.
+
+                     _Language Design Principles_
+
+1.b/2
+          {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01} The
+          rules are designed so that an interface can be used as either
+          a parent type or a progenitor type without changing the
+          meaning.  That's important so that the order that interfaces
+          are specified in a derived_type_definition is not significant.
+          In particular, we want:
+
+1.c/2
+               type Con1 is new Int1 and Int2 with null record;
+               type Con2 is new Int2 and Int1 with null record;
+
+1.d/2
+          to mean exactly the same thing.
+
+                               _Syntax_
+
+2/2
+     {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01}
+     interface_type_definition ::=
+         [limited | task | protected | synchronized] interface [and 
+     interface_list]
+
+3/2
+     {AI95-00251-01AI95-00251-01} {AI95-00419-01AI95-00419-01}
+     interface_list ::= interface_subtype_mark {and interface_
+     subtype_mark}
+
+                          _Static Semantics_
+
+4/2
+{AI95-00251-01AI95-00251-01} An interface type (also called an
+interface) is a specific abstract tagged type that is defined by an
+interface_type_definition.
+
+5/2
+{AI95-00345-01AI95-00345-01} An interface with the reserved word
+limited, task, protected, or synchronized in its definition is termed,
+respectively, a limited interface, a task interface, a protected
+interface, or a synchronized interface.  In addition, all task and
+protected interfaces are synchronized interfaces, and all synchronized
+interfaces are limited interfaces.
+
+5.a/2
+          Glossary entry: A synchronized entity is one that will work
+          safely with multiple tasks at one time.  A synchronized
+          interface can be an ancestor of a task or a protected type.
+          Such a task or protected type is called a synchronized tagged
+          type.
+
+6/2
+{AI95-00345-01AI95-00345-01} {AI95-00443-01AI95-00443-01} [A task or
+protected type derived from an interface is a tagged type.]  Such a
+tagged type is called a synchronized tagged type, as are synchronized
+interfaces and private extensions whose declaration includes the
+reserved word synchronized.
+
+6.a/2
+          Proof: The full definition of tagged types given in *note
+          3.9:: includes task and protected types derived from
+          interfaces.
+
+6.b/2
+          Ramification: The class-wide type associated with a tagged
+          task type (including a task interface type) is a task type,
+          because "task" is one of the language-defined classes of types
+          (see *note 3.2::).  However, the class-wide type associated
+          with an interface is not an interface type, as "interface" is
+          not one of the language-defined classes (as it is not closed
+          under derivation).  In this sense, "interface" is similar to
+          "abstract".  The class-wide type associated with an interface
+          is a concrete (nonabstract) indefinite tagged composite type.
+
+6.c/2
+          "Private extension" includes generic formal private
+          extensions, as explained in *note 12.5.1::.
+
+7/2
+{AI95-00345-01AI95-00345-01} A task interface is an [abstract] task
+type.  A protected interface is an [abstract] protected type.
+
+7.a/2
+          Proof: The "abstract" follows from the definition of an
+          interface type.
+
+7.b/2
+          Reason: This ensures that task operations (like abort and the
+          Terminated attribute) can be applied to a task interface type
+          and the associated class-wide type.  While there are no
+          protected type operations, we apply the same rule to protected
+          interfaces for consistency.
+
+8/2
+{AI95-00251-01AI95-00251-01} [An interface type has no components.]
+
+8.a/2
+          Proof: This follows from the syntax and the fact that
+          discriminants are not allowed for interface types.
+
+9/2
+{AI95-00419-01AI95-00419-01} An interface_subtype_mark in an
+interface_list names a progenitor subtype; its type is the progenitor
+type.  An interface type inherits user-defined primitive subprograms
+from each progenitor type in the same way that a derived type inherits
+user-defined primitive subprograms from its progenitor types (see *note
+3.4::).
+
+9.a.1/2
+          Glossary entry: A progenitor of a derived type is one of the
+          types given in the definition of the derived type other than
+          the first.  A progenitor is always an interface type.
+          Interfaces, tasks, and protected types may also have
+          progenitors.
+
+                           _Legality Rules_
+
+10/2
+{AI95-00251-01AI95-00251-01} All user-defined primitive subprograms of
+an interface type shall be abstract subprograms or null procedures.
+
+11/2
+{AI95-00251-01AI95-00251-01} The type of a subtype named in an
+interface_list shall be an interface type.
+
+12/2
+{AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01} A type derived
+from a nonlimited interface shall be nonlimited.
+
+13/2
+{AI95-00345-01AI95-00345-01} An interface derived from a task interface
+shall include the reserved word task in its definition; any other type
+derived from a task interface shall be a private extension or a task
+type declared by a task declaration (see *note 9.1::).
+
+14/2
+{AI95-00345-01AI95-00345-01} An interface derived from a protected
+interface shall include the reserved word protected in its definition;
+any other type derived from a protected interface shall be a private
+extension or a protected type declared by a protected declaration (see
+*note 9.4::).
+
+15/2
+{AI95-00345-01AI95-00345-01} An interface derived from a synchronized
+interface shall include one of the reserved words task, protected, or
+synchronized in its definition; any other type derived from a
+synchronized interface shall be a private extension, a task type
+declared by a task declaration, or a protected type declared by a
+protected declaration.
+
+15.a/2
+          Reason: We require that an interface descendant of a task,
+          protected, or synchronized interface repeat the explicit kind
+          of interface it will be, rather than simply inheriting it, so
+          that a reader is always aware of whether the interface
+          provides synchronization and whether it may be implemented
+          only by a task or protected type.  The only place where
+          inheritance of the kind of interface might be useful would be
+          in a generic if you didn't know the kind of the actual
+          interface.  However, the value of that is low because you
+          cannot implement an interface properly if you don't know
+          whether it is a task, protected, or synchronized interface.
+          Hence, we require the kind of the actual interface to match
+          the kind of the formal interface (see *note 12.5.5::).
+
+16/2
+{AI95-00345-01AI95-00345-01} No type shall be derived from both a task
+interface and a protected interface.
+
+16.a
+          Reason: This prevents a single private extension from
+          inheriting from both a task and a protected interface.  For a
+          private type, there can be no legal completion.  For a generic
+          formal derived type, there can be no possible matching type
+          (so no instantiation could be legal).  This rule provides
+          early detection of the errors.
+
+17/2
+{AI95-00251-01AI95-00251-01} In addition to the places where Legality
+Rules normally apply (see *note 12.3::), these rules apply also in the
+private part of an instance of a generic unit.
+
+17.a/3
+          Ramification: {AI05-0299-1AI05-0299-1} This paragraph is
+          intended to apply to all of the Legality Rules in this
+          subclause.  We cannot allow interface types which do not obey
+          these rules, anywhere.  Luckily, deriving from a formal type
+          (which might be an interface) is not allowed for any tagged
+          types in a generic body.  So checking in the private part of a
+          generic covers all of the cases.
+
+                          _Dynamic Semantics_
+
+18/3
+{AI95-00251-01AI95-00251-01} {AI05-0070-1AI05-0070-1} The elaboration of
+an interface_type_definition creates the interface type and its first
+subtype.
+
+18.a/3
+          Discussion: There is no other effect.  An interface_list is
+          made up of subtype_marks, which do not need to be elaborated,
+          so the interface_list does not either.  This is consistent
+          with the handling of discriminant_parts.
+
+     NOTES
+
+19/2
+     82  {AI95-00411-01AI95-00411-01} Nonlimited interface types have
+     predefined nonabstract equality operators.  These may be overridden
+     with user-defined abstract equality operators.  Such operators will
+     then require an explicit overriding for any nonabstract descendant
+     of the interface.
+
+                              _Examples_
+
+20/2
+{AI95-00433-01AI95-00433-01} Example of a limited interface and a
+synchronized interface extending it:
+
+21/2
+     type Queue is limited interface;
+     procedure Append(Q : in out Queue; Person : in Person_Name) is abstract;
+     procedure Remove_First(Q      : in out Queue;
+                            Person : out Person_Name) is abstract;
+     function Cur_Count(Q : in Queue) return Natural is abstract;
+     function Max_Count(Q : in Queue) return Natural is abstract;
+     -- See *note 3.10.1:: for Person_Name.
+
+22/3
+     {AI05-0004-1AI05-0004-1} Queue_Error : exception;
+     -- Append raises Queue_Error if Cur_Count(Q) = Max_Count(Q)
+     -- Remove_First raises Queue_Error if Cur_Count(Q) = 0
+
+23/2
+     type Synchronized_Queue is synchronized interface and Queue; -- see *note 
9.11::
+     procedure Append_Wait(Q      : in out Synchronized_Queue;
+                           Person : in Person_Name) is abstract;
+     procedure Remove_First_Wait(Q      : in out Synchronized_Queue;
+                                 Person : out Person_Name) is abstract;
+
+24/2
+     ...
+
+25/2
+     procedure Transfer(From   : in out Queue'Class;
+                        To     : in out Queue'Class;
+                        Number : in     Natural := 1) is
+        Person : Person_Name;
+     begin
+        for I in 1..Number loop
+           Remove_First(From, Person);
+           Append(To, Person);
+        end loop;
+     end Transfer;
+
+26/2
+This defines a Queue interface defining a queue of people.  (A similar
+design could be created to define any kind of queue simply by replacing
+Person_Name by an appropriate type.)  The Queue interface has four
+dispatching operations, Append, Remove_First, Cur_Count, and Max_Count.
+The body of a class-wide operation, Transfer is also shown.  Every
+nonabstract extension of Queue must provide implementations for at least
+its four dispatching operations, as they are abstract.  Any object of a
+type derived from Queue may be passed to Transfer as either the From or
+the To operand.  The two operands need not be of the same type in any
+given call.
+
+27/2
+The Synchronized_Queue interface inherits the four dispatching
+operations from Queue and adds two additional dispatching operations,
+which wait if necessary rather than raising the Queue_Error exception.
+This synchronized interface may only be implemented by a task or
+protected type, and as such ensures safe concurrent access.
+
+28/2
+{AI95-00433-01AI95-00433-01} Example use of the interface:
+
+29/3
+     {AI05-0004-1AI05-0004-1} type Fast_Food_Queue is new Queue with record 
...;
+     procedure Append(Q : in out Fast_Food_Queue; Person : in Person_Name);
+     procedure Remove_First(Q : in out Fast_Food_Queue; Person : out 
Person_Name);
+     function Cur_Count(Q : in Fast_Food_Queue) return Natural;
+     function Max_Count(Q : in Fast_Food_Queue) return Natural;
+
+30/2
+     ...
+
+31/2
+     Cashier, Counter : Fast_Food_Queue;
+
+32/2
+     ...
+     -- Add George (see *note 3.10.1::) to the cashier's queue:
+     Append (Cashier, George);
+     -- After payment, move George to the sandwich counter queue:
+     Transfer (Cashier, Counter);
+     ...
+
+33/2
+An interface such as Queue can be used directly as the parent of a new
+type (as shown here), or can be used as a progenitor when a type is
+derived.  In either case, the primitive operations of the interface are
+inherited.  For Queue, the implementation of the four inherited routines
+must be provided.  Inside the call of Transfer, calls will dispatch to
+the implementations of Append and Remove_First for type Fast_Food_Queue.
+
+34/2
+{AI95-00433-01AI95-00433-01} Example of a task interface:
+
+35/2
+     type Serial_Device is task interface;  -- see *note 9.1::
+     procedure Read (Dev : in Serial_Device; C : out Character) is abstract;
+     procedure Write(Dev : in Serial_Device; C : in  Character) is abstract;
+
+36/2
+The Serial_Device interface has two dispatching operations which are
+intended to be implemented by task entries (see 9.1).
+
+                        _Extensions to Ada 95_
+
+36.a/2
+          {AI95-00251-01AI95-00251-01} {AI95-00345-01AI95-00345-01}
+          Interface types are new.  They provide multiple inheritance of
+          interfaces, similar to the facility provided in Java and other
+          recent language designs.
+
+                    _Wording Changes from Ada 2005_
+
+36.b/3
+          {AI05-0070-1AI05-0070-1} Correction: Corrected the definition
+          of elaboration for an interface_type_definition to match that
+          of other type definitions.
+
+
+File: aarm2012.info,  Node: 3.10,  Next: 3.11,  Prev: 3.9,  Up: 3
+
+3.10 Access Types
+=================
+
+1
+A value of an access type (an access value) provides indirect access to
+the object or subprogram it designates.  Depending on its type, an
+access value can designate either subprograms, objects created by
+allocators (see *note 4.8::), or more generally aliased objects of an
+appropriate type.  
+
+1.a
+          Discussion: A name denotes an entity; an access value
+          designates an entity.  The "dereference" of an access value X,
+          written "X.all", is a name that denotes the entity designated
+          by X.
+
+                     _Language Design Principles_
+
+1.b/3
+          {AI05-0299-1AI05-0299-1} Access values should always be well
+          defined (barring uses of certain unchecked features of Clause
+          *note 13::).  In particular, uninitialized access variables
+          should be prevented by compile-time rules.
+
+                               _Syntax_
+
+2/2
+     {AI95-00231-01AI95-00231-01} access_type_definition ::=
+         [null_exclusion] access_to_object_definition
+       | [null_exclusion] access_to_subprogram_definition
+
+3
+     access_to_object_definition ::=
+         access [general_access_modifier] subtype_indication
+
+4
+     general_access_modifier ::= all | constant
+
+5
+     access_to_subprogram_definition ::=
+         access [protected] procedure parameter_profile
+       | access [protected] function  parameter_and_result_profile
+
+5.1/2
+     {AI95-00231-01AI95-00231-01} null_exclusion ::= not null
+
+6/2
+     {AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01}
+     {AI95-00404-01AI95-00404-01} access_definition ::=
+         [null_exclusion] access [constant] subtype_mark
+       | [null_exclusion] access [protected] procedure parameter_profile
+       | [null_exclusion] access [protected] function 
+     parameter_and_result_profile
+
+                          _Static Semantics_
+
+7/1
+{8652/00128652/0012} {AI95-00062-01AI95-00062-01} There are two kinds of
+access types, access-to-object types, whose values designate objects,
+and access-to-subprogram types, whose values designate subprograms.
+Associated with an access-to-object type is a storage pool; several
+access types may share the same storage pool.  All descendants of an
+access type share the same storage pool.  A storage pool is an area of
+storage used to hold dynamically allocated objects (called pool
+elements) created by allocators[; storage pools are described further in
+*note 13.11::, "*note 13.11:: Storage Management"].
+
+8
+Access-to-object types are further subdivided into pool-specific access
+types, whose values can designate only the elements of their associated
+storage pool, and general access types, whose values can designate the
+elements of any storage pool, as well as aliased objects created by
+declarations rather than allocators, and aliased subcomponents of other
+objects.
+
+8.a
+          Implementation Note: The value of an access type will
+          typically be a machine address.  However, a value of a
+          pool-specific access type can be represented as an offset (or
+          index) relative to its storage pool, since it can point only
+          to the elements of that pool.
+
+9/3
+{AI95-00225-01AI95-00225-01} {AI95-00363-01AI95-00363-01}
+{AI05-0053-1AI05-0053-1} {AI05-0142-4AI05-0142-4}
+{AI05-0277-1AI05-0277-1} A view of an object is defined to be aliased if
+it is defined by an object_declaration (*note 3.3.1: S0032.),
+component_definition (*note 3.6: S0056.), parameter_specification (*note
+6.1: S0175.), or extended_return_object_declaration with the reserved
+word aliased, or by a renaming of an aliased view.  In addition, the
+dereference of an access-to-object value denotes an aliased view, as
+does a view conversion (see *note 4.6::) of an aliased view.  The
+current instance of an immutably limited type (see *note 7.5::) is
+defined to be aliased.  Finally, a formal parameter or generic formal
+object of a tagged type is defined to be aliased.  [Aliased views are
+the ones that can be designated by an access value.]
+
+9.a
+          Glossary entry: An aliased view of an object is one that can
+          be designated by an access value.  Objects allocated by
+          allocators are aliased.  Objects can also be explicitly
+          declared as aliased with the reserved word aliased.  The
+          Access attribute can be used to create an access value
+          designating an aliased object.
+
+9.b
+          Ramification: The current instance of a nonlimited type is not
+          aliased.
+
+9.c
+          The object created by an allocator is aliased, but not its
+          subcomponents, except of course for those that themselves have
+          aliased in their component_definition.
+
+9.d
+          The renaming of an aliased object is aliased.
+
+9.e
+          Slices are never aliased.  See *note 4.1.2:: for more
+          discussion.
+
+9.f/2
+          Reason: {AI95-00225-01AI95-00225-01} The current instance of a
+          limited type is defined to be aliased so that an access
+          discriminant of a component can be initialized with T'Access
+          inside the definition of T. Note that we don't want this to
+          apply to a type that could become nonlimited later within its
+          immediate scope, so we require the full definition to be
+          limited.
+
+9.g
+          A formal parameter of a tagged type is defined to be aliased
+          so that a (tagged) parameter X may be passed to an access
+          parameter P by using P => X'Access.  Access parameters are
+          most important for tagged types because of
+          dispatching-on-access-parameters (see *note 3.9.2::).  By
+          restricting this to formal parameters, we minimize problems
+          associated with allowing components that are not declared
+          aliased to be pointed-to from within the same record.
+
+9.h
+          A view conversion of an aliased view is aliased so that the
+          type of an access parameter can be changed without first
+          converting to a named access type.  For example:
+
+9.i
+               type T1 is tagged ...;
+               procedure P(X : access T1);
+
+9.j
+               type T2 is new T1 with ...;
+               procedure P(X : access T2) is
+               begin
+                   P(T1(X.all)'Access);  -- hand off to T1's P
+                   . . .     -- now do extra T2-specific processing
+               end P;
+
+9.k/2
+          This paragraph was deleted.{AI95-00363-01AI95-00363-01}
+
+9.l/2
+          We considered making more kinds of objects aliased by default.
+          In particular, any object of a by-reference type will pretty
+          much have to be allocated at an addressable location, so it
+          can be passed by reference without using bit-field pointers.
+          Therefore, one might wish to allow the Access and
+          Unchecked_Access attributes for such objects.  However,
+          private parts are transparent to the definition of
+          "by-reference type", so if we made all objects of a
+          by-reference type aliased, we would be violating the privacy
+          of private parts.  Instead, we would have to define a concept
+          of "visibly by-reference" and base the rule on that.  This
+          seemed to complicate the rules more than it was worth,
+          especially since there is no way to declare an untagged
+          limited private type to be by-reference, since the full type
+          might by nonlimited.
+
+9.m
+          Discussion: Note that we do not use the term "aliased" to
+          refer to formal parameters that are referenced through
+          multiple access paths (see *note 6.2::).
+
+10
+An access_to_object_definition defines an access-to-object type and its
+first subtype; the subtype_indication (*note 3.2.2: S0027.) defines the
+designated subtype of the access type.  If a general_access_modifier
+(*note 3.10: S0081.) appears, then the access type is a general access
+type.  If the modifier is the reserved word constant, then the type is
+an access-to-constant type[; a designated object cannot be updated
+through a value of such a type].  If the modifier is the reserved word
+all, then the type is an access-to-variable type[; a designated object
+can be both read and updated through a value of such a type].  If no
+general_access_modifier (*note 3.10: S0081.) appears in the
+access_to_object_definition (*note 3.10: S0080.), the access type is a
+pool-specific access-to-variable type.
+
+10.a
+          To be honest: The type of the designated subtype is called the
+          designated type.
+
+10.b
+          Reason: The modifier all was picked to suggest that values of
+          a general access type could point into "all" storage pools, as
+          well as to objects declared aliased, and that "all" access
+          (both read and update) to the designated object was provided.
+          We couldn't think of any use for pool-specific
+          access-to-constant types, so any access type defined with the
+          modifier constant is considered a general access type, and can
+          point into any storage pool or at other (appropriate) aliased
+          objects.
+
+10.c
+          Implementation Note: The predefined generic
+          Unchecked_Deallocation can be instantiated for any named
+          access-to-variable type.  There is no (language-defined)
+          support for deallocating objects designated by a value of an
+          access-to-constant type.  Because of this, an allocator for an
+          access-to-constant type can allocate out of a storage pool
+          with no support for deallocation.  Frequently, the allocation
+          can be done at link-time, if the size and initial value are
+          known then.
+
+10.d
+          Discussion: For the purpose of generic formal type matching,
+          the relevant subclasses of access types are
+          access-to-subprogram types, access-to-constant types, and
+          (named) access-to-variable types, with its subclass (named)
+          general access-to-variable types.  Pool-specific
+          access-to-variable types are not a separately matchable
+          subclass of types, since they don't have any "extra"
+          operations relative to all (named) access-to-variable types.
+
+11
+An access_to_subprogram_definition defines an access-to-subprogram type
+and its first subtype; the parameter_profile or
+parameter_and_result_profile defines the designated profile of the
+access type.  There is a calling convention associated with the
+designated profile[; only subprograms with this calling convention can
+be designated by values of the access type.]  By default, the calling
+convention is "protected" if the reserved word protected appears, and
+"Ada" otherwise.  [See *note Annex B:: for how to override this
+default.]
+
+11.a
+          Ramification: The calling convention protected is in italics
+          to emphasize that it cannot be specified explicitly by the
+          user.  This is a consequence of it being a reserved word.
+
+11.b/2
+          Implementation Note: {AI95-00254-01AI95-00254-01} For a named
+          access-to-subprogram type, the representation of an access
+          value might include implementation-defined information needed
+          to support up-level references -- for example, a static link.
+          The accessibility rules (see *note 3.10.2::) ensure that in a
+          "global-display-based" implementation model (as opposed to a
+          static-link-based model), a named
+          access-to-(unprotected)-subprogram value need consist only of
+          the address of the subprogram.  The global display is
+          guaranteed to be properly set up any time the designated
+          subprogram is called.  Even in a static-link-based model, the
+          only time a static link is definitely required is for an
+          access-to-subprogram type declared in a scope nested at least
+          two levels deep within subprogram or task bodies, since values
+          of such a type might designate subprograms nested a smaller
+          number of levels.  For the normal case of a named
+          access-to-subprogram type declared at the outermost (library)
+          level, a code address by itself should be sufficient to
+          represent the access value in many implementations.
+
+11.c
+          For access-to-protected-subprogram, the access values will
+          necessarily include both an address (or other identification)
+          of the code of the subprogram, as well as the address of the
+          associated protected object.  This could be thought of as a
+          static link, but it will be needed even for
+          global-display-based implementation models.  It corresponds to
+          the value of the "implicit parameter" that is passed into
+          every call of a protected operation, to identify the current
+          instance of the protected type on which they are to operate.
+
+11.d
+          Any Elaboration_Check is performed when a call is made through
+          an access value, rather than when the access value is first
+          "created" via a 'Access.  For implementation models that
+          normally put that check at the call-site, an access value will
+          have to point to a separate entry point that does the check.
+          Alternatively, the access value could point to a "subprogram
+          descriptor" that consisted of two words (or perhaps more), the
+          first being the address of the code, the second being the
+          elaboration bit.  Or perhaps more efficiently, just the
+          address of the code, but using the trick that the descriptor
+          is initialized to point to a Raise-Program-Error routine
+          initially, and then set to point to the "real" code when the
+          body is elaborated.
+
+11.e
+          For implementations that share code between generic
+          instantiations, the extra level of indirection suggested above
+          to support Elaboration_Checks could also be used to provide a
+          pointer to the per-instance data area normally required when
+          calling shared code.  The trick would be to put a pointer to
+          the per-instance data area into the subprogram descriptor, and
+          then make sure that the address of the subprogram descriptor
+          is loaded into a "known" register whenever an indirect call is
+          performed.  Once inside the shared code, the address of the
+          per-instance data area can be retrieved out of the subprogram
+          descriptor, by indexing off the "known" register.
+
+11.f/2
+          This paragraph was deleted.{AI95-00344-01AI95-00344-01}
+
+11.g/2
+          {AI95-00254-01AI95-00254-01} Note that access parameters of an
+          anonymous access-to-subprogram type are permitted.  Such
+          parameters represent full "downward" closures, meaning that in
+          an implementation that uses a per-task (global) display, the
+          display will have to be passed as a hidden parameter, and
+          reconstructed at the point of call.
+
+12/3
+{AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01}
+{AI95-00254-01AI95-00254-01} {AI05-0264-1AI05-0264-1} An
+access_definition defines an anonymous general access type or an
+anonymous access-to-subprogram type.  For a general access type, the
+subtype_mark denotes its designated subtype; if the
+general_access_modifier (*note 3.10: S0081.) constant appears, the type
+is an access-to-constant type; otherwise, it is an access-to-variable
+type.  For an access-to-subprogram type, the parameter_profile (*note
+6.1: S0172.) or parameter_and_result_profile (*note 6.1: S0173.) denotes
+its designated profile.
+
+13/2
+{AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01} For each
+access type, there is a null access value designating no entity at all,
+which can be obtained by (implicitly) converting the literal null to the
+access type.  [The null value of an access type is the default initial
+value of the type.]  Nonnull values of an access-to-object type are
+obtained by evaluating an allocator[, which returns an access value
+designating a newly created object (see *note 3.10.2::)], or in the case
+of a general access-to-object type, evaluating an attribute_reference
+for the Access or Unchecked_Access attribute of an aliased view of an
+object.  Nonnull values of an access-to-subprogram type are obtained by
+evaluating an attribute_reference for the Access attribute of a
+nonintrinsic subprogram.
+
+13.a/2
+          This paragraph was deleted.{AI95-00231-01AI95-00231-01}
+
+13.b/2
+          This paragraph was deleted.{AI95-00231-01AI95-00231-01}
+
+13.1/2
+{AI95-00231-01AI95-00231-01} A null_exclusion in a construct specifies
+that the null value does not belong to the access subtype defined by the
+construct, that is, the access subtype excludes null.  In addition, the
+anonymous access subtype defined by the access_definition for a
+controlling access parameter (see *note 3.9.2::) excludes null.
+Finally, for a subtype_indication without a null_exclusion, the subtype
+denoted by the subtype_indication excludes null if and only if the
+subtype denoted by the subtype_mark in the subtype_indication excludes
+null.
+
+13.c/2
+          Reason: {AI95-00231-01AI95-00231-01} An access_definition used
+          in a controlling parameter excludes null because it is
+          necessary to read the tag to dispatch, and null has no tag.
+          We would have preferred to require not null to be specified
+          for such parameters, but that would have been too incompatible
+          with Ada 95 code to require.
+
+13.d/2
+          {AI95-00416-01AI95-00416-01} Note that we considered imposing
+          a similar implicit null exclusion for controlling access
+          results, but chose not to do that, because there is no Ada 95
+          compatibility issue, and there is no automatic null check
+          inherent in the use of a controlling access result.  If a null
+          check is necessary, it is because there is a dereference of
+          the result, or because the value is passed to a parameter
+          whose subtype excludes null.  If there is no dereference of
+          the result, a null return value is perfectly acceptable, and
+          can be a useful indication of a particular status of the call.
+
+14/3
+{8652/00138652/0013} {AI95-00012-01AI95-00012-01}
+{AI05-0264-1AI05-0264-1} [All subtypes of an access-to-subprogram type
+are constrained.]  The first subtype of a type defined by an
+access_definition or an access_to_object_definition is unconstrained if
+the designated subtype is an unconstrained array or discriminated
+subtype; otherwise, it is constrained.
+
+14.a
+          Proof: The Legality Rules on range_constraints (see *note
+          3.5::) do not permit the subtype_mark of the
+          subtype_indication to denote an access-to-scalar type, only a
+          scalar type.  The Legality Rules on index_constraints (see
+          *note 3.6.1::) and discriminant_constraints (see *note
+          3.7.1::) both permit access-to-composite types in a
+          subtype_indication with such _constraints.  Note that an
+          access-to-access-to-composite is never permitted in a
+          subtype_indication with a constraint.
+
+14.b/2
+          Reason: {AI95-00363-01AI95-00363-01} Only
+          composite_constraints are permitted for an access type, and
+          only on access-to-composite types.  A constraint on an
+          access-to-scalar or access-to-access type might be violated
+          due to assignments via other access paths that were not so
+          constrained.  By contrast, if the designated subtype is an
+          array or discriminated type without defaults, the constraint
+          could not be violated by unconstrained assignments, since
+          array objects are always constrained, and discriminated
+          objects are also constrained when the type does not have
+          defaults for its discriminants.  Constraints are not allowed
+          on general access-to-unconstrained discriminated types if the
+          type has defaults for its discriminants; constraints on
+          pool-specific access types are usually allowed because
+          allocated objects are usually constrained by their initial
+          value.
+
+                           _Legality Rules_
+
+14.1/2
+{AI95-00231-01AI95-00231-01} If a subtype_indication (*note 3.2.2:
+S0027.), discriminant_specification (*note 3.7: S0062.),
+parameter_specification (*note 6.1: S0175.),
+parameter_and_result_profile (*note 6.1: S0173.),
+object_renaming_declaration (*note 8.5.1: S0200.), or
+formal_object_declaration (*note 12.4: S0279.) has a null_exclusion
+(*note 3.10: S0083.), the subtype_mark (*note 3.2.2: S0028.) in that
+construct shall denote an access subtype that does not exclude null.
+
+14.c/2
+          To be honest: {AI95-00231-01AI95-00231-01} This means
+          "directly allowed in"; we are not talking about a
+          null_exclusion that occurs in an access_definition in one of
+          these constructs (for an access_definition, the subtype_mark
+          in such an access_definition is not restricted).
+
+14.d/2
+          Reason: {AI95-00231-01AI95-00231-01} This is similar to doubly
+          constraining a composite subtype, which we also don't allow.
+
+                          _Dynamic Semantics_
+
+15/2
+{AI95-00231-01AI95-00231-01} A composite_constraint is compatible with
+an unconstrained access subtype if it is compatible with the designated
+subtype.  A null_exclusion is compatible with any access subtype that
+does not exclude null.  An access value satisfies a composite_constraint
+of an access subtype if it equals the null value of its type or if it
+designates an object whose value satisfies the constraint.  An access
+value satisfies an exclusion of the null value if it does not equal the
+null value of its type.
+
+16
+The elaboration of an access_type_definition creates the access type and
+its first subtype.  For an access-to-object type, this elaboration
+includes the elaboration of the subtype_indication, which creates the
+designated subtype.
+
+17/2
+{AI95-00230-01AI95-00230-01} {AI95-00254-01AI95-00254-01} The
+elaboration of an access_definition creates an anonymous access type.
+
+     NOTES
+
+18
+     83  Access values are called "pointers" or "references" in some
+     other languages.
+
+19
+     84  Each access-to-object type has an associated storage pool;
+     several access types can share the same pool.  An object can be
+     created in the storage pool of an access type by an allocator (see
+     *note 4.8::) for the access type.  A storage pool (roughly)
+     corresponds to what some other languages call a "heap."  See *note
+     13.11:: for a discussion of pools.
+
+20
+     85  Only index_constraints and discriminant_constraints can be
+     applied to access types (see *note 3.6.1:: and *note 3.7.1::).
+
+                              _Examples_
+
+21
+Examples of access-to-object types:
+
+22/2
+     {AI95-00433-01AI95-00433-01} type Peripheral_Ref is not null access 
Peripheral;  --  see *note 3.8.1::
+     type Binop_Ptr is access all Binary_Operation'Class;
+                                                -- general 
access-to-class-wide, see *note 3.9.1::
+
+23
+Example of an access subtype:
+
+24
+     subtype Drum_Ref is Peripheral_Ref(Drum);  --  see *note 3.8.1::
+
+25
+Example of an access-to-subprogram type:
+
+26
+     type Message_Procedure is access procedure (M : in String := "Error!");
+     procedure Default_Message_Procedure(M : in String);
+     Give_Message : Message_Procedure := Default_Message_Procedure'Access;
+     ...
+     procedure Other_Procedure(M : in String);
+     ...
+     Give_Message := Other_Procedure'Access;
+     ...
+     Give_Message("File not found.");  -- call with parameter (.all is 
optional)
+     Give_Message.all;                 -- call with no parameters
+
+                        _Extensions to Ada 83_
+
+26.a
+          The syntax for access_type_definition is changed to support
+          general access types (including access-to-constants) and
+          access-to-subprograms.  The syntax rules for
+          general_access_modifier and access_definition are new.
+
+                     _Wording Changes from Ada 83_
+
+26.b/3
+          {AI05-0190-1AI05-0190-1} We use the term "storage pool" to
+          talk about the data area from which allocation takes place.
+          The term "collection" is only used for finalization.
+          ("Collection" and "storage pool" are not the same thing
+          because multiple unrelated access types can share the same
+          storage pool; see *note 13.11:: for more discussion.)
+
+                     _Inconsistencies With Ada 95_
+
+26.c/2
+          {AI95-00231-01AI95-00231-01} Access discriminants and
+          noncontrolling access parameters no longer exclude null.  A
+          program which passed null to such an access discriminant or
+          access parameter and expected it to raise Constraint_Error may
+          fail when compiled with Ada 2005.  One hopes that there no
+          such programs outside of the ACATS. (Of course, a program
+          which actually wants to pass null will work, which is far more
+          likely.)
+
+26.d/2
+          {AI95-00363-01AI95-00363-01} Most unconstrained aliased
+          objects with defaulted discriminants are no longer constrained
+          by their initial values.  This means that a program that
+          raised Constraint_Error from an attempt to change the
+          discriminants will no longer do so.  The change only affects
+          programs that depended on the raising of Constraint_Error in
+          this case, so the inconsistency is unlikely to occur outside
+          of the ACATS. This change may however cause compilers to
+          implement these objects differently, possibly taking
+          additional memory or time.  This is unlikely to be worse than
+          the differences caused by any major compiler upgrade.
+
+                    _Incompatibilities With Ada 95_
+
+26.e/2
+          {AI95-00225-01AI95-00225-01} Amendment Correction: The rule
+          defining when a current instance of a limited type is
+          considered to be aliased has been tightened to apply only to
+          types that cannot become nonlimited.  A program that attempts
+          to take 'Access of the current instance of a limited type that
+          can become nonlimited will be illegal in Ada 2005.  While
+          original Ada 95 allowed the current instance of any limited
+          type to be treated as aliased, this was inconsistently
+          implemented in compilers, and was likely to not work as
+          expected for types that are ultimately nonlimited.
+
+                        _Extensions to Ada 95_
+
+26.f/2
+          {AI95-00231-01AI95-00231-01} The null_exclusion is new.  It
+          can be used in both anonymous and named access type
+          definitions.  It is most useful to declare that parameters
+          cannot be null, thus eliminating the need for checks on use.
+
+26.g/2
+          {AI95-00231-01AI95-00231-01} {AI95-00254-01AI95-00254-01}
+          {AI95-00404-01AI95-00404-01} The kinds of anonymous access
+          types allowed were increased by adding anonymous
+          access-to-constant and anonymous access-to-subprogram types.
+          Anonymous access-to-subprogram types used as parameters allow
+          passing of subprograms at any level.
+
+                     _Wording Changes from Ada 95_
+
+26.h/2
+          {8652/00128652/0012} {AI95-00062-01AI95-00062-01} Corrigendum:
+          Added accidentally-omitted wording that says that a derived
+          access type shares its storage pool with its parent type.
+          This was clearly intended, both because of a note in *note
+          3.4::, and because anything else would have been incompatible
+          with Ada 83.
+
+26.i/2
+          {8652/00138652/0013} {AI95-00012-01AI95-00012-01} Corrigendum:
+          Fixed typographical errors in the description of when access
+          types are constrained.
+
+26.j/2
+          {AI95-00230-01AI95-00230-01} The wording was fixed to allow
+          allocators and the literal null for anonymous access types.
+          The former was clearly intended by Ada 95; see the
+          Implementation Advice in *note 13.11::.
+
+26.k/2
+          {AI95-00363-01AI95-00363-01} The rules about aliased objects
+          being constrained by their initial values now apply only to
+          allocated objects, and thus have been moved to *note 4.8::,
+          "*note 4.8:: Allocators".
+
+                    _Wording Changes from Ada 2005_
+
+26.l/3
+          {AI05-0053-1AI05-0053-1} {AI05-0277-1AI05-0277-1} Correction:
+          The rule about a current instance being aliased now is worded
+          in terms of immutably limited types.  Wording was also added
+          to make extended return object declarations that have the
+          keyword aliased be considered aliased.  This latter was a
+          significant oversight in Ada 2005 -- technically, the keyword
+          aliased had no effect.  But of course implementations followed
+          the intent, not the letter of the Standard.
+
+26.m/3
+          {AI05-0142-4AI05-0142-4} Explicitly aliased parameters (see
+          *note 6.1::) are defined to be aliased.
+
+* Menu:
+
+* 3.10.1 ::   Incomplete Type Declarations
+* 3.10.2 ::   Operations of Access Types
+
+
+File: aarm2012.info,  Node: 3.10.1,  Next: 3.10.2,  Up: 3.10
+
+3.10.1 Incomplete Type Declarations
+-----------------------------------
+
+1
+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.  An
+incomplete_type_declaration can be used to introduce a type to be used
+as a designated type, while deferring its full definition to a
+subsequent full_type_declaration.
+
+                               _Syntax_
+
+2/2
+     {AI95-00326-01AI95-00326-01} incomplete_type_declaration ::= type 
+     defining_identifier [discriminant_part] [is tagged];
+
+                          _Static Semantics_
+
+2.1/2
+{AI95-00326-01AI95-00326-01} An incomplete_type_declaration declares an
+incomplete view of a type and its first subtype; the first subtype is
+unconstrained if a discriminant_part appears.  If the
+incomplete_type_declaration (*note 3.10.1: S0085.) includes the reserved
+word tagged, it declares a tagged incomplete view.  [An incomplete view
+of a type is a limited view of the type (see *note 7.5::).]
+
+2.2/2
+{AI95-00326-01AI95-00326-01} Given an access type A whose designated
+type T is an incomplete view, a dereference of a value of type A also
+has this incomplete view except when:
+
+2.a/3
+          Discussion: {AI05-0208-1AI05-0208-1} Whether the designated
+          type is an incomplete view (and thus whether this set of rules
+          applies) is determined by the view of the type at the
+          declaration of the access type; it does not change during the
+          life of the type.
+
+2.3/2
+   * it occurs within the immediate scope of the completion of T, or
+
+2.4/3
+   * {AI05-0208-1AI05-0208-1} it occurs within the scope of a
+     nonlimited_with_clause that mentions a library package in whose
+     visible part the completion of T is declared, or
+
+2.5/3
+   * {AI05-0208-1AI05-0208-1} it occurs within the scope of the
+     completion of T and T is an incomplete view declared by an
+     incomplete_type_declaration.
+
+2.6/3
+{AI05-0162-1AI05-0162-1} In these cases, the dereference has the view of
+T visible at the point of the dereference.
+
+2.b/2
+          Discussion: We need the "in whose visible part" rule so that
+          the second rule doesn't trigger in the body of a package with
+          a with of a child unit:
+
+2.c/2
+               package P is
+               private
+                  type T;
+                  type PtrT is access T;
+               end P;
+
+2.d/2
+               private package P.C is
+                  Ptr : PtrT;
+               end P.C;
+
+2.e/3
+               {AI05-0005-1AI05-0005-1} with P.C;
+               package body P is
+                   -- Ptr.all'Size is not legal here, but we are within the 
scope
+                   -- of a nonlimited_with_clause for P.
+               type T is ...
+                   --  Ptr.all'Size is legal here.
+               end P;
+
+2.7/3
+{AI95-00412-01AI95-00412-01} {AI05-0162-1AI05-0162-1}
+{AI05-0208-1AI05-0208-1} Similarly, if a subtype_mark denotes a
+subtype_declaration defining a subtype of an incomplete view T, the
+subtype_mark denotes an incomplete view except under the same three
+circumstances given above, in which case it denotes the view of T
+visible at the point of the subtype_mark.
+
+                           _Legality Rules_
+
+3/3
+{AI05-0162-1AI05-0162-1} An incomplete_type_declaration (*note 3.10.1:
+S0085.) requires a completion, which shall be a type_declaration (*note
+3.2.1: S0023.) other than an incomplete_type_declaration (*note 3.10.1:
+S0085.).  [If the incomplete_type_declaration (*note 3.10.1: S0085.)
+occurs immediately within either the visible part of a
+package_specification (*note 7.1: S0191.) or a declarative_part (*note
+3.11: S0086.), then the type_declaration (*note 3.2.1: S0023.) shall
+occur later and immediately within this visible part or declarative_part
+(*note 3.11: S0086.).  If the incomplete_type_declaration (*note 3.10.1:
+S0085.) occurs immediately within the private part of a given
+package_specification (*note 7.1: S0191.), then the type_declaration
+(*note 3.2.1: S0023.) shall occur later and immediately within either
+the private part itself, or the declarative_part (*note 3.11: S0086.) of
+the corresponding package_body (*note 7.2: S0192.).]
+
+3.a
+          Proof: This is implied by the next AARM-only rule, plus the
+          rules in *note 3.11.1::, "*note 3.11.1:: Completions of
+          Declarations" which require a completion to appear later and
+          immediately within the same declarative region.
+
+3.b
+          To be honest: If the incomplete_type_declaration occurs
+          immediately within the visible part of a
+          package_specification, then the completing type_declaration
+          (*note 3.2.1: S0023.) shall occur immediately within this
+          visible part.
+
+3.c
+          To be honest: If the implementation supports it, an
+          incomplete_type_declaration can be imported (using aspect
+          Import, see *note B.1::), in which case no explicit completion
+          is allowed.
+
+4/3
+{AI95-00326-01AI95-00326-01} {AI05-0162-1AI05-0162-1} If an
+incomplete_type_declaration (*note 3.10.1: S0085.) includes the reserved
+word tagged, then a type_declaration (*note 3.2.1: S0023.) that
+completes it shall declare a tagged type.  If an
+incomplete_type_declaration (*note 3.10.1: S0085.) has a
+known_discriminant_part (*note 3.7: S0061.), then a type_declaration
+(*note 3.2.1: S0023.) that completes it shall have a fully conforming
+(explicit) known_discriminant_part (*note 3.7: S0061.) (see *note
+6.3.1::).  [If an incomplete_type_declaration (*note 3.10.1: S0085.) has
+no discriminant_part (or an unknown_discriminant_part (*note 3.7:
+S0060.)), then a corresponding type_declaration (*note 3.2.1: S0023.) is
+nevertheless allowed to have discriminants, either explicitly, or
+inherited via derivation.]
+
+5/2
+{AI95-00326-01AI95-00326-01} A name that denotes an incomplete view of a
+type may be used as follows:
+
+6/3
+   * {AI05-0098-1AI05-0098-1} as the subtype_mark in the
+     subtype_indication of an access_to_object_definition (*note 3.10:
+     S0080.); [the only form of constraint allowed in this
+     subtype_indication is a discriminant_constraint [(a null_exclusion
+     is not allowed)];]
+
+6.a
+          Implementation Note: We now allow discriminant_constraints
+          even if the full type is deferred to the package body.
+          However, there is no particular implementation burden because
+          we have dropped the concept of the dependent compatibility
+          check.  In other words, we have effectively repealed
+          AI83-00007.
+
+7/2
+   * {AI95-00326-01AI95-00326-01} {AI95-00412-01AI95-00412-01} as the
+     subtype_mark in the subtype_indication of a subtype_declaration;
+     the subtype_indication (*note 3.2.2: S0027.) shall not have a
+     null_exclusion (*note 3.10: S0083.) or a constraint;
+
+8/3
+   * {AI95-00326-01AI95-00326-01} {AI05-0151-1AI05-0151-1} as the
+     subtype_mark in an access_definition for an access-to-object type;
+
+8.a/2
+          To be honest: This does not mean any random subtype_mark in a
+          construct that makes up an access_definition, such as a
+          formal_part, just the one given directly in the syntax of
+          access_definition.
+
+8.1/3
+   * {AI05-0151-1AI05-0151-1} as the subtype_mark defining the subtype
+     of a parameter or result in a profile occurring within a
+     basic_declaration;
+
+8.b/3
+          Ramification: But not in the profile for a body or entry.
+
+8.2/3
+   * {AI05-0213-1AI05-0213-1} as a generic actual parameter whose
+     corresponding generic formal parameter is a formal incomplete type
+     (see *note 12.5.1::).
+
+8.3/2
+{AI95-00326-01AI95-00326-01} If such a name denotes a tagged incomplete
+view, it may also be used:
+
+8.4/3
+   * {AI95-00326-01AI95-00326-01} {AI05-0151-1AI05-0151-1} as the
+     subtype_mark defining the subtype of a parameter in the profile for
+     a subprogram_body, entry_body, or accept_statement;
+
+9/2
+   * {AI95-00326-01AI95-00326-01} as the prefix of an
+     attribute_reference whose attribute_designator (*note 4.1.4:
+     S0101.) is Class; such an attribute_reference (*note 4.1.4: S0100.)
+     is restricted to the uses allowed here; it denotes a tagged
+     incomplete view.
+
+9.a/2
+          This paragraph was deleted.{AI95-00326-01AI95-00326-01}
+
+9.1/3
+This paragraph was deleted.{AI95-00326-01AI95-00326-01}
+{AI05-0151-1AI05-0151-1}
+
+9.2/3
+   * This paragraph was deleted.{AI95-00326-01AI95-00326-01}
+     {AI05-0098-1AI05-0098-1} {AI05-0151-1AI05-0151-1}
+
+9.b/3
+          This paragraph was deleted.
+
+9.3/2
+{AI95-00326-01AI95-00326-01} If any of the above uses occurs as part of
+the declaration of a primitive subprogram of the incomplete view, and
+the declaration occurs immediately within the private part of a package,
+then the completion of the incomplete view shall also occur immediately
+within the private part; it shall not be deferred to the package body.
+
+9.c/2
+          Reason: This fixes a hole in Ada 95 where a dispatching
+          operation with an access parameter could be declared in a
+          private part and a dispatching call on it could occur in a
+          child even though there is no visibility on the full type,
+          requiring access to the controlling tag without access to the
+          representation of the type.
+
+9.4/2
+{AI95-00326-01AI95-00326-01} No other uses of a name that denotes an
+incomplete view of a type are allowed.
+
+10/3
+{AI95-00326-01AI95-00326-01} {AI05-0151-1AI05-0151-1} A prefix that
+denotes an object shall not be of an incomplete view.  An actual
+parameter in a call shall not be of an untagged incomplete view.  The
+result object of a function call shall not be of an incomplete view.  A
+prefix shall not denote a subprogram having a formal parameter of an
+untagged incomplete view, nor a return type that is an incomplete view.
+
+10.a/2
+          Reason: We used to disallow all dereferences of an incomplete
+          type.  Now we only disallow such dereferences when used as a
+          prefix.  Dereferences used in other contexts do not pose a
+          problem since normal type matching will preclude their use
+          except when the full type is "nearby" as context (for example,
+          as the expected type).
+
+10.b/2
+          This also disallows prefixes that are directly of an
+          incomplete view.  For instance, a parameter P can be declared
+          of a tagged incomplete type, but we don't want to allow
+          P'Size, P'Alignment, or the like, as representation values
+          aren't known for an incomplete view.
+
+10.c/2
+          We say "denotes an object" so that prefixes that directly name
+          an incomplete view are not covered; the previous rules cover
+          such cases, and we certainly don't want to ban Incomp'Class.
+
+10.d/3
+          {AI05-0151-1AI05-0151-1} As subprogram profiles now may
+          include any kind of incomplete type, we also disallow passing
+          objects of untagged incomplete types in subprogram calls (as
+          the parameter passing method is not known as it is for tagged
+          types) and disallow returning any sort of incomplete objects
+          (since we don't know how big they are).
+
+Paragraph 11 was deleted.
+
+                          _Dynamic Semantics_
+
+12
+The elaboration of an incomplete_type_declaration has no effect.
+
+12.a
+          Reason: An incomplete type has no real existence, so it
+          doesn't need to be "created" in the usual sense we do for
+          other types.  It is roughly equivalent to a "forward;"
+          declaration in Pascal.  Private types are different, because
+          they have a different set of characteristics from their full
+          type.
+
+     NOTES
+
+13
+     86  Within a declarative_part, an incomplete_type_declaration and a
+     corresponding full_type_declaration cannot be separated by an
+     intervening body.  This is because a type has to be completely
+     defined before it is frozen, and a body freezes all types declared
+     prior to it in the same declarative_part (see *note 13.14::).
+
+13.1/3
+     87  {AI05-0151-1AI05-0151-1} {AI05-0269-1AI05-0269-1} A name that
+     denotes an object of an incomplete view is defined to be of a
+     limited type.  Hence, the target of an assignment statement cannot
+     be of an incomplete view.
+
+                              _Examples_
+
+14
+Example of a recursive type:
+
+15
+     type Cell;  --  incomplete type declaration
+     type Link is access Cell;
+
+16
+     type Cell is
+        record
+           Value  : Integer;
+           Succ   : Link;
+           Pred   : Link;
+        end record;
+
+17
+     Head   : Link  := new Cell'(0, null, null);
+     Next   : Link  := Head.Succ;
+
+18
+Examples of mutually dependent access types:
+
+19/2
+     {AI95-00433-01AI95-00433-01} type Person(<>);    -- incomplete type 
declaration
+     type Car is tagged; -- incomplete type declaration
+
+20/2
+     {AI95-00433-01AI95-00433-01} type Person_Name is access Person;
+     type Car_Name    is access all Car'Class;
+
+21/2
+     {AI95-00433-01AI95-00433-01} type Car is tagged
+        record
+           Number  : Integer;
+           Owner   : Person_Name;
+        end record;
+
+22
+     type Person(Sex : Gender) is
+        record
+           Name     : String(1 .. 20);
+           Birth    : Date;
+           Age      : Integer range 0 .. 130;
+           Vehicle  : Car_Name;
+           case Sex is
+              when M => Wife           : Person_Name(Sex => F);
+              when F => Husband        : Person_Name(Sex => M);
+           end case;
+        end record;
+
+23
+     My_Car, Your_Car, Next_Car : Car_Name := new Car;  -- see *note 4.8::
+     George : Person_Name := new Person(M);
+        ...
+     George.Vehicle := Your_Car;
+
+                        _Extensions to Ada 83_
+
+23.a
+          The full_type_declaration that completes an
+          incomplete_type_declaration may have a known_discriminant_part
+          even if the incomplete_type_declaration does not.
+
+23.b/1
+          A discriminant_constraint may be applied to an incomplete
+          type, even if its completion is deferred to the package body,
+          because there is no "dependent compatibility check" required
+          any more.  Of course, the constraint can be specified only if
+          a known_discriminant_part was given in the
+          incomplete_type_declaration.  As mentioned in the previous
+          paragraph, that is no longer required even when the full type
+          has discriminants.
+
+                     _Wording Changes from Ada 83_
+
+23.c
+          Dereferences producing incomplete types were not explicitly
+          disallowed in RM83, though AI83-00039 indicated that it was
+          not strictly necessary since troublesome cases would result in
+          Constraint_Error at run time, since the access value would
+          necessarily be null.  However, this introduces an undesirable
+          implementation burden, as illustrated by Example 4 of
+          AI83-00039:
+
+23.d
+               package Pack is
+                   type Pri is private;
+               private
+                   type Sep;
+                   type Pri is access Sep;
+                   X : Pri;
+               end Pack;
+
+23.e
+               package body Pack is -- Could be separately compiled!
+                   type Sep is ...;
+                   X := new Sep;
+               end Pack;
+
+23.f
+               pragma Elaborate(Pack);
+               private package Pack.Child is
+                   I : Integer := X.all'Size; -- Legal, by AI-00039.
+               end Pack.Child;
+
+23.g
+          Generating code for the above example could be a serious
+          implementation burden, since it would require all aliased
+          objects to store size dope, and for that dope to be in the
+          same format for all kinds of types (or some other equivalently
+          inefficient implementation).  On the contrary, most
+          implementations allocate dope differently (or not at all) for
+          different designated subtypes.
+
+                    _Incompatibilities With Ada 95_
+
+23.h/2
+          {AI95-00326-01AI95-00326-01} It is now illegal to use an
+          incomplete view (type) as the parameter or result of an
+          access-to-subprogram type unless the incomplete view is
+          completed in the same declaration list as the use.  This was
+          allowed in Ada 95 for incomplete types where the completion
+          was deferred to the body.  By disallowing this rare use of
+          incomplete views, we can allow the use of incomplete views in
+          many more places, which is especially valuable for limited
+          views.
+
+23.i/2
+          {AI95-00326-01AI95-00326-01} It is now illegal to use an
+          incomplete view (type) in a primitive subprogram of the type
+          unless the incomplete view is completed in the package
+          specification.  This was allowed in Ada 95 for incomplete
+          types where the completion was deferred to the body (the use
+          would have to be in an access parameter).  This
+          incompatibility was caused by the fix for the hole noted in
+          Legality Rules above.
+
+                        _Extensions to Ada 95_
+
+23.j/2
+          {AI95-00326-01AI95-00326-01} Tagged incomplete types are new.
+          They are allowed in parameter declarations as well as the
+          usual places, as tagged types are always by-reference types
+          (and thus there can be no code generation issue).
+
+23.k/2
+          {AI95-00412-01AI95-00412-01} A subtype_declaration can be used
+          to give a new name to an incomplete view of a type.  This is
+          valuable to give shorter names to entities imported with a
+          limited_with_clause.
+
+                     _Wording Changes from Ada 95_
+
+23.l/2
+          {AI95-00326-01AI95-00326-01} The description of incomplete
+          types as incomplete views is new.  Ada 95 defined these as
+          separate types, but neglected to give any rules for matching
+          them with other types.  Luckily, implementers did the right
+          thing anyway.  This change also makes it easier to describe
+          the meaning of a limited view.
+
+                       _Extensions to Ada 2005_
+
+23.m/3
+          {AI05-0098-1AI05-0098-1} Correction: Fixed the definition so
+          that an anonymous access-to-subprogram type can use an
+          incomplete view in the same way that a named
+          access-to-subprogram type can.
+
+23.n/3
+          {AI05-0151-1AI05-0151-1} Incomplete types now can be used in
+          subprogram declarations.  The type has to be complete before
+          any calls or the body is declared.  This reduces the places
+          where access types are required for types imported from
+          limited views of packages.
+
+23.o/3
+          {AI05-0162-1AI05-0162-1} Incomplete types now can be completed
+          by private types and private extensions.  Since this can
+          already happen for limited views, there is no remaining reason
+          to disallow it for explicitly declared incomplete types.
+
+                    _Wording Changes from Ada 2005_
+
+23.p/3
+          {AI05-0208-1AI05-0208-1} Correction: Changed the rules of uses
+          of dereferences of incomplete views such that it does not
+          introduce an unintentional incompatibility with Ada 83 and Ada
+          95.
+
+23.q/3
+          {AI05-0213-1AI05-0213-1} Incomplete types now can be used as
+          actuals to formal incomplete types (see *note 12.5.1::).
+
+
+File: aarm2012.info,  Node: 3.10.2,  Prev: 3.10.1,  Up: 3.10
+
+3.10.2 Operations of Access Types
+---------------------------------
+
+1/3
+{AI05-0299-1AI05-0299-1} [The attribute Access is used to create access
+values designating aliased objects and nonintrinsic subprograms.  The
+"accessibility" rules prevent dangling references (in the absence of
+uses of certain unchecked features -- see Clause *note 13::).]
+
+                     _Language Design Principles_
+
+1.a
+          It should be possible for an access value to designate an
+          object declared by an object declaration, or a subcomponent
+          thereof.  In implementation terms, this means pointing at
+          stack-allocated and statically allocated data structures.
+          However, dangling references should be prevented, primarily
+          via compile-time rules, so long as features like
+          Unchecked_Access and Unchecked_Deallocation are not used.
+
+1.b
+          In order to create such access values, we require that the
+          access type be a general access type, that the designated
+          object be aliased, and that the accessibility rules be obeyed.
+
+                        _Name Resolution Rules_
+
+2/2
+{AI95-00235-01AI95-00235-01} For an attribute_reference with
+attribute_designator Access (or Unchecked_Access -- see *note 13.10::),
+the expected type shall be a single access type A such that:
+
+2.1/2
+   * {AI95-00235-01AI95-00235-01} A is an access-to-object type with
+     designated type D and the type of the prefix is D'Class or is
+     covered by D, or
+
+2.2/2
+   * {AI95-00235-01AI95-00235-01} A is an access-to-subprogram type
+     whose designated profile is type conformant with that of the
+     prefix.
+
+2.3/2
+{AI95-00235-01AI95-00235-01} [The prefix of such an attribute_reference
+is never interpreted as an implicit_dereference or a parameterless
+function_call (see *note 4.1.4::).]  The designated type or profile of
+the expected type of the attribute_reference is the expected type or
+profile for the prefix.
+
+2.a
+          Discussion: Saying that the expected type shall be a "single
+          access type" is our "new" way of saying that the type has to
+          be determinable from context using only the fact that it is an
+          access type.  See *note 4.2:: and *note 8.6::.  Specifying the
+          expected profile only implies type conformance.  The more
+          stringent subtype conformance is required by a Legality Rule.
+          This is the only Resolution Rule that applies to the name in a
+          prefix of an attribute_reference.  In all other cases, the
+          name has to be resolved without using context.  See *note
+          4.1.4::.
+
+2.b/2
+          {AI95-00235-01AI95-00235-01} Saying "single access type" is a
+          bit of a fudge.  Both the context and the prefix may provide
+          both multiple types; "single" only means that a single,
+          specific interpretation must remain after resolution.  We say
+          "single" here to trigger the Legality Rules of *note 8.6::.
+          The resolution of an access attribute is similar to that of an
+          assignment_statement.  For example:
+
+2.c/2
+               type Int_Ptr is access all Integer;
+               type Char_Ptr is access all Character;
+               type Float_Ptr is access all Float;
+
+2.d/2
+               function Zap (Val : Int_Ptr) return Float;   -- (1)
+               function Zap (Val : Float_Ptr) return Float; -- (2)
+               function Zop return Int_Ptr;  -- (3)
+               function Zop return Char_Ptr; -- (4)
+
+2.e/2
+               Result : Float := Zap (Zop.all'Access); -- Resolves to Zap (1) 
and Zop (3).
+
+                          _Static Semantics_
+
+3/2
+{AI95-00162-01AI95-00162-01} [The accessibility rules, which prevent
+dangling references, are written in terms of accessibility levels, which
+reflect the run-time nesting of masters.  As explained in *note 7.6.1::,
+a master is the execution of a certain construct, such as a
+subprogram_body.  An accessibility level is deeper than another if it is
+more deeply nested at run time.  For example, an object declared local
+to a called subprogram has a deeper accessibility level than an object
+declared local to the calling subprogram.  The accessibility rules for
+access types require that the accessibility level of an object
+designated by an access value be no deeper than that of the access type.
+This ensures that the object will live at least as long as the access
+type, which in turn ensures that the access value cannot later designate
+an object that no longer exists.  The Unchecked_Access attribute may be
+used to circumvent the accessibility rules.]
+
+3.a/3
+          Discussion: {AI05-0005-1AI05-0005-1} The Unchecked_Access
+          attribute acts as if the object was declared at library-level;
+          this applies even when it is used as the value of anonymous
+          access type.  See *note 13.10::.
+
+3.b/3
+          Subclause *note 3.10.2::, home of the accessibility rules, is
+          informally known as the "Heart of Darkness" amongst the
+          maintainers of Ada.  Woe unto all who enter here (well, at
+          least unto anyone that needs to understand any of these
+          rules).  
+
+4
+[A given accessibility level is said to be statically deeper than
+another if the given level is known at compile time (as defined below)
+to be deeper than the other for all possible executions.  In most cases,
+accessibility is enforced at compile time by Legality Rules.  Run-time
+accessibility checks are also used, since the Legality Rules do not
+cover certain cases involving access parameters and generic packages.]
+
+5
+Each master, and each entity and view created by it, has an
+accessibility level:
+
+6
+   * The accessibility level of a given master is deeper than that of
+     each dynamically enclosing master, and deeper than that of each
+     master upon which the task executing the given master directly
+     depends (see *note 9.3::).
+
+7/3
+   * {AI95-00162-01AI95-00162-01} {AI95-00416-01AI95-00416-01}
+     {AI05-0235-1AI05-0235-1} An entity or view defined by a declaration
+     and created as part of its elaboration has the same accessibility
+     level as the innermost master of the declaration except in the
+     cases of renaming and derived access types described below.  Other
+     than for an explicitly aliased parameter, a formal parameter of a
+     callable entity has the same accessibility level as the master
+     representing the invocation of the entity.
+
+7.a/2
+          Reason: {AI95-00416-01AI95-00416-01} This rule defines the
+          "normal" accessibility of entities.  In the absence of special
+          rules below, we intend for this rule to apply.
+
+7.b/2
+          Discussion: {AI95-00416-01AI95-00416-01} This rule defines the
+          accessibility of all named access types, as well as the
+          accessibility level of all anonymous access types other than
+          those for access parameters and access discriminants.  Special
+          rules exist for the accessibility level of such anonymous
+          types.  Components, stand-alone objects, and function results
+          whose (anonymous) type is defined by an access_definition have
+          accessibility levels corresponding to named access types
+          defined at the same point.
+
+7.c/2
+          Ramification: {AI95-00230-01AI95-00230-01} Because
+          accessibility level is determined by where the
+          access_definition is elaborated, for a type extension, the
+          anonymous access types of components (other than access
+          discriminants) inherited from the parent have the same
+          accessibility as they did in the parent; those in the
+          extension part have the accessibility determined by the scope
+          where the type extension is declared.  Similarly, the types of
+          the nondiscriminant access components of a derived untagged
+          type have the same accessibility as they did in the parent.
+
+7.d/3
+          To be honest: {AI05-0235-1AI05-0235-1} We use "invocation of"
+          in the parameter case as a master is formally an execution of
+          something.  But we mean this to be interpreted statically (for
+          instance, as the body of the subprogram) for the purposes of
+          computing "statically deeper than" (see below).
+
+7.e/3
+          Ramification: {AI05-0235-1AI05-0235-1} Note that accessibility
+          can differ depending on the view of an object (for both static
+          and dynamic accessibility).  For instance, the accessibility
+          level of a formal parameter may be different than the
+          accessibility level of the corresponding actual parameter.
+          This occurs in other cases as well.
+
+7.f/3
+          Reason: {AI05-0235-1AI05-0235-1} We define the (dynamic)
+          accessibility of formal parameters in order that it does not
+          depend on the parameter passing model (by-reference or
+          by-copy) as that is implementation defined.  Otherwise, there
+          would be a portability issue.
+
+8
+   * The accessibility level of a view of an object or subprogram
+     defined by a renaming_declaration is the same as that of the
+     renamed view.
+
+9/2
+   * {AI95-00416-01AI95-00416-01} The accessibility level of a view
+     conversion, qualified_expression, or parenthesized expression, is
+     the same as that of the operand.
+
+9.1/3
+   * {AI05-0188-1AI05-0188-1} The accessibility level of a
+     conditional_expression is the accessibility level of the evaluated
+     dependent_expression.
+
+10/3
+   * {AI95-00318-02AI95-00318-02} {AI95-00416-01AI95-00416-01}
+     {AI05-0234-1AI05-0234-1} The accessibility level of an aggregate
+     that is used (in its entirety) to directly initialize part of an
+     object is that of the object being initialized.  In other contexts,
+     the accessibility level of an aggregate is that of the innermost
+     master that evaluates the aggregate.
+
+10.1/3
+   * {AI05-0234-1AI05-0234-1} The accessibility level of the result of a
+     function call is that of the master of the function call, which is
+     determined by the point of call as follows:
+
+10.2/3
+             * If the result is used (in its entirety) to directly
+               initialize part of an object, the master is that of the
+               object being initialized.  In the case where the
+               initialized object is a coextension (see below) that
+               becomes a coextension of another object, the master is
+               that of the eventual object to which the coextension will
+               be transferred.
+
+10.a/2
+          To be honest: {AI95-00416-01AI95-00416-01} The first sentence
+          is talking about a static use of the entire return object -- a
+          slice that happens to be the entire return object doesn't
+          count.  On the other hand, this is intended to allow
+          parentheses and qualified_expressions.
+
+10.b/3
+          Ramification: {AI95-00416-01AI95-00416-01}
+          {AI05-0234-1AI05-0234-1} If the function is used as a prefix,
+          this bullet does not apply.  Similarly, an
+          assignment_statement is not an initialization of an object, so
+          this bullet does not apply.
+
+10.3/3
+             * If the result is of an anonymous access type and is the
+               operand of an explicit conversion, the master is that of
+               the target type of the conversion;
+
+10.4/3
+             * If the result is of an anonymous access type and defines
+               an access discriminant, the master is the same as that
+               for an object created by an anonymous allocator that
+               defines an access discriminant (even if the access result
+               is of an access-to-subprogram type).
+
+10.5/3
+             * If the call itself defines the result of a function to
+               which one of the above rules applies, these rules are
+               applied recursively;
+
+10.6/3
+             * In other cases, the master of the call is that of the
+               innermost master that evaluates the function call.
+
+10.c/2
+          Ramification: {AI95-00318-02AI95-00318-02}
+          {AI95-00416-01AI95-00416-01} The "innermost master which
+          evaluated the function call" does not include the function
+          call itself (which might be a master).
+
+10.d/2
+          {AI95-00318-02AI95-00318-02} {AI95-00416-01AI95-00416-01} We
+          really mean the innermost master here, which could be a very
+          short lifetime.  Consider a function call used as a parameter
+          of a procedure call.  In this case the innermost master which
+          evaluated the function call is the procedure call.
+
+10.d.1/3
+          Ramification: {AI05-0234-1AI05-0234-1} These rules do not
+          mention whether the result object is built-in-place (see *note
+          7.6::).  In particular, in the case where building in place is
+          optional, the choice whether or not to build-in-place has no
+          effect on masters, lifetimes, or accessibility.
+
+10.d.2/3
+          Implementation Note: {AI05-0234-1AI05-0234-1} There are
+          several cases where the implementation may have to pass in the
+          accessibility level of the result object on a call, to support
+          later rules where the accessibility level comes from the
+          master of the call:
+
+10.d.3/3
+             * when the function result may have a part with access
+               discriminants;
+
+10.d.4/3
+             * when the function result type is an anonymous access
+               type;
+
+10.d.5/3
+             * when the function result is built-in-place;
+
+10.d.6/3
+             * when the function has an explicitly aliased parameter.
+
+10.d.7/3
+          In particular, this implies passing a level parameter when the
+          result type is class-wide, since descendants may add access
+          discriminants.  For most implementations this will mean that
+          functions with controlling results will also need a level
+          parameter.
+
+10.7/3
+     {AI05-0284-1AI05-0284-1} In the case of a call to a function whose
+     result type is an anonymous access type, the accessibility level of
+     the type of the result of the function call is also determined by
+     the point of call as described above.
+
+10.8/3
+   * {AI95-00416-01AI95-00416-01} Within a return statement, the
+     accessibility level of the return object is that of the execution
+     of the return statement.  If the return statement completes
+     normally by returning from the function, then prior to leaving the
+     function, the accessibility level of the return object changes to
+     be a level determined by the point of call, as does the level of
+     any coextensions (see below) of the return object.
+
+10.e/2
+          Reason: We define the accessibility level of the return object
+          during the return statement to be that of the return statement
+          itself so that the object may be designated by objects local
+          to the return statement, but not by objects outside the return
+          statement.  In addition, the intent is that the return object
+          gets finalized if the return statement ends without actually
+          returning (for example, due to propagating an exception, or a
+          goto).  For a normal return, of course, no finalization is
+          done before returning.
+
+11
+   * The accessibility level of a derived access type is the same as
+     that of its ultimate ancestor.
+
+11.1/2
+   * {AI95-00230-01AI95-00230-01} The accessibility level of the
+     anonymous access type defined by an access_definition of an
+     object_renaming_declaration is the same as that of the renamed
+     view.
+
+12/2
+   * {AI95-00230-01AI95-00230-01} {AI95-00416-01AI95-00416-01} The
+     accessibility level of the anonymous access type of an access
+     discriminant in the subtype_indication or qualified_expression of
+     an allocator, or in the expression or return_subtype_indication
+     (*note 6.5: S0187.) of a return statement is determined as follows:
+
+12.1/2
+             * If the value of the access discriminant is determined by
+               a discriminant_association in a subtype_indication, the
+               accessibility level of the object or subprogram
+               designated by the associated value (or library level if
+               the value is null);
+
+12.a/2
+          Discussion: This deals with the following cases, when they
+          occur in the context of an allocator or return statement:
+
+12.b/2
+                  * An extension_aggregate where the ancestor_part is a
+                    subtype_mark denoting a constrained subtype;
+
+12.c/2
+                  * An uninitialized allocator where the
+                    subtype_indication defines a constrained subtype;
+
+12.d/2
+                  * A discriminant of an object with a constrained
+                    nominal subtype, including constrained components,
+                    the result of calling a function with a constrained
+                    result subtype, the dereference of an
+                    access-to-constrained subtype, etc.
+
+12.e/3
+          Ramification: {AI05-0281-1AI05-0281-1} The subtype_indication
+          mentioned in this bullet is not necessarily the one given in
+          the allocator or return statement that is determining the
+          accessibility level; the constrained subtype might have been
+          defined in an earlier declaration (as a named subtype).
+
+12.f/3
+          {AI05-0005-1AI05-0005-1} If the value for this rule and the
+          next one is derived from an Unchecked_Access attribute, the
+          accessibility is library-level no matter what the
+          accessibility level of the object is (see *note 13.10::).
+
+12.2/3
+             * {AI05-0234-1AI05-0234-1} If the value of the access
+               discriminant is determined by a default_expression in the
+               declaration of the discriminant, the level of the object
+               or subprogram designated by the associated value (or
+               library level if null);
+
+12.f.1/3
+          Discussion: This covers the case of an unconstrained
+          subcomponent of a limited type with defaulted access
+          discriminants.
+
+12.3/3
+             * {AI05-0004-1AI05-0004-1} If the value of the access
+               discriminant is determined by a
+               record_component_association in an aggregate, the
+               accessibility level of the object or subprogram
+               designated by the associated value (or library level if
+               the value is null);
+
+12.g/2
+          Discussion: In this bullet, the aggregate has to occur in the
+          context of an allocator or return statement, while the
+          subtype_indication of the previous bullet can occur anywhere
+          (it doesn't have to be directly given in the allocator or
+          return statement).
+
+12.4/3
+             * In other cases, where the value of the access
+               discriminant is determined by an object with an
+               unconstrained nominal subtype, the accessibility level of
+               the object.
+
+12.h/2
+          Discussion: {AI95-00416-01AI95-00416-01} In other words, if
+          you know the value of the discriminant for an allocator or
+          return statement from a discriminant constraint or an
+          aggregate component association, then that determines the
+          accessibility level; if you don't know it, then it is based on
+          the object itself.
+
+12.5/3
+   * {AI95-00416-01AI95-00416-01} The accessibility level of the
+     anonymous access type of an access discriminant in any other
+     context is that of the enclosing object.
+
+13/3
+   * {AI95-00162-01AI95-00162-01} {AI95-00254-01AI95-00254-01}
+     {AI05-0270-1AI05-0270-1} The accessibility level of the anonymous
+     access type of an access parameter specifying an access-to-object
+     type is the same as that of the view designated by the actual (or
+     library-level if the actual is null).
+
+13.a/3
+          Ramification: {AI05-0005-1AI05-0005-1} If the value of the
+          actual is derived from an Unchecked_Access attribute, the
+          accessibility is always library-level (see *note 13.10::).
+
+13.1/2
+   * {AI95-00254-01AI95-00254-01} The accessibility level of the
+     anonymous access type of an access parameter specifying an
+     access-to-subprogram type is deeper than that of any master; all
+     such anonymous access types have this same level.
+
+13.b/2
+          Reason: These represent "downward closures" and thus require
+          passing of static links or global display information (along
+          with generic sharing information if the implementation does
+          sharing) along with the address of the subprogram.  We must
+          prevent conversions of these to types with "normal"
+          accessibility, as those typically don't include the extra
+          information needed to make a call.
+
+13.2/3
+   * {AI05-0148-1AI05-0148-1} {AI05-0240-1AI05-0240-1} The accessibility
+     level of the type of a stand-alone object of an anonymous
+     access-to-object type is the same as the accessibility level of the
+     type of the access value most recently assigned to the object[;
+     accessibility checks ensure that this is never deeper than that of
+     the declaration of the stand-alone object].
+
+13.3/3
+   * {AI05-0142-4AI05-0142-4} {AI05-0240-1AI05-0240-1} The accessibility
+     level of an explicitly aliased (see *note 6.1::) formal parameter
+     in a function body is determined by the point of call; it is the
+     same level that the return object ultimately will have.
+
+14/3
+   * {AI95-00416-01AI95-00416-01} {AI05-0051-1AI05-0051-1}
+     {AI05-0253-1AI05-0253-1} The accessibility level of an object
+     created by an allocator is the same as that of the access type,
+     except for an allocator of an anonymous access type (an anonymous
+     allocator) in certain contexts, as follows: For an anonymous
+     allocator that defines the result of a function with an access
+     result, the accessibility level is determined as though the
+     allocator were in place of the call of the function; in the special
+     case of a call that is the operand of a type conversion, the level
+     is that of the target access type of the conversion.  For an
+     anonymous allocator defining the value of an access parameter, the
+     accessibility level is that of the innermost master of the call.
+     For an anonymous allocator whose type is that of a stand-alone
+     object of an anonymous access-to-object type, the accessibility
+     level is that of the declaration of the stand-alone object.  For
+     one defining an access discriminant, the accessibility level is
+     determined as follows:
+
+14.1/3
+             * {AI95-00416-01AI95-00416-01} {AI05-0024-1AI05-0024-1} for
+               an allocator used to define the discriminant of an
+               object, the level of the object;
+
+14.2/3
+             * {AI95-00416-01AI95-00416-01} {AI05-0024-1AI05-0024-1} for
+               an allocator used to define the constraint in a
+               subtype_indication in any other context, the level of the
+               master that elaborates the subtype_indication.
+
+14.3/3
+             * This paragraph was deleted.{AI95-00416-01AI95-00416-01}
+               {AI05-0024-1AI05-0024-1}
+
+14.4/3
+     {AI95-00416-01AI95-00416-01} {AI05-0024-1AI05-0024-1}
+     {AI05-0066-1AI05-0066-1} In the first case, the allocated object is
+     said to be a coextension of the object whose discriminant
+     designates it, as well as of any object of which the discriminated
+     object is itself a coextension or subcomponent.  If the allocated
+     object is a coextension of an anonymous object representing the
+     result of an aggregate or function call that is used (in its
+     entirety) to directly initialize a part of an object, after the
+     result is assigned, the coextension becomes a coextension of the
+     object being initialized and is no longer considered a coextension
+     of the anonymous object.  All coextensions of an object [(which
+     have not thus been transfered by such an initialization)] are
+     finalized when the object is finalized (see *note 7.6.1::).
+
+14.a.1/2
+          Ramification: The rules of access discriminants are such that
+          when the space for an object with a coextension is reclaimed,
+          the space for the coextensions can be reclaimed.  Hence, there
+          is implementation advice (see 13.11) that an object and its
+          coextensions all be allocated from the same storage pool (or
+          stack frame, in the case of a declared object).
+
+14.5/3
+   * {AI05-0051-1AI05-0051-1} Within a return statement, the
+     accessibility level of the anonymous access type of an access
+     result is that of the master of the call.
+
+15/3
+   * {AI05-0014-1AI05-0014-1} The accessibility level of a view of an
+     object or subprogram designated by an access value is the same as
+     that of the access type.
+
+15.a/3
+          Discussion: {AI05-0005-1AI05-0005-1} {AI05-0014-1AI05-0014-1}
+          This rule applies even when no dereference exists, for example
+          when an access value is passed as an access parameter.  This
+          rule ensures that implementations are not required to include
+          dynamic accessibility values with all access values.
+
+16
+   * The accessibility level of a component, protected subprogram, or
+     entry of (a view of) a composite object is the same as that of (the
+     view of) the composite object.
+
+16.1/3
+{AI95-00416-01AI95-00416-01} {AI05-0262-1AI05-0262-1} In the above
+rules, the operand of a view conversion, parenthesized expression or
+qualified_expression is considered to be used in a context if the view
+conversion, parenthesized expression or qualified_expression itself is
+used in that context.  Similarly, a dependent_expression of a
+conditional_expression is considered to be used in a context if the
+conditional_expression itself is used in that context.
+
+17
+One accessibility level is defined to be statically deeper than another
+in the following cases:
+
+18
+   * For a master that is statically nested within another master, the
+     accessibility level of the inner master is statically deeper than
+     that of the outer master.
+
+18.a
+          To be honest: Strictly speaking, this should talk about the
+          constructs (such as subprogram_bodies) being statically nested
+          within one another; the masters are really the executions of
+          those constructs.
+
+18.b
+          To be honest: If a given accessibility level is statically
+          deeper than another, then each level defined to be the same as
+          the given level is statically deeper than each level defined
+          to be the same as the other level.
+
+18.1/2
+   * {AI95-00254-01AI95-00254-01} The accessibility level of the
+     anonymous access type of an access parameter specifying an
+     access-to-subprogram type is statically deeper than that of any
+     master; all such anonymous access types have this same level.
+
+18.c/2
+          Ramification: This rule means that it is illegal to convert an
+          access parameter specifying an access to subprogram to a named
+          access to subprogram type, but it is allowed to pass such an
+          access parameter to another access parameter (the implicit
+          conversion's accessibility will succeed).
+
+19/3
+   * {AI95-00254-01AI95-00254-01} {AI05-0082-1AI05-0082-1} The
+     statically deeper relationship does not apply to the accessibility
+     level of the anonymous type of an access parameter specifying an
+     access-to-object type nor does it apply to a descendant of a
+     generic formal type; that is, such an accessibility level is not
+     considered to be statically deeper, nor statically shallower, than
+     any other.
+
+19.1/3
+   * {AI05-0148-1AI05-0148-1} The statically deeper relationship does
+     not apply to the accessibility level of the type of a stand-alone
+     object of an anonymous access-to-object type; that is, such an
+     accessibility level is not considered to be statically deeper, nor
+     statically shallower, than any other.
+
+19.a/3
+          Ramification: In these cases, we use dynamic accessibility
+          checks.
+
+19.2/3
+   * {AI05-0142-4AI05-0142-4} {AI05-0235-1AI05-0235-1} Inside a return
+     statement that applies to a function F, when determining whether
+     the accessibility level of an explicitly aliased parameter of F is
+     statically deeper than the level of the return object of F, the
+     level of the return object is considered to be the same as that of
+     the level of the explicitly aliased parameter; for statically
+     comparing with the level of other entities, an explicitly aliased
+     parameter of F is considered to have the accessibility level of the
+     body of F.
+
+19.3/3
+   * {AI05-0051-1AI05-0051-1} {AI05-0234-1AI05-0234-1}
+     {AI05-0235-1AI05-0235-1} For determining whether a level is
+     statically deeper than the level of the anonymous access type of an
+     access result of a function, when within a return statement that
+     applies to the function, the level of the master of the call is
+     presumed to be the same as that of the level of the master that
+     elaborated the function body.
+
+19.b/3
+          To be honest: {AI05-0235-1AI05-0235-1} This rule has no effect
+          if the previous bullet also applies (that is, the "a level" is
+          of an explicitly aliased parameter).
+
+20
+   * [For determining whether one level is statically deeper than
+     another when within a generic package body, the generic package is
+     presumed to be instantiated at the same level as where it was
+     declared; run-time checks are needed in the case of more deeply
+     nested instantiations.]
+
+20.a/3
+          Proof: {AI05-0082-1AI05-0082-1} A generic package does not
+          introduce a new master, so it has the static level of its
+          declaration; the rest follows from the other "statically
+          deeper" rules.
+
+21
+   * For determining whether one level is statically deeper than another
+     when within the declarative region of a type_declaration, the
+     current instance of the type is presumed to be an object created at
+     a deeper level than that of the type.
+
+21.a
+          Ramification: In other words, the rules are checked at compile
+          time of the type_declaration, in an assume-the-worst manner.
+
+22
+The accessibility level of all library units is called the library
+level; a library-level declaration or entity is one whose accessibility
+level is the library level.
+
+22.a
+          Ramification: Library_unit_declarations are library level.
+          Nested declarations are library level if they are nested only
+          within packages (possibly more than one), and not within
+          subprograms, tasks, etc.
+
+22.b/2
+          To be honest: The definition of the accessibility level of the
+          anonymous type of an access parameter specifying an
+          access-to-object type cheats a bit, since it refers to the
+          view designated by the actual, but access values designate
+          objects, not views of objects.  What we really mean is the
+          view that "would be" denoted by an expression "X.all", where X
+          is the actual, even though such an expression is a figment of
+          our imagination.  The definition is intended to be equivalent
+          to the following more verbose version: The accessibility level
+          of the anonymous type of an access parameter is as follows:
+
+22.c
+             * if the actual is an expression of a named access type --
+               the accessibility level of that type;
+
+22.d
+             * if the actual is an allocator -- the accessibility level
+               of the execution of the called subprogram;
+
+22.e/1
+             * if the actual is a reference to the Access attribute --
+               the accessibility level of the view denoted by the
+               prefix;
+
+22.f
+             * if the actual is a reference to the Unchecked_Access
+               attribute -- library accessibility level;
+
+22.g
+             * if the actual is an access parameter -- the accessibility
+               level of its type.
+
+22.h
+          Note that the allocator case is explicitly mentioned in the
+          RM95, because otherwise the definition would be circular: the
+          level of the anonymous type is that of the view designated by
+          the actual, which is that of the access type.
+
+22.i
+          Discussion: A deeper accessibility level implies a shorter
+          maximum lifetime.  Hence, when a rule requires X to have a
+          level that is "not deeper than" Y's level, this requires that
+          X has a lifetime at least as long as Y. (We say "maximum
+          lifetime" here, because the accessibility level really
+          represents an upper bound on the lifetime; an object created
+          by an allocator can have its lifetime prematurely ended by an
+          instance of Unchecked_Deallocation.)
+
+22.j
+          Package elaborations are not masters, and are therefore
+          invisible to the accessibility rules: an object declared
+          immediately within a package has the same accessibility level
+          as an object declared immediately within the declarative
+          region containing the package.  This is true even in the body
+          of a package; it jibes with the fact that objects declared in
+          a package_body live as long as objects declared outside the
+          package, even though the body objects are not visible outside
+          the package.
+
+22.k
+          Note that the level of the view denoted by X.all can be
+          different from the level of the object denoted by X.all.  The
+          former is determined by the type of X; the latter is
+          determined either by the type of the allocator, or by the
+          master in which the object was declared.  The former is used
+          in several Legality Rules and run-time checks; the latter is
+          used to define when X.all gets finalized.  The level of a view
+          reflects what we can conservatively "know" about the object of
+          that view; for example, due to type_conversions, an access
+          value might designate an object that was allocated by an
+          allocator for a different access type.
+
+22.l
+          Similarly, the level of the view denoted by X.all.Comp can be
+          different from the level of the object denoted by X.all.Comp.
+
+22.m
+          If Y is statically deeper than X, this implies that Y will be
+          (dynamically) deeper than X in all possible executions.
+
+22.n
+          Most accessibility checking is done at compile time; the rules
+          are stated in terms of "statically deeper than".  The
+          exceptions are:
+
+22.o/2
+             * Checks involving access parameters of an access-to-object
+               type.  The fact that "statically deeper than" is not
+               defined for the anonymous access type of an access
+               parameter implies that any rule saying "shall not be
+               statically deeper than" does not apply to such a type,
+               nor to anything defined to have "the same" level as such
+               a type.
+
+22.o.1/3
+             * {AI05-0082-1AI05-0082-1} Checks involving generic formal
+               types and their descendants.  This is because the actual
+               type can be more or less deeply nested than the generic
+               unit.  Note that this only applies to the generic unit
+               itself, and not to the instance.  Any static checks
+               needed in the instance will be performed.  Any other
+               checks (such as those in the generic body) will require a
+               run-time check of some sort (although implementations
+               that macro-expand generics can determine the result of
+               the check when the generic is expanded).
+
+22.p/3
+             * {AI05-0082-1AI05-0082-1} Checks involving other entities
+               and views within generic packages.  This is because an
+               instantiation can be at a level that is more deeply
+               nested than the generic package itself.  In
+               implementations that use a macro-expansion model of
+               generics, these violations can be detected at
+               macro-expansion time.  For implementations that share
+               generics, run-time code is needed to detect the error.
+
+22.q/2
+             * {AI95-00318-02AI95-00318-02} {AI95-00344-01AI95-00344-01}
+               {AI95-00416-01AI95-00416-01} Checks during function
+               return and allocators, for nested type extensions and
+               access discriminants.
+
+22.r/3
+          {AI05-0005-1AI05-0005-1} Note that run-time checks are not
+          required for access discriminants (except during function
+          returns and allocators), because their accessibility is
+          determined statically by the accessibility level of the
+          enclosing object.
+
+22.s/2
+          The accessibility level of the result object of a function
+          reflects the time when that object will be finalized; we don't
+          allow pointers to the object to survive beyond that time.
+
+22.t
+          We sometimes use the terms "accessible" and "inaccessible" to
+          mean that something has an accessibility level that is not
+          deeper, or deeper, respectively, than something else.
+
+22.u/2
+          Implementation Note: {AI95-00318-02AI95-00318-02}
+          {AI95-00344-01AI95-00344-01} {AI95-00416-01AI95-00416-01} If
+          an accessibility Legality Rule is satisfied, then the
+          corresponding run-time check (if any) cannot fail (and a
+          reasonable implementation will not generate any checking code)
+          unless one of the cases requiring run-time checks mentioned
+          previously is involved.
+
+22.v
+          Accessibility levels are defined in terms of the relations
+          "the same as" and "deeper than".  To make the discussion more
+          concrete, we can assign actual numbers to each level.  Here,
+          we assume that library-level accessibility is level 0, and
+          each level defined as "deeper than" is one level deeper.
+          Thus, a subprogram directly called from the environment task
+          (such as the main subprogram) would be at level 1, and so on.
+
+22.w/2
+          Accessibility is not enforced at compile time for access
+          parameters of an access-to-object type.  The "obvious"
+          implementation of the run-time checks would be inefficient,
+          and would involve distributed overhead; therefore, an
+          efficient method is given below.  The "obvious" implementation
+          would be to pass the level of the caller at each subprogram
+          call, task creation, etc.  This level would be incremented by
+          1 for each dynamically nested master.  An Accessibility_Check
+          would be implemented as a simple comparison -- checking that X
+          is not deeper than Y would involve checking that X <= Y.
+
+22.x
+          A more efficient method is based on passing static nesting
+          levels (within constructs that correspond at run time to
+          masters -- packages don't count).  Whenever an access
+          parameter is passed, an implicit extra parameter is passed
+          with it.  The extra parameter represents (in an indirect way)
+          the accessibility level of the anonymous access type, and,
+          therefore, the level of the view denoted by a dereference of
+          the access parameter.  This is analogous to the implicit
+          "Constrained" bit associated with certain formal parameters of
+          an unconstrained but definite composite subtype.  In this
+          method, we avoid distributed overhead: it is not necessary to
+          pass any extra information to subprograms that have no access
+          parameters.  For anything other than an access parameter and
+          its anonymous type, the static nesting level is known at
+          compile time, and is defined analogously to the RM95
+          definition of accessibility level (e.g.  derived access types
+          get their nesting level from their parent).  Checking "not
+          deeper than" is a "<=" test on the levels.
+
+22.y/2
+          For each access parameter of an access-to-object type, the
+          static depth passed depends on the actual, as follows:
+
+22.z
+             * If the actual is an expression of a named access type,
+               pass the static nesting level of that type.
+
+22.aa
+             * If the actual is an allocator, pass the static nesting
+               level of the caller, plus one.
+
+22.bb/1
+             * If the actual is a reference to the Access attribute,
+               pass the level of the view denoted by the prefix.
+
+22.cc
+             * If the actual is a reference to the Unchecked_Access
+               attribute, pass 0 (the library accessibility level).
+
+22.dd/2
+             * If the actual is an access parameter of an
+               access-to-object type, usually just pass along the level
+               passed in.  However, if the static nesting level of the
+               formal (access) parameter is greater than the static
+               nesting level of the actual (access) parameter, the level
+               to be passed is the minimum of the static nesting level
+               of the access parameter and the actual level passed in.
+
+22.ee/2
+          For the Accessibility_Check associated with a type_conversion
+          of an access parameter of an access-to-object type of a given
+          subprogram to a named access type, if the target type is
+          statically nested within the subprogram, do nothing; the check
+          can't fail in this case.  Otherwise, check that the value
+          passed in is <= the static nesting depth of the target type.
+          The other Accessibility_Checks are handled in a similar
+          manner.
+
+22.ff
+          This method, using statically known values most of the time,
+          is efficient, and, more importantly, avoids distributed
+          overhead.
+
+22.ff.1/3
+          {AI05-0148-1AI05-0148-1} The implementation of accessibility
+          checks for stand-alone objects of anonymous access-to-object
+          types can be similar to that for anonymous access-to-object
+          parameters.  A static level suffices; it can be calculated
+          using rules similar to those previously described for access
+          parameters.
+
+22.ff.2/3
+          {AI05-0148-1AI05-0148-1} One important difference between the
+          stand-alone access variables and access parameters is that one
+          can assign a local access parameter to a more global
+          stand-alone access variable.  Similarly, one can assign a more
+          global access parameter to a more local stand-alone access
+          variable.
+
+22.ff.3/3
+          {AI05-0148-1AI05-0148-1} For these cases, it is important to
+          note that the "correct" static accessibility level for an
+          access parameter assigned to a stand-alone access object is
+          the minimum of the passed in level and the static
+          accessibility level of the stand-alone object itself.  This is
+          true since the static accessibility level passed in might be
+          deeper than that of the stand-alone object, but the dynamic
+          accessibility of the passed in object clearly must be
+          shallower than the stand-alone object (whatever is passed in
+          must live at least as long as the subprogram call).  We do not
+          need to keep a more local static level as accesses to objects
+          statically deeper than the stand-alone object cannot be stored
+          into the stand-alone object.
+
+22.gg
+          Discussion: Examples of accessibility:
+
+22.hh/3
+               {AI05-0005-1AI05-0005-1} package body Lib_Unit is
+                   type T is tagged ...;
+                   type A0 is access all T;
+                   Global: A0 := ...;
+                   procedure P(X: in out T) is
+                       Y: aliased T;
+                       type A1 is access all T;
+                       Ptr0: A0 := Global; -- OK.
+                       Ptr1: A1 := X'Access; -- OK.
+                   begin
+                       Ptr1 := Y'Access; -- OK;
+                       Ptr0 := A0(Ptr1); -- Illegal type conversion!
+                       Ptr0 := X'Access; -- Illegal reference to Access 
attribute!
+                       Ptr0 := Y'Access; -- Illegal reference to Access 
attribute!
+                       Global := Ptr0; -- OK.
+                   end P;
+               end Lib_Unit;
+
+22.ii/3
+          {AI05-0005-1AI05-0005-1} The above illegal statements are
+          illegal because the accessibility levels of X and Y are
+          statically deeper than the accessibility level of A0.  In
+          every possible execution of any program including this library
+          unit, if P is called, the accessibility level of X will be
+          (dynamically) deeper than that of A0.  Note that the
+          accessibility levels of X and Y are the same.
+
+22.jj/2
+          Here's an example involving access parameters of an
+          access-to-object type:
+
+22.kk
+               procedure Main is
+                   type Level_1_Type is access all Integer;
+
+22.ll
+                   procedure P(X: access Integer) is
+                       type Nested_Type is access all Integer;
+                   begin
+                       ... Nested_Type(X) ... -- (1)
+                       ... Level_1_Type(X) ... -- (2)
+                   end P;
+
+22.mm
+                   procedure Q(X: access Integer) is
+                       procedure Nested(X: access Integer) is
+                       begin
+                           P(X);
+                       end Nested;
+                   begin
+                       Nested(X);
+                   end Q;
+
+22.nn
+                   procedure R is
+                       Level_2: aliased Integer;
+                   begin
+                       Q(Level_2'Access); -- (3)
+                   end R;
+
+22.oo
+                   Level_1: aliased Integer;
+               begin
+                   Q(Level_1'Access); -- (4)
+                   R;
+               end Main;
+
+22.pp
+          The run-time Accessibility_Check at (1) can never fail, and no
+          code should be generated to check it.  The check at (2) will
+          fail when called from (3), but not when called from (4).
+
+22.qq
+          Within a type_declaration, the rules are checked in an
+          assume-the-worst manner.  For example:
+
+22.rr/3
+               {AI05-0298-1AI05-0298-1} package P is
+                   type Int_Ptr is access all Integer;
+                   type Rec(D: access Integer) is limited private;
+               private
+                   type Rec_Ptr is access all Rec;
+                   function F(X: Rec_Ptr) return Boolean;
+                   function G(X: access Rec) return Boolean;
+                   type Rec(D: access Integer) is
+                       limited record
+                           C1: Int_Ptr := Int_Ptr(D); -- Illegal!
+                           C2: Rec_Ptr := Rec'Access; -- Illegal!
+                           C3: Boolean := F(Rec'Access); -- Illegal!
+                           C4: Boolean := G(Rec'Access);
+                       end record;
+               end P;
+
+22.ss
+          C1, C2, and C3 are all illegal, because one might declare an
+          object of type Rec at a more deeply nested place than the
+          declaration of the type.  C4 is legal, but the accessibility
+          level of the object will be passed to function G, and
+          constraint checks within G will prevent it from doing any evil
+          deeds.
+
+22.tt
+          Note that we cannot defer the checks on C1, C2, and C3 until
+          compile-time of the object creation, because that would cause
+          violation of the privacy of private parts.  Furthermore, the
+          problems might occur within a task or protected body, which
+          the compiler can't see while compiling an object creation.
+
+23
+The following attribute is defined for a prefix X that denotes an
+aliased view of an object:
+
+24/1
+X'Access
+               {8652/00108652/0010} {AI95-00127-01AI95-00127-01}
+               X'Access yields an access value that designates the
+               object denoted by X. The type of X'Access is an
+               access-to-object type, as determined by the expected
+               type.  The expected type shall be a general access type.
+               X shall denote an aliased view of an object[, including
+               possibly the current instance (see *note 8.6::) of a
+               limited type within its definition, or a formal parameter
+               or generic formal object of a tagged type].  The view
+               denoted by the prefix X shall satisfy the following
+               additional requirements, presuming the expected type for
+               X'Access is the general access type A with designated
+               type D:
+
+25
+                  * If A is an access-to-variable type, then the view
+                    shall be a variable; [on the other hand, if A is an
+                    access-to-constant type, the view may be either a
+                    constant or a variable.]
+
+25.a
+          Discussion: The current instance of a limited type is
+          considered a variable.
+
+26/3
+                  * {AI95-00363-01AI95-00363-01}
+                    {AI05-0008-1AI05-0008-1} {AI05-0041-1AI05-0041-1}
+                    The view shall not be a subcomponent that depends on
+                    discriminants of an object unless the object is
+                    known to be constrained.
+
+26.a
+          Discussion: This restriction is intended to be similar to the
+          restriction on renaming discriminant-dependent subcomponents.
+
+26.b
+          Reason: This prevents references to subcomponents that might
+          disappear or move or change constraints after creating the
+          reference.
+
+26.c
+          Implementation Note: There was some thought to making this
+          restriction more stringent, roughly: "X shall not denote a
+          subcomponent of a variable with discriminant-dependent
+          subcomponents, if the nominal subtype of the variable is an
+          unconstrained definite subtype."  This was because in some
+          implementations, it is not just the discriminant-dependent
+          subcomponents that might move as the result of an assignment
+          that changed the discriminants of the enclosing object.
+          However, it was decided not to make this change because a
+          reasonable implementation strategy was identified to avoid
+          such problems, as follows:
+
+26.d
+             * Place non-discriminant-dependent components with any
+               aliased parts at offsets preceding any
+               discriminant-dependent components in a discriminated
+               record type with defaulted discriminants.
+
+26.e
+             * Preallocate the maximum space for unconstrained
+               discriminated variables with aliased subcomponents,
+               rather than allocating the initial size and moving them
+               to a larger (heap-resident) place if they grow as the
+               result of an assignment.
+
+26.f
+          Note that for objects of a by-reference type, it is not an
+          error for a programmer to take advantage of the fact that such
+          objects are passed by reference.  Therefore, the above
+          approach is also necessary for discriminated record types with
+          components of a by-reference type.
+
+26.g
+          To make the above strategy work, it is important that a
+          component of a derived type is defined to be
+          discriminant-dependent if it is inherited and the parent
+          subtype constraint is defined in terms of a discriminant of
+          the derived type (see *note 3.7::).
+
+27/2
+                  * {8652/00108652/0010} {AI95-00127-01AI95-00127-01}
+                    {AI95-00363-01AI95-00363-01} If A is a named access
+                    type and D is a tagged type, then the type of the
+                    view shall be covered by D; if A is anonymous and D
+                    is tagged, then the type of the view shall be either
+                    D'Class or a type covered by D; if D is untagged,
+                    then the type of the view shall be D, and either:
+
+27.1/2
+                            * {AI95-00363-01AI95-00363-01} the
+                              designated subtype of A shall statically
+                              match the nominal subtype of the view; or
+
+27.2/3
+                            * {AI95-00363-01AI95-00363-01}
+                              {AI05-0041-1AI05-0041-1} D shall be
+                              discriminated in its full view and
+                              unconstrained in any partial view, and the
+                              designated subtype of A shall be
+                              unconstrained.  For the purposes of
+                              determining within a generic body whether
+                              D is unconstrained in any partial view, a
+                              discriminated subtype is considered to
+                              have a constrained partial view if it is a
+                              descendant of an untagged generic formal
+                              private or derived type.
+
+27.a
+          Implementation Note: This ensures that the dope for an aliased
+          array object can always be stored contiguous with it, but need
+          not be if its nominal subtype is constrained.
+
+27.a.1/1
+          Ramification: {8652/00108652/0010}
+          {AI95-00127-01AI95-00127-01} An access attribute can be used
+          as the controlling operand in a dispatching call; see *note
+          3.9.2::.
+
+27.a.2/2
+          {AI95-00363-01AI95-00363-01} This does not require that types
+          have a partial view in order to allow an access attribute of
+          an unconstrained discriminated object, only that any partial
+          view that does exist is unconstrained.
+
+28/3
+                  * {AI05-0041-1AI05-0041-1} The accessibility level of
+                    the view shall not be statically deeper than that of
+                    the access type A. 
+
+28.a
+          Ramification: In an instance body, a run-time check applies.
+
+28.b/2
+          {AI95-00230-01AI95-00230-01} If A is an anonymous
+          access-to-object type of an access parameter, then the view
+          can never have a deeper accessibility level than A. The same
+          is true for an anonymous access-to-object type of an access
+          discriminant, except when X'Access is used to initialize an
+          access discriminant of an object created by an allocator.  The
+          latter case is illegal if the accessibility level of X is
+          statically deeper than that of the access type of the
+          allocator; a run-time check is needed in the case where the
+          initial value comes from an access parameter.  Other anonymous
+          access-to-object types have "normal" accessibility checks.
+
+28.1/3
+               {AI05-0041-1AI05-0041-1} In addition to the places where
+               Legality Rules normally apply (see *note 12.3::), these
+               requirements apply also in the private part of an
+               instance of a generic unit.
+
+29
+               A check is made that the accessibility level of X is not
+               deeper than that of the access type A. If this check
+               fails, Program_Error is raised.
+
+29.a/2
+          Ramification: The check is needed for access parameters of an
+          access-to-object type and in instance bodies.
+
+29.a.1/3
+          {AI05-0024-1AI05-0024-1} Because there are no access
+          parameters permitted for task entries, the accessibility
+          levels are always comparable.  We would have to switch to the
+          terminology used in *note 4.8:: and *note 6.5:: based on
+          inclusion within masters if we relax this restriction.  That
+          might introduce unacceptable distributed overhead.
+
+29.b/3
+          Implementation Note: {AI05-0148-1AI05-0148-1} This check
+          requires that some indication of lifetime is passed as an
+          implicit parameter along with access parameters of an
+          access-to-object type.  A similar indication is required for
+          stand-alone objects of anonymous access-to-object types.No
+          such requirement applies to other anonymous access types,
+          since the checks associated with them are all compile-time
+          checks.
+
+30
+               If the nominal subtype of X does not statically match the
+               designated subtype of A, a view conversion of X to the
+               designated subtype is evaluated (which might raise
+               Constraint_Error -- see *note 4.6::) and the value of
+               X'Access designates that view.
+
+31
+The following attribute is defined for a prefix P that denotes a
+subprogram:
+
+32/3
+P'Access
+               {AI95-00229-01AI95-00229-01} {AI95-00254-01AI95-00254-01}
+               {AI05-0239-1AI05-0239-1} P'Access yields an access value
+               that designates the subprogram denoted by P. The type of
+               P'Access is an access-to-subprogram type (S), as
+               determined by the expected type.  The accessibility level
+               of P shall not be statically deeper than that of S. In
+               addition to the places where Legality Rules normally
+               apply (see *note 12.3::), this rule applies also in the
+               private part of an instance of a generic unit.  The
+               profile of P shall be subtype conformant with the
+               designated profile of S, and shall not be Intrinsic.  If
+               the subprogram denoted by P is declared within a generic
+               unit, and the expression P'Access occurs within the body
+               of that generic unit or within the body of a generic unit
+               declared within the declarative region of the generic
+               unit, then the ultimate ancestor of S shall be either a
+               nonformal type declared within the generic unit or an
+               anonymous access type of an access parameter.
+
+32.a/2
+          Discussion: {AI95-00229-01AI95-00229-01} The part about
+          generic bodies is worded in terms of the denoted subprogram,
+          not the denoted view; this implies that renaming is invisible
+          to this part of the rule.  "Declared within the declarative
+          region of the generic" is referring to child and nested
+          generic units.This rule is partly to prevent contract model
+          problems with respect to the accessibility rules, and partly
+          to ease shared-generic-body implementations, in which a
+          subprogram declared in an instance needs to have a different
+          calling convention from other subprograms with the same
+          profile.
+
+32.b
+          Overload resolution ensures only that the profile is type
+          conformant.  This rule specifies that subtype conformance is
+          required (which also requires matching calling conventions).
+          P cannot denote an entry because access-to-subprogram types
+          never have the entry calling convention.  P cannot denote an
+          enumeration literal or an attribute function because these
+          have intrinsic calling conventions.
+
+                           _Legality Rules_
+
+32.1/3
+{AI05-0188-1AI05-0188-1} An expression is said to have distributed
+accessibility if it is
+
+32.2/3
+   * a conditional_expression (see *note 4.5.7::); or
+
+32.3/3
+   * a view conversion, qualified_expression, or parenthesized
+     expression whose operand has distributed accessibility.
+
+32.4/3
+{AI05-0188-1AI05-0188-1} The statically deeper relationship does not
+apply to the accessibility level of an expression having distributed
+accessibility; that is, such an accessibility level is not considered to
+be statically deeper, nor statically shallower, than any other.
+
+32.5/3
+{AI05-0188-1AI05-0188-1} Any static accessibility requirement that is
+imposed on an expression that has distributed accessibility (or on its
+type) is instead imposed on the dependent_expressions of the underlying
+conditional_expression.  This rule is applied recursively if a
+dependent_expression also has distributed accessibility.
+
+32.c/3
+          Discussion: This means that any Legality Rule requiring that
+          the accessibility level of an expression (or that of the type
+          of an expression) shall or shall not be statically deeper than
+          some other level also applies, in the case where the
+          expression has distributed accessibility, to each
+          dependent_expression of the underlying conditional_expression.
+
+     NOTES
+
+33
+     88  The Unchecked_Access attribute yields the same result as the
+     Access attribute for objects, but has fewer restrictions (see *note
+     13.10::).  There are other predefined operations that yield access
+     values: an allocator can be used to create an object, and return an
+     access value that designates it (see *note 4.8::); evaluating the
+     literal null yields a null access value that designates no entity
+     at all (see *note 4.2::).
+
+34/2
+     89  {AI95-00230-01AI95-00230-01} The predefined operations of an
+     access type also include the assignment operation, qualification,
+     and membership tests.  Explicit conversion is allowed between
+     general access types with matching designated subtypes; explicit
+     conversion is allowed between access-to-subprogram types with
+     subtype conformant profiles (see *note 4.6::).  Named access types
+     have predefined equality operators; anonymous access types do not,
+     but they can use the predefined equality operators for
+     universal_access (see *note 4.5.2::).
+
+34.a/2
+          Reason: {AI95-00230-01AI95-00230-01} Anonymous access types
+          can use the universal access equality operators declared in
+          Standard, while named access types cannot for compatibility
+          reasons.  By not having equality operators for anonymous
+          access types, we eliminate the need to specify exactly where
+          the predefined operators for anonymous access types would be
+          defined, as well as the need for an implementer to insert an
+          implicit declaration for "=", etc.  at the appropriate place
+          in their symbol table.  Note that ":=", 'Access, and ".all"
+          are defined.
+
+35
+     90  The object or subprogram designated by an access value can be
+     named with a dereference, either an explicit_dereference (*note
+     4.1: S0094.) or an implicit_dereference.  See *note 4.1::.
+
+36
+     91  A call through the dereference of an access-to-subprogram value
+     is never a dispatching call.
+
+36.a
+          Proof: See *note 3.9.2::.
+
+37/2
+     92  {AI95-00254-01AI95-00254-01} The Access attribute for
+     subprograms and parameters of an anonymous access-to-subprogram
+     type may together be used to implement "downward closures" -- that
+     is, to pass a more-nested subprogram as a parameter to a
+     less-nested subprogram, as might be appropriate for an iterator
+     abstraction or numerical integration.  Downward closures can also
+     be implemented using generic formal subprograms (see *note 12.6::).
+     Note that Unchecked_Access is not allowed for subprograms.
+
+38
+     93  Note that using an access-to-class-wide tagged type with a
+     dispatching operation is a potentially more structured alternative
+     to using an access-to-subprogram type.
+
+39
+     94  An implementation may consider two access-to-subprogram values
+     to be unequal, even though they designate the same subprogram.
+     This might be because one points directly to the subprogram, while
+     the other points to a special prologue that performs an
+     Elaboration_Check and then jumps to the subprogram.  See *note
+     4.5.2::.
+
+39.a
+          Ramification: If equality of access-to-subprogram values is
+          important to the logic of a program, a reference to the Access
+          attribute of a subprogram should be evaluated only once and
+          stored in a global constant for subsequent use and equality
+          comparison.
+
+                              _Examples_
+
+40
+Example of use of the Access attribute:
+
+41
+     Martha : Person_Name := new Person(F);       -- see *note 3.10.1::
+     Cars   : array (1..2) of aliased Car;
+        ...
+     Martha.Vehicle := Cars(1)'Access;
+     George.Vehicle := Cars(2)'Access;
+
+                        _Extensions to Ada 83_
+
+41.a
+          We no longer make things like 'Last and ".component" (basic)
+          operations of an access type that need to be "declared"
+          somewhere.  Instead, implicit dereference in a prefix takes
+          care of them all.  This means that there should never be a
+          case when X.all'Last is legal while X'Last is not.  See
+          AI83-00154.
+
+                    _Incompatibilities With Ada 95_
+
+41.b/2
+          {AI95-00363-01AI95-00363-01}  Aliased variables are not
+          necessarily constrained in Ada 2005 (see *note 3.6::).
+          Therefore, a subcomponent of an aliased variable may disappear
+          or change shape, and taking 'Access of such a subcomponent
+          thus is illegal, while the same operation would have been
+          legal in Ada 95.  Note that most allocated objects are still
+          constrained by their initial value (see *note 4.8::), and thus
+          legality of 'Access didn't change for them.  For example:
+
+41.c/2
+               type T1 (D1 : Boolean := False) is
+                  record
+                     case D1 is
+                        when False =>
+                           C1 : aliased Integer;
+                        when True =>
+                           null;
+                     end case;
+                  end record;
+               type Acc_Int is access all Integer;
+
+41.d/2
+               A_T : aliased T1;
+               Ptr : Acc_Int := A_T.C1'Access; -- Illegal in Ada 2005, legal 
in Ada 95
+               A_T := (D1 => True);            -- Raised Constraint_Error in 
Ada 95, but does not
+                                               -- in Ada 2005, so Ptr would 
become invalid when this
+                                               -- is assigned (thus Ptr is 
illegal).
+
+41.e/2
+          {AI95-00363-01AI95-00363-01} If a discriminated full type has
+          a partial view (private type) that is constrained, we do not
+          allow 'Access on objects to create a value of an object of an
+          access-to-unconstrained type.  Ada 95 allowed this attribute
+          and various access subtypes, requiring that the heap object be
+          constrained and thus making details of the implementation of
+          the private type visible to the client of the private type.
+          See *note 4.8:: for more on this topic.
+
+41.f/2
+          {AI95-00229-01AI95-00229-01} {AI95-00254-01AI95-00254-01}
+          Amendment Correction: Taking 'Access of a subprogram declared
+          in a generic unit in the body of that generic is no longer
+          allowed.  Such references can easily be used to create
+          dangling pointers, as Legality Rules are not rechecked in
+          instance bodies.  At the same time, the rules were loosened a
+          bit where that is harmless, and also to allow any routine to
+          be passed to an access parameter of an access-to-subprogram
+          type.  The now illegal uses of 'Access can almost always be
+          moved to the private part of the generic unit, where they are
+          still legal (and rechecked upon instantiation for possibly
+          dangling pointers).
+
+                        _Extensions to Ada 95_
+
+41.g/2
+          {8652/00108652/0010} {AI95-00127-01AI95-00127-01} Corrigendum:
+          Access attributes of objects of class-wide types can be used
+          as the controlling parameter in a dispatching calls (see *note
+          3.9.2::).  This was an oversight in Ada 95.
+
+41.h/2
+          {AI95-00235-01AI95-00235-01} Amendment Correction: The type of
+          the prefix can now be used in resolving Access attributes.
+          This allows more uses of the Access attribute to resolve.  For
+          example:
+
+41.i/2
+               type Int_Ptr is access all Integer;
+               type Float_Ptr is access all Float;
+
+41.j/2
+               function Zap (Val : Int_Ptr) return Float;
+               function Zap (Val : Float_Ptr) return Float;
+
+41.k/2
+               Value : aliased Integer := 10;
+
+41.l/2
+               Result1 : Float := Zap (Value'access); -- Ambiguous in Ada 95; 
resolves in Ada 2005.
+               Result2 : Float := Zap (Int_Ptr'(Value'access)); -- Resolves in 
Ada 95 and Ada 2005.
+
+41.m/2
+          This change is upward compatible; any expression that does not
+          resolve by the new rules would have failed a Legality Rule.
+
+                     _Wording Changes from Ada 95_
+
+41.n/2
+          {AI95-00162-01AI95-00162-01} Adjusted the wording to reflect
+          the fact that expressions and function calls are masters.
+
+41.o/2
+          {AI95-00230-01AI95-00230-01} {AI95-00254-01AI95-00254-01}
+          {AI95-00318-02AI95-00318-02} {AI95-00385-01AI95-00385-01}
+          {AI95-00416-01AI95-00416-01} Defined the accessibility of the
+          various new kinds and uses of anonymous access types.
+
+                   _Incompatibilities With Ada 2005_
+
+41.p/3
+          {AI05-0008-1AI05-0008-1} Correction: Simplified the
+          description of when a discriminant-dependent component is
+          allowed as the prefix of 'Access to when the object is known
+          to be constrained.  This fixes a confusion as to whether a
+          subcomponent of an object that is not certain to be
+          constrained can be used as a prefix of 'Access.  The fix
+          introduces an incompatibility, as the rule did not apply in
+          Ada 95 if the prefix was a constant; but it now applies no
+          matter what kind of object is involved.  The incompatibility
+          is not too bad, since most kinds of constants are known to be
+          constrained.
+
+41.q/3
+          {AI05-0041-1AI05-0041-1} Correction: Corrected the checks for
+          the constrainedness of the prefix of the Access attribute so
+          that assume-the-worst is used in generic bodies.  This may
+          make some programs illegal, but those programs were at risk
+          having objects disappear while valid access values still
+          pointed at them.
+
+                       _Extensions to Ada 2005_
+
+41.r/3
+          {AI05-0082-1AI05-0082-1} Correction: Eliminated the static
+          accessibility definition for generic formal types, as the
+          actual can be more or less nested than the generic itself.
+          This allows programs that were illegal for Ada 95 and for Ada
+          2005.
+
+41.s/3
+          {AI05-0148-1AI05-0148-1} {AI05-0253-1AI05-0253-1} Eliminate
+          the static accessibility definition for stand-alone objects of
+          anonymous access-to-object types.  This allows such objects to
+          be used as temporaries without causing accessibility problems.
+
+                    _Wording Changes from Ada 2005_
+
+41.t/3
+          {AI05-0014-1AI05-0014-1} Correction: Corrected the rules so
+          that the accessibility of the object designated by an access
+          object is that of the access type, even when no dereference is
+          given.  The accessibility was not specified in the past.  This
+          correction applies to both Ada 95 and Ada 2005.
+
+41.u/3
+          {AI05-0024-1AI05-0024-1} Correction: Corrected accessibility
+          rules for access discriminants so that no cases are omitted.
+
+41.v/3
+          {AI05-0051-1AI05-0051-1} {AI05-0234-1AI05-0234-1}
+          {AI05-0235-1AI05-0235-1} {AI05-0284-1AI05-0284-1} Correction:
+          Corrected accessibility rules for anonymous access return
+          types and access discriminants in return statements.
+
+41.w/3
+          {AI05-0066-1AI05-0066-1} Correction: Changed coextension rules
+          so that coextensions that belong to an anonymous object are
+          transfered to the ultimate object.
+
+41.x/3
+          {AI05-0142-4AI05-0142-4} {AI05-0188-1AI05-0188-1}
+          {AI05-0235-1AI05-0235-1} Defined the accessibility of
+          explicitly aliased parameters (see *note 6.1::) and
+          conditional_expressions (see *note 4.5.7::).
+
+41.y/3
+          {AI05-0234-1AI05-0234-1} Correction: Defined the term "master
+          of the call" to simplify other wording, especially that for
+          the accessibility checks associated with return statements and
+          explicitly aliased parameters.
+
+41.z/3
+          {AI05-0270-1AI05-0270-1} Correction: Defined the (omitted)
+          accessibility level of null values when those are passed as
+          the actual of an access-to-object parameter.
+
+
+File: aarm2012.info,  Node: 3.11,  Prev: 3.10,  Up: 3
+
+3.11 Declarative Parts
+======================
+
+1
+[A declarative_part contains declarative_items (possibly none).]
+
+                               _Syntax_
+
+2
+     declarative_part ::= {declarative_item}
+
+3
+     declarative_item ::=
+         basic_declarative_item | body
+
+4/1
+     {8652/00098652/0009} {AI95-00137-01AI95-00137-01}
+     basic_declarative_item ::=
+         basic_declaration | aspect_clause | use_clause
+
+5
+     body ::= proper_body | body_stub
+
+6
+     proper_body ::=
+         subprogram_body | package_body | task_body | protected_body
+
+                          _Static Semantics_
+
+6.1/2
+{AI95-00420-01AI95-00420-01} The list of declarative_items of a
+declarative_part is called the declaration list of the declarative_part.
+
+                          _Dynamic Semantics_
+
+7
+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.
+
+8
+An elaborable construct is in the elaborated state after the normal
+completion of its elaboration.  Prior to that, it is not yet elaborated.
+
+8.a
+          Ramification: The elaborated state is only important for
+          bodies; certain uses of a body raise an exception if the body
+          is not yet elaborated.
+
+8.b
+          Note that "prior" implies before the start of elaboration, as
+          well as during elaboration.
+
+8.c
+          The use of the term "normal completion" implies that if the
+          elaboration propagates an exception or is aborted, the
+          declaration is not elaborated.  RM83 missed the aborted case.
+
+9
+For a construct that attempts to use a body, a check (Elaboration_Check)
+is performed, as follows:
+
+10/1
+   * {8652/00148652/0014} {AI95-00064-01AI95-00064-01} For a call to a
+     (non-protected) subprogram that has an explicit body, a check is
+     made that the body is already elaborated.  This check and the
+     evaluations of any actual parameters of the call are done in an
+     arbitrary order.
+
+10.a
+          Discussion: AI83-00180 specifies that there is no elaboration
+          check for a subprogram defined by a pragma Interface (or
+          equivalently, pragma Import).  AI83-00430 specifies that there
+          is no elaboration check for an enumeration literal.
+          AI83-00406 specifies that the evaluation of parameters and the
+          elaboration check occur in an arbitrary order.  AI83-00406
+          applies to generic instantiation as well (see below).
+
+10.a.1/3
+          {8652/00148652/0014} {AI95-00064-01AI95-00064-01}
+          {AI05-0177-1AI05-0177-1} A subprogram can be completed by a
+          renaming-as-body, a null_procedure_declaration, or an
+          expression_function_declaration, and we need to make an
+          elaboration check on such a body, so we use "body" rather than
+          subprogram_body above.
+
+11/3
+   * {AI05-0229-1AI05-0229-1} For a call to a protected operation of a
+     protected type (that has a body -- no check is performed if the
+     protected type is imported -- see *note B.1::), a check is made
+     that the protected_body is already elaborated.  This check and the
+     evaluations of any actual parameters of the call are done in an
+     arbitrary order.
+
+11.a
+          Discussion: A protected type has only one elaboration "bit,"
+          rather than one for each operation, because one call may
+          result in evaluating the barriers of other entries, and
+          because there are no elaborable declarations between the
+          bodies of the operations.  In fact, the elaboration of a
+          protected_body does not elaborate the enclosed bodies, since
+          they are not considered independently elaborable.
+
+11.b
+          Note that there is no elaboration check when calling a task
+          entry.  Task entry calls are permitted even before the
+          associated task_body has been seen.  Such calls are simply
+          queued until the task is activated and reaches a corresponding
+          accept_statement.  We considered a similar rule for protected
+          entries -- simply queuing all calls until the protected_body
+          was seen, but felt it was not worth the possible
+          implementation overhead, particularly given that there might
+          be multiple instances of the protected type.
+
+12
+   * For the activation of a task, a check is made by the activator that
+     the task_body is already elaborated.  If two or more tasks are
+     being activated together (see *note 9.2::), as the result of the
+     elaboration of a declarative_part or the initialization for the
+     object created by an allocator, this check is done for all of them
+     before activating any of them.
+
+12.a
+          Reason: As specified by AI83-00149, the check is done by the
+          activator, rather than by the task itself.  If it were done by
+          the task itself, it would be turned into a Tasking_Error in
+          the activator, and the other tasks would still be activated.
+
+13
+   * For the instantiation of a generic unit that has a body, a check is
+     made that this body is already elaborated.  This check and the
+     evaluation of any explicit_generic_actual_parameters of the
+     instantiation are done in an arbitrary order.
+
+14
+The exception Program_Error is raised if any of these checks fails.
+
+                        _Extensions to Ada 83_
+
+14.a/2
+          {AI95-00114-01AI95-00114-01} The syntax for declarative_part
+          is modified to remove the ordering restrictions of Ada 83;
+          that is, the distinction between basic_declarative_items and
+          later_declarative_items within declarative_parts is removed.
+          This means that things like use_clauses and
+          object_declarations can be freely intermixed with things like
+          bodies.
+
+14.b
+          The syntax rule for proper_body now allows a protected_body,
+          and the rules for elaboration checks now cover calls on
+          protected operations.
+
+                     _Wording Changes from Ada 83_
+
+14.c
+          The syntax rule for later_declarative_item is removed; the
+          syntax rule for declarative_item is new.
+
+14.d
+          RM83 defines "elaborated" and "not yet elaborated" for
+          declarative_items here, and for other things in *note 3.1::,
+          "*note 3.1:: Declarations".  That's no longer necessary, since
+          these terms are fully defined in *note 3.1::.
+
+14.e
+          In RM83, all uses of declarative_part are optional (except for
+          the one in block_statement with a declare) which is sort of
+          strange, since a declarative_part can be empty, according to
+          the syntax.  That is, declarative_parts are sort of "doubly
+          optional".  In Ada 95, these declarative_parts are always
+          required (but can still be empty).  To simplify description,
+          we go further and say (see *note 5.6::, "*note 5.6:: Block
+          Statements") that a block_statement without an explicit
+          declarative_part is equivalent to one with an empty one.
+
+                     _Wording Changes from Ada 95_
+
+14.f/2
+          {8652/00098652/0009} {AI95-00137-01AI95-00137-01} Corrigendum:
+          Changed representation clauses to aspect clauses to reflect
+          that they are used for more than just representation.
+
+14.g/2
+          {8652/00148652/0014} {AI95-00064-01AI95-00064-01} Corrigendum:
+          Clarified that the elaboration check applies to all kinds of
+          subprogram bodies.
+
+14.h/2
+          {AI95-00420-01AI95-00420-01} Defined "declaration list" to
+          avoid confusion for various rules.  Other kinds of declaration
+          list are defined elsewhere.
+
+* Menu:
+
+* 3.11.1 ::   Completions of Declarations
+
+
+File: aarm2012.info,  Node: 3.11.1,  Up: 3.11
+
+3.11.1 Completions of Declarations
+----------------------------------
+
+1/3
+{8652/00148652/0014} {AI95-00064-01AI95-00064-01}
+{AI05-0177-1AI05-0177-1} Declarations sometimes come in two parts.  A
+declaration that requires a second part is said to require completion.
+The second part is called the completion of the declaration (and of the
+entity declared), and is either another declaration, a body, or a
+pragma.  A body is a body, an entry_body, a null_procedure_declaration
+or an expression_function_declaration that completes another
+declaration, or a renaming-as-body (see *note 8.5.4::).
+
+1.a
+          Discussion: Throughout the RM95, there are rules about
+          completions that define the following:
+
+1.b
+             * Which declarations require a corresponding completion.
+
+1.c
+             * Which constructs can only serve as the completion of a
+               declaration.
+
+1.d
+             * Where the completion of a declaration is allowed to be.
+
+1.e
+             * What kinds of completions are allowed to correspond to
+               each kind of declaration that allows one.
+
+1.f
+          Don't confuse this compile-time concept with the run-time
+          concept of completion defined in *note 7.6.1::.
+
+1.g
+          Note that the declaration of a private type (if limited) can
+          be completed with the declaration of a task type, which is
+          then completed with a body.  Thus, a declaration can actually
+          come in three parts.
+
+1.h/3
+          {AI95-00217-06AI95-00217-06} {AI05-0162-1AI05-0162-1} An
+          incomplete type (whether declared in the limited view of a
+          package or not) may be completed by a private type
+          declaration, so we can in fact have four parts.
+
+1.i/3
+          {AI05-0229-1AI05-0229-1} In Ada 2012, there are no
+          language-defined pragmas that act as completions.  Pragma
+          Import (which is obsolescent) has the effect of setting aspect
+          Import to True; such an aspect makes giving a completion
+          illegal.  The wording that allows pragmas as completions was
+          left as it is harmless and appears in many places in this
+          Standard.
+
+                        _Name Resolution Rules_
+
+2
+A construct that can be a completion is interpreted as the completion of
+a prior declaration only if:
+
+3
+   * The declaration and the completion occur immediately within the
+     same declarative region;
+
+4
+   * The defining name or defining_program_unit_name in the completion
+     is the same as in the declaration, or in the case of a pragma, the
+     pragma applies to the declaration;
+
+5
+   * If the declaration is overloadable, then the completion either has
+     a type-conformant profile, or is a pragma.  
+
+                           _Legality Rules_
+
+6/3
+{AI05-0229-1AI05-0229-1} An implicit declaration shall not have a
+completion.  For any explicit declaration that is specified to require
+completion, there shall be a corresponding explicit completion, unless
+the declared entity is imported (see *note B.1::).
+
+6.a.1/2
+          To be honest: {AI95-00217-06AI95-00217-06} The implicit
+          declarations occurring in a limited view do have a completion
+          (the explicit declaration occurring in the full view) but
+          that's a special case, since the implicit declarations are
+          actually built from the explicit ones.  So they do not require
+          a completion, they have one by fiat.
+
+6.a/3
+          Discussion: {AI05-0299-1AI05-0299-1} The implicit declarations
+          of predefined operators are not allowed to have a completion.
+          Enumeration literals, although they are subprograms, are not
+          allowed to have a corresponding subprogram_body.  That's
+          because the completion rules are described in terms of
+          constructs (subprogram_declarations) and not entities
+          (subprograms).  When a completion is required, it has to be
+          explicit; the implicit null package_body that Clause *note 7::
+          talks about cannot serve as the completion of a
+          package_declaration if a completion is required.
+
+7
+At most one completion is allowed for a given declaration.  Additional
+requirements on completions appear where each kind of completion is
+defined.
+
+7.a
+          Ramification: A subunit is not a completion; the stub is.
+
+7.b
+          If the completion of a declaration is also a declaration, then
+          that declaration might have a completion, too.  For example, a
+          limited private type can be completed with a task type, which
+          can then be completed with a task body.  This is not a
+          violation of the "at most one completion" rule.
+
+8
+A type is completely defined at a place that is after its full type
+definition (if it has one) and after all of its subcomponent types are
+completely defined.  A type shall be completely defined before it is
+frozen (see *note 13.14:: and *note 7.3::).
+
+8.a
+          Reason: Index types are always completely defined -- no need
+          to mention them.  There is no way for a completely defined
+          type to depend on the value of a (still) deferred constant.
+
+     NOTES
+
+9/3
+     95  {AI05-0229-1AI05-0229-1} Completions are in principle allowed
+     for any kind of explicit declaration.  However, for some kinds of
+     declaration, the only allowed completion is an
+     implementation-defined pragma, and implementations are not required
+     to have any such pragmas.
+
+9.a/3
+          This paragraph was deleted.{AI05-0229-1AI05-0229-1}
+
+10
+     96  There are rules that prevent premature uses of declarations
+     that have a corresponding completion.  The Elaboration_Checks of
+     *note 3.11:: prevent such uses at run time for subprograms,
+     protected operations, tasks, and generic units.  The rules of *note
+     13.14::, "*note 13.14:: Freezing Rules" prevent, at compile time,
+     premature uses of other entities such as private types and deferred
+     constants.
+
+                     _Wording Changes from Ada 83_
+
+10.a
+          This subclause is new.  It is intended to cover all kinds of
+          completions of declarations, be they a body for a spec, a full
+          type for an incomplete or private type, a full constant
+          declaration for a deferred constant declaration, or a pragma
+          Import for any kind of entity.
+
+                     _Wording Changes from Ada 95_
+
+10.b/2
+          {8652/00148652/0014} {AI95-00064-01AI95-00064-01} Corrigendum:
+          Added a definition of body, which is different than body or
+          body.
+
+                    _Wording Changes from Ada 2005_
+
+10.c/3
+          {AI95-0177-1AI95-0177-1} Added null procedures and expression
+          functions that are completions to the definition of body.
+
+
+File: aarm2012.info,  Node: 4,  Next: 5,  Prev: 3,  Up: Top
+
+4 Names and Expressions
+***********************
+
+1/3
+{AI05-0299-1AI05-0299-1} [The rules applicable to the different forms of
+name and expression, and to their evaluation, are given in this clause.]
+
+* Menu:
+
+* 4.1 ::      Names
+* 4.2 ::      Literals
+* 4.3 ::      Aggregates
+* 4.4 ::      Expressions
+* 4.5 ::      Operators and Expression Evaluation
+* 4.6 ::      Type Conversions
+* 4.7 ::      Qualified Expressions
+* 4.8 ::      Allocators
+* 4.9 ::      Static Expressions and Static Subtypes
+
+
+File: aarm2012.info,  Node: 4.1,  Next: 4.2,  Up: 4
+
+4.1 Names
+=========
+
+1
+[Names can denote declared entities, whether declared explicitly or
+implicitly (see *note 3.1::).  Names can also denote objects or
+subprograms designated by access values; the results of type_conversions
+or function_calls; subcomponents and slices of objects and values;
+protected subprograms, single entries, entry families, and entries in
+families of entries.  Finally, names can denote attributes of any of the
+foregoing.]
+
+                               _Syntax_
+
+2/3
+     {AI05-0003-1AI05-0003-1} {AI05-0139-2AI05-0139-2} name ::=
+          direct_name   | explicit_dereference
+        | indexed_component   | slice
+        | selected_component   | attribute_reference
+        | type_conversion   | function_call
+        | character_literal   | qualified_expression
+        | generalized_reference   | generalized_indexing
+
+3
+     direct_name ::= identifier | operator_symbol
+
+3.a/2
+          Discussion: {AI95-00114-01AI95-00114-01} character_literal is
+          no longer a direct_name.  character_literals are usable even
+          when the corresponding enumeration type declaration is not
+          visible.  See *note 4.2::.
+
+4
+     prefix ::= name | implicit_dereference
+
+5
+     explicit_dereference ::= name.all
+
+6
+     implicit_dereference ::= name
+
+7/3
+{AI05-0004-1AI05-0004-1} [Certain forms of name (indexed_components,
+selected_components, slices, and attribute_references) include a prefix
+that is either itself a name that denotes some related entity, or an
+implicit_dereference of an access value that designates some related
+entity.]
+
+                        _Name Resolution Rules_
+
+8
+The name in a dereference (either an implicit_dereference or an
+explicit_dereference) is expected to be of any access type.
+
+                          _Static Semantics_
+
+9/3
+{AI05-0008-1AI05-0008-1} If the type of the name in a dereference is
+some access-to-object type T, then the dereference denotes a view of an
+object, the nominal subtype of the view being the designated subtype of
+T. If the designated subtype has unconstrained discriminants, the
+(actual) subtype of the view is constrained by the values of the
+discriminants of the designated object, except when there is a partial
+view of the type of the designated subtype that does not have
+discriminants, in which case the dereference is not constrained by its
+discriminant values.
+
+9.a
+          Ramification: If the value of the name is the result of an
+          access type conversion, the dereference denotes a view created
+          as part of the conversion.  The nominal subtype of the view is
+          not necessarily the same as that used to create the designated
+          object.  See *note 4.6::.
+
+9.b
+          To be honest: We sometimes refer to the nominal subtype of a
+          particular kind of name rather than the nominal subtype of the
+          view denoted by the name (presuming the name denotes a view of
+          an object).  These two uses of nominal subtype are intended to
+          mean the same thing.
+
+9.c/3
+          Reason: {AI05-0008-1AI05-0008-1} The last sentence was not
+          present in Ada 95; it is necessary in Ada 2005 because general
+          access types can designate unconstrained objects, which was
+          not possible in Ada 95.  Thus, the rules that had this effect
+          in Ada 95 (the object being constrained by its initial value)
+          don't work in Ada 2005 and we have to say this explicitly.
+
+9.d/3
+          {AI05-0008-1AI05-0008-1} The "except" part of the last
+          sentence prevents privacy "breaking", so that if a private
+          type has discriminants only in the full view, they don't
+          interfere with freely interassigning values between objects of
+          the type, even when the objects live in the heap.
+
+9.e/3
+          Implementation Note: {AI05-0008-1AI05-0008-1} Since we don't
+          depend on whether the designated object is constrained, it is
+          not necessary to include a constrained bit in every object
+          that could be designated by a general access type.
+
+10
+If the type of the name in a dereference is some access-to-subprogram
+type S, then the dereference denotes a view of a subprogram, the profile
+of the view being the designated profile of S.
+
+10.a
+          Ramification: This means that the formal parameter names and
+          default expressions to be used in a call whose name or prefix
+          is a dereference are those of the designated profile, which
+          need not be the same as those of the subprogram designated by
+          the access value, since 'Access requires only subtype
+          conformance, not full conformance.
+
+                          _Dynamic Semantics_
+
+11/2
+{AI95-00415-01AI95-00415-01} The evaluation of a name determines the
+entity denoted by the name.  This evaluation has no other effect for a
+name that is a direct_name or a character_literal.
+
+12
+[The evaluation of a name that has a prefix includes the evaluation of
+the prefix.]  The evaluation of a prefix consists of the evaluation of
+the name or the implicit_dereference.  The prefix denotes the entity
+denoted by the name or the implicit_dereference.
+
+13
+The evaluation of a dereference consists of the evaluation of the name
+and the determination of the object or subprogram that is designated by
+the value of the name.  A check is made that the value of the name is
+not the null access value.  Constraint_Error is raised if this check
+fails.  The dereference denotes the object or subprogram designated by
+the value of the name.
+
+                              _Examples_
+
+14
+Examples of direct names:
+
+15
+     Pi    -- the direct name of a number    (see *note 3.3.2::)
+     Limit    -- the direct name of a constant    (see *note 3.3.1::)
+     Count    -- the direct name of a scalar variable    (see *note 3.3.1::)
+     Board    -- the direct name of an array variable    (see *note 3.6.1::)
+     Matrix    -- the direct name of a type    (see *note 3.6::)
+     Random    -- the direct name of a function    (see *note 6.1::)
+     Error    -- the direct name of an exception    (see *note 11.1::)
+
+16
+Examples of dereferences:
+
+17
+     Next_Car.all   --  explicit dereference denoting the object designated by
+                       --  the access variable Next_Car (see *note 3.10.1::)
+     Next_Car.Owner    --  selected component with implicit dereference;
+                       --  same as Next_Car.all.Owner
+
+                        _Extensions to Ada 83_
+
+17.a
+          Type conversions and function calls are now considered names
+          that denote the result of the operation.  In the case of a
+          type conversion used as an actual parameter or that is of a
+          tagged type, the type conversion is considered a variable if
+          the operand is a variable.  This simplifies the description of
+          "parameters of the form of a type conversion" as well as
+          better supporting an important OOP paradigm that requires the
+          combination of a conversion from a class-wide type to some
+          specific type followed immediately by component selection.
+          Function calls are considered names so that a type conversion
+          of a function call and the function call itself are treated
+          equivalently in the grammar.  A function call is considered
+          the name of a constant, and can be used anywhere such a name
+          is permitted.  See *note 6.5::.
+
+17.b/1
+          Type conversions of a tagged type are permitted anywhere their
+          operand is permitted.  That is, if the operand is a variable,
+          then the type conversion can appear on the left-hand side of
+          an assignment_statement.  If the operand is an object, then
+          the type conversion can appear in an object renaming or as a
+          prefix.  See *note 4.6::.
+
+                     _Wording Changes from Ada 83_
+
+17.c/2
+          {AI95-00114-01AI95-00114-01} Everything of the general
+          syntactic form name(...)  is now syntactically a name.  In any
+          realistic parser, this would be a necessity since
+          distinguishing among the various name(...)  constructs
+          inevitably requires name resolution.  In cases where the
+          construct yields a value rather than an object, the name
+          denotes a value rather than an object.  Names already denote
+          values in Ada 83 with named numbers, components of the result
+          of a function call, etc.  This is partly just a wording
+          change, and partly an extension of functionality (see
+          Extensions heading above).
+
+17.d
+          The syntax rule for direct_name is new.  It is used in places
+          where direct visibility is required.  It's kind of like Ada
+          83's simple_name, but simple_name applied to both direct
+          visibility and visibility by selection, and furthermore, it
+          didn't work right for operator_symbols.  The syntax rule for
+          simple_name is removed, since its use is covered by a
+          combination of direct_name and selector_name.  The syntactic
+          categories direct_name and selector_name are similar; it's
+          mainly the visibility rules that distinguish the two.  The
+          introduction of direct_name requires the insertion of one new
+          explicit textual rule: to forbid statement_identifiers from
+          being operator_symbols.  This is the only case where the
+          explicit rule is needed, because this is the only case where
+          the declaration of the entity is implicit.  For example, there
+          is no need to syntactically forbid (say) "X: "Rem";", because
+          it is impossible to declare a type whose name is an
+          operator_symbol in the first place.
+
+17.e
+          The syntax rules for explicit_dereference and
+          implicit_dereference are new; this makes other rules simpler,
+          since dereferencing an access value has substantially
+          different semantics from selected_components.  We also use
+          name instead of prefix in the explicit_dereference rule since
+          that seems clearer.  Note that these rules rely on the fact
+          that function calls are now names, so we don't need to use
+          prefix to allow functions calls in front of .all.
+
+17.f
+          Discussion: Actually, it would be reasonable to allow any
+          primary in front of .all, since only the value is needed, but
+          that would be a bit radical.
+
+17.g
+          We no longer use the term appropriate for a type since we now
+          describe the semantics of a prefix in terms of implicit
+          dereference.
+
+                       _Extensions to Ada 2005_
+
+17.h/3
+          {AI05-0003-1AI05-0003-1} A qualified_expression is now a name
+          denoting a constant view; this allows them to be used as a
+          prefix and to be renamed as an object.  They are often used to
+          remove ambiguity from function calls, and there may be no
+          other way to do that.  Interestingly, a type_conversion of a
+          qualified_expression is already legal in these contexts, so
+          this change mainly reduces clutter by eliminating an otherwise
+          unneeded type_conversion from some expressions.
+
+                    _Wording Changes from Ada 2005_
+
+17.i/3
+          {AI05-0008-1AI05-0008-1} Correction: Added a missing rule so
+          that most dereferences are assumed constrained (without
+          determining whether the designated object is).  This is just
+          confirming the Ada 95 rules; Ada 2005 failed to ensure that
+          this property was unchanged.
+
+17.j/3
+          {AI05-0139-2AI05-0139-2} {AI05-0299-1AI05-0299-1} Added
+          generalized_reference and generalized_indexing as types of
+          name; these are documented as extensions in the appropriate
+          subclauses.
+
+* Menu:
+
+* 4.1.1 ::    Indexed Components
+* 4.1.2 ::    Slices
+* 4.1.3 ::    Selected Components
+* 4.1.4 ::    Attributes
+* 4.1.5 ::    User-Defined References
+* 4.1.6 ::    User-Defined Indexing
+
+
+File: aarm2012.info,  Node: 4.1.1,  Next: 4.1.2,  Up: 4.1
+
+4.1.1 Indexed Components
+------------------------
+
+1
+[An indexed_component denotes either a component of an array or an entry
+in a family of entries.  ]
+
+                               _Syntax_
+
+2
+     indexed_component ::= prefix(expression {, expression})
+
+                        _Name Resolution Rules_
+
+3
+The prefix of an indexed_component with a given number of expressions
+shall resolve to denote an array (after any implicit dereference) with
+the corresponding number of index positions, or shall resolve to denote
+an entry family of a task or protected object (in which case there shall
+be only one expression).
+
+4
+The expected type for each expression is the corresponding index type.
+
+                          _Static Semantics_
+
+5
+When the prefix denotes an array, the indexed_component denotes the
+component of the array with the specified index value(s).  The nominal
+subtype of the indexed_component is the component subtype of the array
+type.
+
+6
+When the prefix denotes an entry family, the indexed_component denotes
+the individual entry of the entry family with the specified index value.
+
+                          _Dynamic Semantics_
+
+7
+For the evaluation of an indexed_component, the prefix and the
+expressions are evaluated in an arbitrary order.  The value of each
+expression is converted to the corresponding index type.  A check is
+made that each index value belongs to the corresponding index range of
+the array or entry family denoted by the prefix.  Constraint_Error is
+raised if this check fails.
+
+                              _Examples_
+
+8
+Examples of indexed components:
+
+9
+      My_Schedule(Sat)     --  a component of a one-dimensional array    (see 
*note 3.6.1::)
+      Page(10)             --  a component of a one-dimensional array    (see 
*note 3.6::)
+      Board(M, J + 1)      --  a component of a two-dimensional array    (see 
*note 3.6.1::)
+      Page(10)(20)         --  a component of a component    (see *note 3.6::)
+      Request(Medium)      --  an entry in a family of entries    (see *note 
9.1::)
+      Next_Frame(L)(M, N)  --  a component of a function call    (see *note 
6.1::)
+
+     NOTES
+
+10
+     1  Notes on the examples: 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 that designates a
+     two-dimensional array.
+
+
+File: aarm2012.info,  Node: 4.1.2,  Next: 4.1.3,  Prev: 4.1.1,  Up: 4.1
+
+4.1.2 Slices
+------------
+
+1
+[ 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.
+
+                               _Syntax_
+
+2
+     slice ::= prefix(discrete_range)
+
+                        _Name Resolution Rules_
+
+3
+The prefix of a slice shall resolve to denote a one-dimensional array
+(after any implicit dereference).
+
+4
+The expected type for the discrete_range of a slice is the index type of
+the array type.
+
+                          _Static Semantics_
+
+5
+A slice denotes a one-dimensional array formed by the sequence of
+consecutive components of the array denoted by the prefix, corresponding
+to the range of values of the index given by the discrete_range.
+
+6
+The type of the slice is that of the prefix.  Its bounds are those
+defined by the discrete_range.
+
+                          _Dynamic Semantics_
+
+7
+For the evaluation of a slice, the prefix and the discrete_range are
+evaluated in an arbitrary order.  If the slice is not a null slice (a
+slice where the discrete_range is a null range), then a check is made
+that the bounds of the discrete_range belong to the index range of the
+array denoted by the prefix.  Constraint_Error is raised if this check
+fails.
+
+     NOTES
+
+8
+     2  A slice is not permitted as the prefix of an Access
+     attribute_reference, even if the components or the array as a whole
+     are aliased.  See *note 3.10.2::.
+
+8.a
+          Proof: Slices are not aliased, by *note 3.10::, "*note 3.10::
+          Access Types".
+
+8.b
+          Reason: This is to ease implementation of
+          general-access-to-array.  If slices were aliased,
+          implementations would need to store array dope with the access
+          values, which is not always desirable given
+          access-to-incomplete types completed in a package body.
+
+9
+     3  For a one-dimensional array A, the slice A(N ..  N) denotes an
+     array that has only one component; its type is the type of A. On
+     the other hand, A(N) denotes a component of the array A and has the
+     corresponding component type.
+
+                              _Examples_
+
+10
+Examples of slices:
+
+11
+       Stars(1 .. 15)        --  a slice of 15 characters    (see *note 
3.6.3::)
+       Page(10 .. 10 + Size) --  a slice of 1 + Size components    (see *note 
3.6::)
+       Page(L)(A .. B)       --  a slice of the array Page(L)    (see *note 
3.6::)
+       Stars(1 .. 0)         --  a null slice    (see *note 3.6.3::)
+       My_Schedule(Weekday)  --  bounds given by subtype    (see *note 3.6.1:: 
and *note 3.5.1::)
+       Stars(5 .. 15)(K)     --  same as Stars(K)    (see *note 3.6.3::)
+                             --  provided that K is in 5 .. 15
+
+
+File: aarm2012.info,  Node: 4.1.3,  Next: 4.1.4,  Prev: 4.1.2,  Up: 4.1
+
+4.1.3 Selected Components
+-------------------------
+
+1
+[Selected_components are used to denote components (including
+discriminants), entries, entry families, and protected subprograms; they
+are also used as expanded names as described below.  ]
+
+                               _Syntax_
+
+2
+     selected_component ::= prefix . selector_name
+
+3
+     selector_name ::= identifier | character_literal | operator_symbol
+
+                        _Name Resolution Rules_
+
+4
+A selected_component is called an expanded name if, according to the
+visibility rules, at least one possible interpretation of its prefix
+denotes a package or an enclosing named construct (directly, not through
+a subprogram_renaming_declaration or generic_renaming_declaration).
+
+4.a
+          Discussion: See AI83-00187.
+
+5
+A selected_component that is not an expanded name shall resolve to
+denote one of the following:
+
+5.a
+          Ramification: If the prefix of a selected_component denotes an
+          enclosing named construct, then the selected_component is
+          interpreted only as an expanded name, even if the named
+          construct is a function that could be called without
+          parameters.
+
+6
+   * A component [(including a discriminant)]:
+
+7
+     The prefix shall resolve to denote an object or value of some
+     non-array composite type (after any implicit dereference).  The
+     selector_name shall resolve to denote a discriminant_specification
+     of the type, or, unless the type is a protected type, a
+     component_declaration of the type.  The selected_component denotes
+     the corresponding component of the object or value.
+
+7.a/3
+          Reason: {AI05-0005-1AI05-0005-1} The components of a protected
+          object cannot be named except by an expanded name, even from
+          within the corresponding protected body.  The protected body
+          cannot reference the private components of some arbitrary
+          object of the protected type; the protected body may reference
+          components of the current instance only (by an expanded name
+          or a direct_name).
+
+7.b
+          Ramification: Only the discriminants and components visible at
+          the place of the selected_component can be selected, since a
+          selector_name can only denote declarations that are visible
+          (see *note 8.3::).
+
+8
+   * A single entry, an entry family, or a protected subprogram:
+
+9
+     The prefix shall resolve to denote an object or value of some task
+     or protected type (after any implicit dereference).  The
+     selector_name shall resolve to denote an entry_declaration or
+     subprogram_declaration occurring (implicitly or explicitly) within
+     the visible part of that type.  The selected_component denotes the
+     corresponding entry, entry family, or protected subprogram.
+
+9.a
+          Reason: This explicitly says "visible part" because even
+          though the body has visibility on the private part, it cannot
+          call the private operations of some arbitrary object of the
+          task or protected type, only those of the current instance
+          (and expanded name notation has to be used for that).
+
+9.1/2
+   * {AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01} A view of
+     a subprogram whose first formal parameter is of a tagged type or is
+     an access parameter whose designated type is tagged:
+
+9.2/3
+     {AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01}
+     {AI05-0090-1AI05-0090-1} The prefix (after any implicit
+     dereference) shall resolve to denote an object or value of a
+     specific tagged type T or class-wide type T'Class.  The
+     selector_name shall resolve to denote a view of a subprogram
+     declared immediately within the declarative region in which an
+     ancestor of the type T is declared.  The first formal parameter of
+     the subprogram shall be of type T, or a class-wide type that covers
+     T, or an access parameter designating one of these types.  The
+     designator of the subprogram shall not be the same as that of a
+     component of the tagged type visible at the point of the
+     selected_component.  The subprogram shall not be an implicitly
+     declared primitive operation of type T that overrides an inherited
+     subprogram implemented by an entry or protected subprogram visible
+     at the point of the selected_component.  The selected_component
+     denotes a view of this subprogram that omits the first formal
+     parameter.  This view is called a prefixed view of the subprogram,
+     and the prefix of the selected_component (after any implicit
+     dereference) is called the prefix of the prefixed view.  
+
+9.b/3
+          Discussion: {AI05-0090-1AI05-0090-1} The part of the rule that
+          excludes a primitive overriding subprogram as a selector
+          applies only to the wrapper subprogram that is implicitly
+          declared to override a subprogram inherited from a
+          synchronized interface that is implemented by an operation of
+          a task or protected type (see *note 9.1:: and *note 9.4::).
+          We don't want calls that use a prefixed view to be ambiguous
+          between the wrapper subprogram and the implementing entry or
+          protected operation.  Note that it is illegal to declare an
+          explicit primitive that has a prefixed view that is
+          homographic with one of the type's operations, so in normal
+          cases it isn't possible to have an ambiguity in a prefix call.
+          However, a class-wide operation of an ancestor type that is
+          declared in the same declaration list with the ancestor type
+          is also considered, and that can still make a call ambiguous.
+
+10
+An expanded name shall resolve to denote a declaration that occurs
+immediately within a named declarative region, as follows:
+
+11
+   * The prefix shall resolve to denote either a package [(including the
+     current instance of a generic package, or a rename of a package)],
+     or an enclosing named construct.
+
+12
+   * The selector_name shall resolve to denote a declaration that occurs
+     immediately within the declarative region of the package or
+     enclosing construct [(the declaration shall be visible at the place
+     of the expanded name -- see *note 8.3::)].  The expanded name
+     denotes that declaration.
+
+12.a
+          Ramification: Hence, a library unit or subunit can use an
+          expanded name to refer to the declarations within the private
+          part of its parent unit, as well as to other children that
+          have been mentioned in with_clauses.
+
+13
+   * If the prefix does not denote a package, then it shall be a
+     direct_name or an expanded name, and it shall resolve to denote a
+     program unit (other than a package), the current instance of a
+     type, a block_statement, a loop_statement, or an accept_statement
+     (*note 9.5.2: S0219.) (in the case of an accept_statement (*note
+     9.5.2: S0219.) or entry_body (*note 9.5.2: S0221.), no family index
+     is allowed); the expanded name shall occur within the declarative
+     region of this construct.  Further, if this construct is a callable
+     construct and the prefix denotes more than one such enclosing
+     callable construct, then the expanded name is ambiguous,
+     independently of the selector_name.
+
+                           _Legality Rules_
+
+13.1/2
+{AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01} For a
+subprogram whose first parameter is an access parameter, the prefix of
+any prefixed view shall denote an aliased view of an object.
+
+13.2/2
+{AI95-00407-01AI95-00407-01} For a subprogram whose first parameter is
+of mode in out or out, or of an anonymous access-to-variable type, the
+prefix of any prefixed view shall denote a variable.
+
+13.a/2
+          Reason: We want calls through a prefixed view and through a
+          normal view to have the same legality.  Thus, the implicit
+          'Access in this new notation needs the same legality check
+          that an explicit 'Access would have.  Similarly, we need to
+          prohibit the object from being constant if the first parameter
+          of the subprogram is in out, because that is (obviously)
+          prohibited for passing a normal parameter.
+
+                          _Dynamic Semantics_
+
+14
+The evaluation of a selected_component includes the evaluation of the
+prefix.
+
+15
+For a selected_component that denotes a component of a variant, a check
+is made that the values of the discriminants are such that the value or
+object denoted by the prefix has this component.  The exception
+Constraint_Error is raised if this check fails.
+
+                              _Examples_
+
+16
+Examples of selected components:
+
+17/2
+     {AI95-00252-01AI95-00252-01} {AI95-00407-01AI95-00407-01}   
Tomorrow.Month     --  a record component    (see *note 3.8::)
+       Next_Car.Owner     --  a record component    (see *note 3.10.1::)
+       Next_Car.Owner.Age --  a record component    (see *note 3.10.1::)
+                          --  the previous two lines involve implicit 
dereferences
+       Writer.Unit        --  a record component (a discriminant)    (see 
*note 3.8.1::)
+       Min_Cell(H).Value  --  a record component of the result    (see *note 
6.1::)
+                          --  of the function call Min_Cell(H)
+       Cashier.Append     --  a prefixed view of a procedure    (see *note 
3.9.4::)
+       Control.Seize      --  an entry of a protected object    (see *note 
9.4::)
+       Pool(K).Write      --  an entry of the task Pool(K)    (see *note 9.4::)
+
+18
+Examples of expanded names:
+
+19
+       Key_Manager."<"      --  an operator of the visible part of a package   
 (see *note 7.3.1::)
+       Dot_Product.Sum      --  a variable declared in a function body    (see 
*note 6.1::)
+       Buffer.Pool          --  a variable declared in a protected unit    
(see *note 9.11::)
+       Buffer.Read          --  an entry of a protected unit    (see *note 
9.11::)
+       Swap.Temp            --  a variable declared in a block statement    
(see *note 5.6::)
+       Standard.Boolean     --  the name of a predefined type    (see *note 
A.1::)
+
+                        _Extensions to Ada 83_
+
+19.a
+          We now allow an expanded name to use a prefix that denotes a
+          rename of a package, even if the selector is for an entity
+          local to the body or private part of the package, so long as
+          the entity is visible at the place of the reference.  This
+          eliminates a preexisting anomaly where references in a package
+          body may refer to declarations of its visible part but not
+          those of its private part or body when the prefix is a rename
+          of the package.
+
+                     _Wording Changes from Ada 83_
+
+19.b
+          The syntax rule for selector_name is new.  It is used in
+          places where visibility, but not necessarily direct
+          visibility, is required.  See *note 4.1::, "*note 4.1:: Names"
+          for more information.
+
+19.c
+          The description of dereferencing an access type has been moved
+          to *note 4.1::, "*note 4.1:: Names"; name.all is no longer
+          considered a selected_component.
+
+19.d
+          The rules have been restated to be consistent with our new
+          terminology, to accommodate class-wide types, etc.
+
+                        _Extensions to Ada 95_
+
+19.e/2
+          {AI95-00252-01AI95-00252-01} The prefixed view notation for
+          tagged objects is new.  This provides a similar notation to
+          that used in other popular languages, and also reduces the
+          need for use_clauses.  This is sometimes known as
+          "distinguished receiver notation".  
+
+19.f/2
+          Given the following definitions for a tagged type T:
+
+19.g/2
+               procedure Do_Something (Obj : in out T; Count : in Natural);
+               procedure Do_Something_Else (Obj : access T; Flag : in Boolean);
+               My_Object : aliased T;
+
+19.h/2
+          the following calls are equivalent:
+
+19.i/2
+               Do_Something (My_Object, Count => 10);
+               My_Object.Do_Something (Count => 10);
+
+19.j/2
+          as are the following calls:
+
+19.k/2
+               Do_Something_Else (My_Object'Access, Flag => True);
+               My_Object.Do_Something_Else (Flag => True);
+
+                    _Wording Changes from Ada 2005_
+
+19.l/3
+          {AI05-0090-1AI05-0090-1} Correction: Corrected the definition
+          of a prefixed view to ignore the implicit subprograms declared
+          for "implemented by" entries and protected subprograms.
+
+
+File: aarm2012.info,  Node: 4.1.4,  Next: 4.1.5,  Prev: 4.1.3,  Up: 4.1
+
+4.1.4 Attributes
+----------------
+
+1
+[An attribute is a characteristic of an entity that can be queried via
+an attribute_reference (*note 4.1.4: S0100.) or a
+range_attribute_reference (*note 4.1.4: S0102.).]
+
+                               _Syntax_
+
+2
+     attribute_reference ::= prefix'attribute_designator
+
+3/2
+     {AI05-0004-1AI05-0004-1} attribute_designator ::=
+         identifier[(static_expression)]
+       | Access | Delta | Digits | Mod
+
+4
+     range_attribute_reference ::= prefix'range_attribute_designator
+
+5
+     range_attribute_designator ::= Range[(static_expression)]
+
+                        _Name Resolution Rules_
+
+6
+In an attribute_reference, if the attribute_designator is for an
+attribute defined for (at least some) objects of an access type, then
+the prefix is never interpreted as an implicit_dereference; otherwise
+(and for all range_attribute_references), if the type of the name within
+the prefix is of an access type, the prefix is interpreted as an
+implicit_dereference.  Similarly, if the attribute_designator is for an
+attribute defined for (at least some) functions, then the prefix is
+never interpreted as a parameterless function_call; otherwise (and for
+all range_attribute_references), if the prefix consists of a name that
+denotes a function, it is interpreted as a parameterless function_call.
+
+6.a
+          Discussion: The first part of this rule is essentially a
+          "preference" against implicit dereference, so that it is
+          possible to ask for, say, 'Size of an access object, without
+          automatically getting the size of the object designated by the
+          access object.  This rule applies to 'Access,
+          'Unchecked_Access, 'Size, and 'Address, and any other
+          attributes that are defined for at least some access objects.
+
+6.b
+          The second part of this rule implies that, for a parameterless
+          function F, F'Address is the address of F, whereas F'Size is
+          the size of the anonymous constant returned by F.
+
+6.c/1
+          We normally talk in terms of expected type or profile for name
+          resolution rules, but we don't do this for attributes because
+          certain attributes are legal independent of the type or the
+          profile of the prefix.
+
+6.d/2
+          {AI95-00114-01AI95-00114-01} Other than the rules given above,
+          the Name Resolution Rules for the prefix of each attribute are
+          defined as Name Resolution Rules for that attribute.  If no
+          such rules are defined, then no context at all should be used
+          when resolving the prefix.  In particular, any knowledge about
+          the kind of entities required must not be used for resolution
+          unless that is required by Name Resolution Rules.  This
+          matters in obscure cases; for instance, given the following
+          declarations:
+
+6.e/2
+                 function Get_It return Integer is ... -- (1)
+                 function Get_It return Some_Record_Type is ... -- (2)
+
+6.f/2
+          the following attribute_reference cannot be resolved and is
+          illegal:
+
+6.g/2
+                 if Get_It'Valid then
+
+6.h/3
+          {AI05-0005-1AI05-0005-1} even though the Valid attribute is
+          only defined for objects of scalar types, and thus cannot be
+          applied to the result of function (2).  That information
+          cannot be used to resolve the prefix.  The same would be true
+          if (2) had been a procedure; even though the procedure does
+          not denote an object, the attribute_reference is still
+          illegal.
+
+7
+The expression, if any, in an attribute_designator or
+range_attribute_designator is expected to be of any integer type.
+
+                           _Legality Rules_
+
+8
+The expression, if any, in an attribute_designator or
+range_attribute_designator shall be static.
+
+                          _Static Semantics_
+
+9/3
+{AI05-0006-1AI05-0006-1} An attribute_reference denotes a value, an
+object, a subprogram, or some other kind of program entity.  For an
+attribute_reference that denotes a value or an object, if its type is
+scalar, then its nominal subtype is the base subtype of the type; if its
+type is tagged, its nominal subtype is the first subtype of the type;
+otherwise, its nominal subtype is a subtype of the type without any
+constraint or null_exclusion.  Similarly, unless explicitly specified
+otherwise, for an attribute_reference that denotes a function, when its
+result type is scalar, its result subtype is the base subtype of the
+type, when its result type is tagged, the result subtype is the first
+subtype of the type, and when the result type is some other type, the
+result subtype is a subtype of the type without any constraint or
+null_exclusion.
+
+9.a
+          Ramification: The attributes defined by the language are
+          summarized in *note K.2::.  Implementations can define
+          additional attributes.
+
+9.b/3
+          Discussion: {AI05-0006-1AI05-0006-1} The nominal subtype is
+          primarily a concern when an attribute_reference, or a call on
+          an attribute_reference, is used as the expression of a case
+          statement, due to the full coverage requirement based on the
+          nominal subtype.  For nondiscrete cases, we define the nominal
+          subtype mainly for completeness.  Implementations may specify
+          otherwise for implementation-defined attribute functions.
+
+9.c/3
+          The rule is written to match the meaning of the italicized T
+          in the definition of attributes such as Input; see *note
+          4.5.1::.
+
+9.d/3
+          To be honest: {AI05-0006-1AI05-0006-1} We don't worry about
+          the fact that "base subtype" is not explicitly defined for the
+          universal types.  Since it is not possible to constrain a
+          universal numeric type, all subtypes are unconstrained, and
+          hence can be considered base subtypes.  The wording above
+          could be altered to bypass this issue, but it doesn't seem
+          necessary, since universal integer is handled specially in the
+          rules for case expression full coverage, and we don't allow
+          user-defined functions for attribute functions whose result
+          type is universal.
+
+10
+[A range_attribute_reference X'Range(N) is equivalent to the range
+X'First(N) ..  X'Last(N), except that the prefix is only evaluated once.
+Similarly, X'Range is equivalent to X'First ..  X'Last, except that the
+prefix is only evaluated once.]
+
+                          _Dynamic Semantics_
+
+11
+The evaluation of an attribute_reference (or range_attribute_reference)
+consists of the evaluation of the prefix.
+
+                     _Implementation Permissions_
+
+12/1
+{8652/00158652/0015} {AI95-00093-01AI95-00093-01} An implementation may
+provide implementation-defined attributes; the identifier for an
+implementation-defined attribute shall differ from those of the
+language-defined attributes unless supplied for compatibility with a
+previous edition of this International Standard.
+
+12.a
+          Implementation defined: Implementation-defined attributes.
+
+12.b
+          Ramification: They cannot be reserved words because reserved
+          words are not legal identifiers.
+
+12.c
+          The semantics of implementation-defined attributes, and any
+          associated rules, are, of course, implementation defined.  For
+          example, the implementation defines whether a given
+          implementation-defined attribute can be used in a static
+          expression.
+
+12.c.1/1
+          {8652/00158652/0015} {AI95-00093-01AI95-00093-01}
+          Implementations are allowed to support the Small attribute for
+          floating types, as this was defined in Ada 83, even though the
+          name would conflict with a language-defined attribute.
+
+     NOTES
+
+13
+     4  Attributes are defined throughout this International Standard,
+     and are summarized in *note K.2::.
+
+14/2
+     5  {AI95-00235AI95-00235} In general, the name in a prefix of an
+     attribute_reference (or a range_attribute_reference) has to be
+     resolved without using any context.  However, in the case of the
+     Access attribute, the expected type for the attribute_reference has
+     to be a single access type, and the resolution of the name can use
+     the fact that the type of the object or the profile of the callable
+     entity denoted by the prefix has to match the designated type or be
+     type conformant with the designated profile of the access type.  
+
+14.a/2
+          Proof: {AI95-00235AI95-00235} In the general case, there is no
+          "expected type" for the prefix of an attribute_reference.  In
+          the special case of 'Access, there is an "expected type" or
+          "expected profile" for the prefix.
+
+14.b
+          Reason: 'Access is a special case, because without it, it
+          would be very difficult to take 'Access of an overloaded
+          subprogram.
+
+                              _Examples_
+
+15
+Examples of attributes:
+
+16
+     Color'First        -- minimum value of the enumeration type Color    (see 
*note 3.5.1::)
+     Rainbow'Base'First -- same as Color'First    (see *note 3.5.1::)
+     Real'Digits        -- precision of the type Real    (see *note 3.5.7::)
+     Board'Last(2)      -- upper bound of the second dimension of Board    
(see *note 3.6.1::)
+     Board'Range(1)     -- index range of the first dimension of Board    (see 
*note 3.6.1::)
+     Pool(K)'Terminated -- True if task Pool(K) is terminated    (see *note 
9.1::)
+     Date'Size          -- number of bits for records of type Date    (see 
*note 3.8::)
+     Message'Address    -- address of the record variable Message    (see 
*note 3.7.1::)
+
+                        _Extensions to Ada 83_
+
+16.a
+          We now uniformly treat X'Range as X'First..X'Last, allowing
+          its use with scalar subtypes.
+
+16.b
+          We allow any integer type in the static_expression of an
+          attribute designator, not just a value of universal_integer.
+          The preference rules ensure upward compatibility.
+
+                     _Wording Changes from Ada 83_
+
+16.c
+          We use the syntactic category attribute_reference rather than
+          simply "attribute" to avoid confusing the name of something
+          with the thing itself.
+
+16.d
+          The syntax rule for attribute_reference now uses identifier
+          instead of simple_name, because attribute identifiers are not
+          required to follow the normal visibility rules.
+
+16.e
+          We now separate attribute_reference from
+          range_attribute_reference, and enumerate the reserved words
+          that are legal attribute or range attribute designators.  We
+          do this because identifier no longer includes reserved words.
+
+16.f
+          The Ada 95 name resolution rules are a bit more explicit than
+          in Ada 83.  The Ada 83 rule said that 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."  That isn't quite right since
+          the meaning even in Ada 83 embodies whether or not the prefix
+          is interpreted as a parameterless function call, and in Ada
+          95, it also embodies whether or not the prefix is interpreted
+          as an implicit_dereference.  So the attribute designator does
+          make a difference -- just not much.
+
+16.g
+          Note however that if the attribute designator is Access, it
+          makes a big difference in the interpretation of the prefix
+          (see *note 3.10.2::).
+
+                     _Wording Changes from Ada 95_
+
+16.h/2
+          {8652/00158652/0015} {AI95-00093-01AI95-00093-01} Corrigendum:
+          The wording was changed to allow implementations to continue
+          to implement the Ada 83 Small attribute.  This was always
+          intended to be allowed.
+
+16.i/2
+          {AI95-00235-01AI95-00235-01} The note about resolving prefixes
+          of attributes was updated to reflect that the prefix of an
+          Access attribute now has an expected type (see *note
+          3.10.2::).
+
+                    _Wording Changes from Ada 2005_
+
+16.j/3
+          {AI05-0006-1AI05-0006-1} Correction: Defined the nominal
+          subtype of an attribute_reference to close a minor language
+          hole.
+
+
+File: aarm2012.info,  Node: 4.1.5,  Next: 4.1.6,  Prev: 4.1.4,  Up: 4.1
+
+4.1.5 User-Defined References
+-----------------------------
+
+                          _Static Semantics_
+
+1/3
+{AI05-0139-2AI05-0139-2} Given a discriminated type T, the following
+type-related operational aspect may be specified:
+
+2/3
+Implicit_Dereference
+               This aspect is specified by a name that denotes an access
+               discriminant declared for the type T.
+
+2.a/3
+          Aspect Description for Implicit_Dereference: Mechanism for
+          user-defined implicit .all.
+
+3/3
+{AI05-0139-2AI05-0139-2} A (view of a) type with a specified
+Implicit_Dereference aspect is a reference type.  A reference object is
+an object of a reference type.  The discriminant named by the
+Implicit_Dereference aspect is the reference discriminant of the
+reference type or reference object.  [A generalized_reference is a name
+that identifies a reference object, and denotes the object or subprogram
+designated by the reference discriminant of the reference object.]
+
+3.a.1/3
+          Glossary entry: A reference type is one that has user-defined
+          behavior for ".all", defined by the Implicit_Dereference
+          aspect.
+
+                               _Syntax_
+
+4/3
+     {AI05-0139-2AI05-0139-2} generalized_reference ::=
+     reference_object_name
+
+                        _Name Resolution Rules_
+
+5/3
+{AI05-0139-2AI05-0139-2} {AI05-0269-1AI05-0269-1} The expected type for
+the reference_object_name in a generalized_reference is any reference
+type.
+
+                          _Static Semantics_
+
+6/3
+{AI05-0139-2AI05-0139-2} A generalized_reference denotes a view
+equivalent to that of a dereference of the reference discriminant of the
+reference object.
+
+7/3
+{AI05-0139-2AI05-0139-2} Given a reference type T, the
+Implicit_Dereference aspect is inherited by descendants of type T if not
+overridden.  If a descendant type constrains the value of the reference
+discriminant of T by a new discriminant, that new discriminant is the
+reference discriminant of the descendant.  [If the descendant type
+constrains the value of the reference discriminant of T by an expression
+other than the name of a new discriminant, a generalized_reference that
+identifies an object of the descendant type denotes the object or
+subprogram designated by the value of this constraining expression.]
+
+                          _Dynamic Semantics_
+
+8/3
+{AI05-0139-2AI05-0139-2} The evaluation of a generalized_reference
+consists of the evaluation of the reference_object_name and a
+determination of the object or subprogram designated by the reference
+discriminant of the named reference object.  A check is made that the
+value of the reference discriminant is not the null access value.
+Constraint_Error is raised if this check fails.  The
+generalized_reference denotes the object or subprogram designated by the
+value of the reference discriminant of the named reference object.
+
+                              _Examples_
+
+9/3
+     {AI05-0268-1AI05-0268-1} type Barrel is tagged ...  -- holds objects of 
type Element
+
+10/3
+     {AI05-0139-2AI05-0139-2} {AI05-0299-2AI05-0299-2} type Ref_Element(Data : 
access Element) is limited private
+        with Implicit_Dereference => Data;
+           -- This Ref_Element type is a "reference" type.
+           -- "Data" is its reference discriminant.
+
+11/3
+     {AI05-0139-2AI05-0139-2} {AI05-0268-1AI05-0268-1} function Find (B : 
aliased in out Barrel; Key : String) return Ref_Element;
+        -- Return a reference to an element of a barrel.
+
+12/3
+     {AI05-0268-1AI05-0268-1} {AI05-0299-2AI05-0299-2} B: aliased Barrel;
+
+13/3
+     {AI05-0139-2AI05-0139-2} ...
+
+14/3
+     {AI05-0139-2AI05-0139-2} {AI05-0268-1AI05-0268-1} Find (B, "grape") := 
Element'(...);  -- Assign through a reference.
+
+15/3
+     {AI05-0139-2AI05-0139-2} {AI05-0268-1AI05-0268-1} -- This is equivalent 
to:
+     Find (B, "grape").Data.all := Element'(...);
+
+                       _Extensions to Ada 2005_
+
+15.a/3
+          {AI05-0139-2AI05-0139-2} The aspect Implicit_Dereference and
+          the generalized_reference are new.
+
+
+File: aarm2012.info,  Node: 4.1.6,  Prev: 4.1.5,  Up: 4.1
+
+4.1.6 User-Defined Indexing
+---------------------------
+
+                          _Static Semantics_
+
+1/3
+{AI05-0139-2AI05-0139-2} Given a tagged type T, the following
+type-related, operational aspects may be specified:
+
+2/3
+Constant_Indexing
+               This aspect shall be specified by a name that denotes one
+               or more functions declared immediately within the same
+               declaration list in which T is declared.  All such
+               functions shall have at least two parameters, the first
+               of which is of type T or T'Class, or is an
+               access-to-constant parameter with designated type T or
+               T'Class.
+
+2.a/3
+          Aspect Description for Constant_Indexing: Defines function(s)
+          to implement user-defined indexed_components.
+
+3/3
+Variable_Indexing
+               This aspect shall be specified by a name that denotes one
+               or more functions declared immediately within the same
+               declaration list in which T is declared.  All such
+               functions shall have at least two parameters, the first
+               of which is of type T or T'Class, or is an access
+               parameter with designated type T or T'Class.  All such
+               functions shall have a return type that is a reference
+               type (see *note 4.1.5::), whose reference discriminant is
+               of an access-to-variable type.
+
+3.a/3
+          Reason: We require these functions to return a reference type
+          so that the object returned from the function can act like a
+          variable.  We need no similar rule for Constant_Indexing,
+          since all functions return constant objects.
+
+3.b/3
+          Aspect Description for Variable_Indexing: Defines function(s)
+          to implement user-defined indexed_components.
+
+4/3
+These aspects are inherited by descendants of T (including the
+class-wide type T'Class).  [The aspects shall not be overridden, but the
+functions they denote may be.]
+
+4.a/3
+          Ramification: Indexing can be provided for multiple index
+          types by overloading routines with different parameter
+          profiles.  For instance, the map containers provide indexing
+          on both cursors and keys by providing pairs of overloaded
+          routines to the Constant_Indexing and Variable_Indexing
+          aspects.
+
+5/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} An indexable container
+type is (a view of) a tagged type with at least one of the aspects
+Constant_Indexing or Variable_Indexing specified.  An indexable
+container object is an object of an indexable container type.  [A
+generalized_indexing is a name that denotes the result of calling a
+function named by a Constant_Indexing or Variable_Indexing aspect.]
+
+5.a.1/3
+          Glossary entry: An indexable container type is one that has
+          user-defined behavior for indexing, via the Constant_Indexing
+          or Variable_Indexing aspects.
+
+                           _Legality Rules_
+
+6/3
+{AI05-0139-2AI05-0139-2} The Constant_Indexing or Variable_Indexing
+aspect shall not be specified:
+
+7/3
+   * on a derived type if the parent type has the corresponding aspect
+     specified or inherited; or
+
+8/3
+   * on a full_type_declaration if the type has a tagged partial view.
+
+9/3
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), these rules apply also in the private part of an instance of a
+generic unit.
+
+9.a/3
+          Ramification: In order to enforce these rules without breaking
+          privacy, we cannot allow a tagged private type to have hidden
+          indexing aspects.  There is no problem if the private type is
+          not tagged (as the indexing aspects cannot be specified on
+          descendants in that case).
+
+9.b/3
+          We don't need an assume-the-worst rule as deriving from formal
+          tagged type is not allowed in generic bodies.
+
+                               _Syntax_
+
+10/3
+     {AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1}
+     generalized_indexing ::= indexable_container_object_prefix 
+     actual_parameter_part
+
+                        _Name Resolution Rules_
+
+11/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} The expected type for
+the indexable_container_object_prefix of a generalized_indexing is any
+indexable container type.
+
+12/3
+{AI05-0139-2AI05-0139-2} {AI05-0292-1AI05-0292-1} If the
+Constant_Indexing aspect is specified for the type of the
+indexable_container_object_prefix of a generalized_indexing, then the
+generalized_indexing is interpreted as a constant indexing under the
+following circumstances:
+
+13/3
+   * when the Variable_Indexing aspect is not specified for the type of
+     the indexable_container_object_prefix;
+
+14/3
+   * when the indexable_container_object_prefix denotes a constant;
+
+15/3
+   * when the generalized_indexing is used within a primary where a name
+     denoting a constant is permitted.
+
+15.a/3
+          Ramification: This means it is not interpreted as a constant
+          indexing for the variable_name in the LHS of an assignment
+          (not inside a primary), nor for the name used for an out or in
+          out parameter (not allowed to be a constant), nor for the name
+          in an object renaming (not inside a primary), unless there is
+          no Variable_Indexing aspect defined.
+
+16/3
+Otherwise, the generalized_indexing is interpreted as a variable
+indexing.
+
+17/3
+When a generalized_indexing is interpreted as a constant (or variable)
+indexing, it is equivalent to a call on a prefixed view of one of the
+functions named by the Constant_Indexing (or Variable_Indexing) aspect
+of the type of the indexable_container_object_prefix with the given
+actual_parameter_part, and with the indexable_container_object_prefix as
+the prefix of the prefixed view.
+
+17.a/3
+          Ramification: In other words, the generalized_indexing is
+          equivalent to:
+
+17.b/3
+               indexable_container_object_prefix.Indexing actual_parameter_part
+
+17.c/3
+          where Indexing is the name specified for the Constant_Indexing
+          or Variable_Indexing aspect.
+
+                              _Examples_
+
+18/3
+     {AI05-0268-1AI05-0268-1} {AI05-0292-1AI05-0292-1} type Indexed_Barrel is 
tagged ...
+       with Variable_Indexing => Find;
+       -- Indexed_Barrel is an indexable container type,
+       -- Find is the generalized indexing operation.
+
+19/3
+     {AI05-0268-1AI05-0268-1} function Find (B : aliased in out 
Indexed_Barrel; Key : String) return Ref_Element;
+        -- Return a reference to an element of a barrel (see *note 4.1.5::).
+
+20/3
+     {AI05-0268-1AI05-0268-1} IB: aliased Indexed_Barrel;
+
+21/3
+     {AI05-0268-1AI05-0268-1} -- All of the following calls are then 
equivalent:
+     Find (IB,"pear").Data.all := Element'(...); -- Traditional call
+     IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
+     IB.Find ("pear")          := Element'(...); -- Implicit dereference (see 
*note 4.1.5::)
+     IB      ("pear")          := Element'(...); -- Implicit indexing and 
dereference
+     IB      ("pear").Data.all := Element'(...); -- Implicit indexing only
+
+                       _Extensions to Ada 2005_
+
+21.a/3
+          {AI05-0139-2AI05-0139-2} Aspects Constant_Indexing and
+          Variable_Indexing, and the generalized_indexing syntax are
+          new.
+
+
+File: aarm2012.info,  Node: 4.2,  Next: 4.3,  Prev: 4.1,  Up: 4
+
+4.2 Literals
+============
+
+1
+[ A literal represents a value literally, that is, by means of notation
+suited to its kind.]  A literal is either a numeric_literal, a
+character_literal, the literal null, or a string_literal.  
+
+1.a
+          Discussion: An enumeration literal that is an identifier
+          rather than a character_literal is not considered a literal in
+          the above sense, because it involves no special notation
+          "suited to its kind."  It might more properly be called an
+          enumeration_identifier, except for historical reasons.
+
+                        _Name Resolution Rules_
+
+2/2
+This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+
+3
+For a name that consists of a character_literal, either its expected
+type shall be a single character type, in which case it is interpreted
+as a parameterless function_call that yields the corresponding value of
+the character type, or its expected profile shall correspond to a
+parameterless function with a character result type, in which case it is
+interpreted as the name of the corresponding parameterless function
+declared as part of the character type's definition (see *note 3.5.1::).
+In either case, the character_literal denotes the
+enumeration_literal_specification.
+
+3.a
+          Discussion: See *note 4.1.3:: for the resolution rules for a
+          selector_name that is a character_literal.
+
+4
+The expected type for a primary that is a string_literal shall be a
+single string type.
+
+                           _Legality Rules_
+
+5
+A character_literal that is a name shall correspond to a
+defining_character_literal of the expected type, or of the result type
+of the expected profile.
+
+6
+For each character of a string_literal with a given expected string
+type, there shall be a corresponding defining_character_literal of the
+component type of the expected string type.
+
+7/2
+This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+{AI95-00231-01AI95-00231-01}
+
+                          _Static Semantics_
+
+8/2
+{AI95-00230-01AI95-00230-01} An integer literal is of type
+universal_integer.  A real literal is of type universal_real.  The
+literal null is of type universal_access.
+
+                          _Dynamic Semantics_
+
+9
+The evaluation of a numeric literal, or the literal null, yields the
+represented value.
+
+10
+The evaluation of a string_literal that is a primary yields an array
+value containing the value of each character of the sequence of
+characters of the string_literal, as defined in *note 2.6::.  The bounds
+of this array value are determined according to the rules for
+positional_array_aggregates (see *note 4.3.3::), except that for a null
+string literal, the upper bound is the predecessor of the lower bound.
+
+11
+For the evaluation of a string_literal of type T, a check is made that
+the value of each character of the string_literal belongs to the
+component subtype of T. For the evaluation of a null string literal, a
+check is made that its lower bound is greater than the lower bound of
+the base range of the index type.  The exception Constraint_Error is
+raised if either of these checks fails.
+
+11.a
+          Ramification: The checks on the characters need not involve
+          more than two checks altogether, since one need only check the
+          characters of the string with the lowest and highest position
+          numbers against the range of the component subtype.
+
+     NOTES
+
+12
+     6  Enumeration literals that are identifiers rather than
+     character_literals follow the normal rules for identifiers when
+     used in a name (see *note 4.1:: and *note 4.1.3::).
+     Character_literals used as selector_names follow the normal rules
+     for expanded names (see *note 4.1.3::).
+
+                              _Examples_
+
+13
+Examples of literals:
+
+14
+     3.14159_26536    --  a real literal
+     1_345    --  an integer literal
+     'A'    --  a character literal
+     "Some Text"    --  a string literal 
+
+                    _Incompatibilities With Ada 83_
+
+14.a
+          Because character_literals are now treated like other
+          literals, in that they are resolved using context rather than
+          depending on direct visibility, additional qualification might
+          be necessary when passing a character_literal to an overloaded
+          subprogram.
+
+                        _Extensions to Ada 83_
+
+14.b
+          Character_literals are now treated analogously to null and
+          string_literals, in that they are resolved using context,
+          rather than their content; the declaration of the
+          corresponding defining_character_literal need not be directly
+          visible.
+
+                     _Wording Changes from Ada 83_
+
+14.c
+          Name Resolution rules for enumeration literals that are not
+          character_literals are not included anymore, since they are
+          neither syntactically nor semantically "literals" but are
+          rather names of parameterless functions.
+
+                        _Extensions to Ada 95_
+
+14.d/2
+          {AI95-00230-01AI95-00230-01} {AI95-00231-01AI95-00231-01} Null
+          now has type universal_access, which is similar to other
+          literals.  Null can be used with anonymous access types.
+
+
+File: aarm2012.info,  Node: 4.3,  Next: 4.4,  Prev: 4.2,  Up: 4
+
+4.3 Aggregates
+==============
+
+1
+[ An aggregate combines component values into a composite value of an
+array type, record type, or record extension.]  
+
+                               _Syntax_
+
+2
+     aggregate ::= record_aggregate | extension_aggregate | 
+     array_aggregate
+
+                        _Name Resolution Rules_
+
+3/2
+{AI95-00287-01AI95-00287-01} The expected type for an aggregate shall be
+a single array type, record type, or record extension.
+
+3.a
+          Discussion: See *note 8.6::, "*note 8.6:: The Context of
+          Overload Resolution" for the meaning of "shall be a single ...
+          type."
+
+3.b/3
+          Ramification: {AI05-0005-1AI05-0005-1} There are additional
+          rules for each kind of aggregate.  These aggregate rules are
+          additive; a legal expression needs to satisfy all of the
+          applicable rules.  That means the rule given here must be
+          satisfied even when it is syntactically possible to tell which
+          specific kind of aggregate is being used.
+
+                           _Legality Rules_
+
+4
+An aggregate shall not be of a class-wide type.
+
+4.a
+          Ramification: When the expected type in some context is
+          class-wide, an aggregate has to be explicitly qualified by the
+          specific type of value to be created, so that the expected
+          type for the aggregate itself is specific.
+
+4.b
+          Discussion: We used to disallow aggregates of a type with
+          unknown discriminants.  However, that was unnecessarily
+          restrictive in the case of an extension aggregate, and
+          irrelevant to a record aggregate (since a type that is legal
+          for a record aggregate could not possibly have unknown
+          discriminants) and to an array aggregate (the only specific
+          types that can have unknown discriminants are private types,
+          private extensions, and types derived from them).
+
+                          _Dynamic Semantics_
+
+5
+For the evaluation of an aggregate, an anonymous object is created and
+values for the components or ancestor part are obtained (as described in
+the subsequent subclause for each kind of the aggregate) and assigned
+into the corresponding components or ancestor part of the anonymous
+object.  Obtaining the values and the assignments occur in an arbitrary
+order.  The value of the aggregate is the value of this object.
+
+5.a
+          Discussion: The ancestor part is the set of components
+          inherited from the ancestor type.  The syntactic category
+          ancestor_part is the expression or subtype_mark that specifies
+          how the ancestor part of the anonymous object should be
+          initialized.
+
+5.b
+          Ramification: The assignment operations do the necessary value
+          adjustment, as described in *note 7.6::.  Note that the value
+          as a whole is not adjusted -- just the subcomponents (and
+          ancestor part, if any).  *note 7.6:: also describes when this
+          anonymous object is finalized.
+
+5.c
+          If the ancestor_part is a subtype_mark the Initialize
+          procedure for the ancestor type is applied to the ancestor
+          part after default-initializing it, unless the procedure is
+          abstract, as described in *note 7.6::.  The Adjust procedure
+          for the ancestor type is not called in this case, since there
+          is no assignment to the ancestor part as a whole.
+
+6
+If an aggregate is of a tagged type, a check is made that its value
+belongs to the first subtype of the type.  Constraint_Error is raised if
+this check fails.
+
+6.a
+          Ramification: This check ensures that no values of a tagged
+          type are ever outside the first subtype, as required for
+          inherited dispatching operations to work properly (see *note
+          3.4::).  This check will always succeed if the first subtype
+          is unconstrained.  This check is not extended to untagged
+          types to preserve upward compatibility.
+
+                        _Extensions to Ada 83_
+
+6.b
+          We now allow extension_aggregates.
+
+                     _Wording Changes from Ada 83_
+
+6.c
+          We have adopted new wording for expressing the rule that the
+          type of an aggregate shall be determinable from the outside,
+          though using the fact that it is nonlimited record (extension)
+          or array.
+
+6.d
+          An aggregate now creates an anonymous object.  This is
+          necessary so that controlled types will work (see *note
+          7.6::).
+
+                    _Incompatibilities With Ada 95_
+
+6.e/2
+          {AI95-00287-01AI95-00287-01} In Ada 95, a limited type is not
+          considered when resolving an aggregate.  Since Ada 2005 now
+          allows limited aggregates, we can have incompatibilities.  For
+          example:
+
+6.f/2
+               type Lim is limited
+                  record
+                     Comp: Integer;
+                  end record;
+
+6.g/2
+               type Not_Lim is
+                  record
+                     Comp: Integer;
+                  end record;
+
+6.h/2
+               procedure P(X: Lim);
+               procedure P(X: Not_Lim);
+
+6.i/2
+               P((Comp => 123)); -- Illegal in Ada 2005, legal in Ada 95
+
+6.j/2
+          The call to P is ambiguous in Ada 2005, while it would not be
+          ambiguous in Ada 95 as the aggregate could not have a limited
+          type.  Qualifying the aggregate will eliminate any ambiguity.
+          This construction would be rather confusing to a maintenance
+          programmer, so it should be avoided, and thus we expect it to
+          be rare.
+
+                        _Extensions to Ada 95_
+
+6.k/2
+          {AI95-00287-01AI95-00287-01} Aggregates can be of a limited
+          type.
+
+* Menu:
+
+* 4.3.1 ::    Record Aggregates
+* 4.3.2 ::    Extension Aggregates
+* 4.3.3 ::    Array Aggregates
+
+
+File: aarm2012.info,  Node: 4.3.1,  Next: 4.3.2,  Up: 4.3
+
+4.3.1 Record Aggregates
+-----------------------
+
+1
+[In a record_aggregate, a value is specified for each component of the
+record or record extension value, using either a named or a positional
+association.]
+
+                               _Syntax_
+
+2
+     record_aggregate ::= (record_component_association_list)
+
+3
+     record_component_association_list ::=
+         record_component_association {, record_component_association}
+       | null record
+
+4/2
+     {AI95-00287-01AI95-00287-01} record_component_association ::=
+         [component_choice_list =>] expression
+        | component_choice_list => <>
+
+5
+     component_choice_list ::=
+          component_selector_name {| component_selector_name}
+        | others
+
+6
+     A record_component_association (*note 4.3.1: S0109.) is a named
+     component association if it has a component_choice_list; otherwise,
+     it is a positional component association.  Any positional component
+     associations shall precede any named component associations.  If
+     there is a named association with a component_choice_list of
+     others, it shall come last.
+
+6.a
+          Discussion: These rules were implied by the BNF in an early
+          version of the RM9X, but it made the grammar harder to read,
+          and was inconsistent with how we handle discriminant
+          constraints.  Note that for array aggregates we still express
+          some of the rules in the grammar, but array aggregates are
+          significantly different because an array aggregate is either
+          all positional (with a possible others at the end), or all
+          named.
+
+7
+     In the record_component_association_list (*note 4.3.1: S0108.) for
+     a record_aggregate (*note 4.3.1: S0107.), if there is only one
+     association, it shall be a named association.
+
+7.a/3
+          Reason: {AI05-0264-1AI05-0264-1} Otherwise, the construct
+          would be interpreted as a parenthesized expression.  This is
+          considered a syntax rule, since it is relevant to overload
+          resolution.  We choose not to express it with BNF so we can
+          share the definition of record_component_association_list in
+          both record_aggregate and extension_aggregate.
+
+7.b
+          Ramification: The record_component_association_list of an
+          extension_aggregate does not have such a restriction.
+
+                        _Name Resolution Rules_
+
+8/2
+{AI95-00287-01AI95-00287-01} The expected type for a record_aggregate
+shall be a single record type or record extension.
+
+8.a
+          Ramification: This rule is used to resolve whether an
+          aggregate is an array_aggregate or a record_aggregate.  The
+          presence of a with is used to resolve between a
+          record_aggregate and an extension_aggregate.
+
+9
+For the record_component_association_list (*note 4.3.1: S0108.) of a
+record_aggregate (*note 4.3.1: S0107.), all components of the composite
+value defined by the aggregate are needed[; for the association list of
+an extension_aggregate, only those components not determined by the
+ancestor expression or subtype are needed (see *note 4.3.2::).]  Each
+selector_name (*note 4.1.3: S0099.) in a record_component_association
+(*note 4.3.1: S0109.) shall denote a needed component [(including
+possibly a discriminant)].
+
+9.a
+          Ramification: For the association list of a record_aggregate,
+          "needed components" includes every component of the composite
+          value, but does not include those in unchosen variants (see
+          AI83-309).  If there are variants, then the value specified
+          for the discriminant that governs them determines which
+          variant is chosen, and hence which components are needed.
+
+9.b
+          If an extension defines a new known_discriminant_part, then
+          all of its discriminants are needed in the component
+          association list of an extension aggregate for that type, even
+          if the discriminants have the same names and types as
+          discriminants of the type of the ancestor expression.  This is
+          necessary to ensure that the positions in the
+          record_component_association_list (*note 4.3.1: S0108.) are
+          well defined, and that discriminants that govern variant_parts
+          can be given by static expressions.
+
+10
+The expected type for the expression of a record_component_association
+(*note 4.3.1: S0109.) is the type of the associated component(s); the
+associated component(s) are as follows:
+
+11
+   * For a positional association, the component [(including possibly a
+     discriminant)] in the corresponding relative position (in the
+     declarative region of the type), counting only the needed
+     components;
+
+11.a
+          Ramification: This means that for an association list of an
+          extension_aggregate, only noninherited components are counted
+          to determine the position.
+
+11.b/3
+          {AI05-0005-1AI05-0005-1} For a derived type (including type
+          extensions), the order of declaration is defined in *note
+          3.4::, "*note 3.4:: Derived Types and Classes".  In
+          particular, all discriminants come first, regardless of
+          whether they are defined for the parent type or are newly
+          added to the derived type.
+
+12
+   * For a named association with one or more component_selector_names,
+     the named component(s);
+
+13
+   * For a named association with the reserved word others, all needed
+     components that are not associated with some previous association.
+
+                           _Legality Rules_
+
+14
+If the type of a record_aggregate is a record extension, then it shall
+be a descendant of a record type, through one or more record extensions
+(and no private extensions).
+
+15/3
+{AI05-0016-1AI05-0016-1} The reserved words null record may appear only
+if there are no components needed in a given
+record_component_association_list (*note 4.3.1: S0108.).
+
+15.a
+          Ramification: For example, "(null record)" is a
+          record_aggregate for a null record type.  Similarly, "(T'(A)
+          with null record)" is an extension_aggregate for a type
+          defined as a null record extension of T.
+
+15.b/3
+          {AI05-0016-1AI05-0016-1} If no components are needed and null
+          record is not used, the record_component_association (*note
+          4.3.1: S0109.) must necessarily be others => <>, as that is
+          the only record_component_association (*note 4.3.1: S0109.)
+          that does not require an associated component.
+
+16/3
+{AI95-00287-01AI95-00287-01} {AI05-0199-1AI05-0199-1} Each
+record_component_association other than an others choice with a <> shall
+have at least one associated component, and each needed component shall
+be associated with exactly one record_component_association (*note
+4.3.1: S0109.).  If a record_component_association (*note 4.3.1: S0109.)
+with an expression has two or more associated components, all of them
+shall be of the same type, or all of them shall be of anonymous access
+types whose subtypes statically match.
+
+16.a/2
+          Ramification: {AI95-00287-01AI95-00287-01} These rules apply
+          to an association with an others choice with an expression.
+          An others choice with a <> can match zero components or
+          several components with different types.
+
+16.b/2
+          Reason: {AI95-00287-01AI95-00287-01} Without these rules,
+          there would be no way to know what was the expected type for
+          the expression of the association.  Note that some of the
+          rules do not apply to <> associations, as we do not need to
+          resolve anything.  We allow others => <> to match no
+          components as this is similar to array aggregates.  That means
+          that (others => <>) always represents a default-initialized
+          record or array value.
+
+16.c
+          Discussion: AI83-00244 also requires that the expression shall
+          be legal for each associated component.  This is because even
+          though two components have the same type, they might have
+          different subtypes.  Therefore, the legality of the
+          expression, particularly if it is an array aggregate, might
+          differ depending on the associated component's subtype.
+          However, we have relaxed the rules on array aggregates
+          slightly for Ada 95, so the staticness of an applicable index
+          constraint has no effect on the legality of the array
+          aggregate to which it applies.  See *note 4.3.3::.  This was
+          the only case (that we know of) where a subtype provided by
+          context affected the legality of an expression.
+
+16.d
+          Ramification: The rule that requires at least one associated
+          component for each record_component_association implies that
+          there can be no extra associations for components that don't
+          exist in the composite value, or that are already determined
+          by the ancestor expression or subtype of an
+          extension_aggregate.
+
+16.e
+          The second part of the first sentence ensures that no needed
+          components are left out, nor specified twice.
+
+17/3
+{AI05-0220-1AI05-0220-1} The value of a discriminant that governs a
+variant_part P shall be given by a static expression, unless P is nested
+within a variant V that is not selected by the discriminant value
+governing the variant_part enclosing V.
+
+17.a
+          Ramification: This expression might either be given within the
+          aggregate itself, or in a constraint on the parent subtype in
+          a derived_type_definition for some ancestor of the type of the
+          aggregate.
+
+17.1/2
+{AI95-00287-01AI95-00287-01} A record_component_association for a
+discriminant without a default_expression shall have an expression
+rather than <>.
+
+17.b/2
+          Reason: A discriminant must always have a defined value, but
+          <> means uninitialized for a discrete type unless the
+          component has a default value.
+
+                          _Dynamic Semantics_
+
+18
+The evaluation of a record_aggregate consists of the evaluation of the
+record_component_association_list (*note 4.3.1: S0108.).
+
+19
+For the evaluation of a record_component_association_list (*note 4.3.1:
+S0108.), any per-object constraints (see *note 3.8::) for components
+specified in the association list are elaborated and any expressions are
+evaluated and converted to the subtype of the associated component.  Any
+constraint elaborations and expression evaluations (and conversions)
+occur in an arbitrary order, except that the expression for a
+discriminant is evaluated (and converted) prior to the elaboration of
+any per-object constraint that depends on it, which in turn occurs prior
+to the evaluation and conversion of the expression for the component
+with the per-object constraint.
+
+19.a
+          Ramification: The conversion in the first rule might raise
+          Constraint_Error.
+
+19.b
+          Discussion: This check in the first rule presumably happened
+          as part of the dependent compatibility check in Ada 83.
+
+19.1/2
+{AI95-00287-01AI95-00287-01} For a record_component_association with an
+expression, the expression defines the value for the associated
+component(s).  For a record_component_association with <>, if the
+component_declaration has a default_expression, that default_expression
+defines the value for the associated component(s); otherwise, the
+associated component(s) are initialized by default as for a stand-alone
+object of the component subtype (see *note 3.3.1::).
+
+20
+The expression of a record_component_association is evaluated (and
+converted) once for each associated component.
+
+20.a/3
+          Ramification: {AI05-0005-1AI05-0005-1} We don't need similar
+          language for <>, as we're considering the value of <> for each
+          individual component.  Each component has its own default
+          expression or its own default initialization (they can be
+          different for each component; the components even could have
+          different types), and each one has to be evaluated.  So there
+          is no need to repeat that.
+
+     NOTES
+
+21
+     7  For a record_aggregate with positional associations, expressions
+     specifying discriminant values appear first since the
+     known_discriminant_part is given first in the declaration of the
+     type; they have to be in the same order as in the
+     known_discriminant_part.
+
+                              _Examples_
+
+22
+Example of a record aggregate with positional associations:
+
+23
+     (4, July, 1776)                                       --  see *note 3.8:: 
+
+24
+Examples of record aggregates with named associations:
+
+25
+     (Day => 4, Month => July, Year => 1776)
+     (Month => July, Day => 4, Year => 1776)
+
+26
+     (Disk, Closed, Track => 5, Cylinder => 12)            --  see *note 
3.8.1::
+     (Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)
+
+27/2
+{AI95-00287-01AI95-00287-01} Examples of component associations with
+several choices:
+
+28
+     (Value => 0, Succ|Pred => new Cell'(0, null, null))    --  see *note 
3.10.1::
+
+29
+      --  The allocator is evaluated twice: Succ and Pred designate different 
cells
+
+29.1/2
+     (Value => 0, Succ|Pred => <>)    --  see *note 3.10.1::
+
+29.2/2
+      --  Succ and Pred will be set to null
+
+30
+Examples of record aggregates for tagged types (see *note 3.9:: and
+*note 3.9.1::):
+
+31
+     Expression'(null record)
+     Literal'(Value => 0.0)
+     Painted_Point'(0.0, Pi/2.0, Paint => Red)
+
+                        _Extensions to Ada 83_
+
+31.a
+          Null record aggregates may now be specified, via "(null
+          record)".  However, this syntax is more useful for null record
+          extensions in extension aggregates.
+
+                     _Wording Changes from Ada 83_
+
+31.b
+          Various AIs have been incorporated (AI83-00189, AI83-00244,
+          and AI83-00309).  In particular, Ada 83 did not explicitly
+          disallow extra values in a record aggregate.  Now we do.
+
+                        _Extensions to Ada 95_
+
+31.c/2
+          {AI95-00287-01AI95-00287-01} <> can be used in place of an
+          expression in a record_aggregate, default initializing the
+          component.
+
+                     _Wording Changes from Ada 95_
+
+31.d/2
+          {AI95-00287-01AI95-00287-01} Limited record_aggregates are
+          allowed (since all kinds of aggregates can now be limited, see
+          *note 4.3::).
+
+                   _Incompatibilities With Ada 2005_
+
+31.e/3
+          {AI05-0220-1AI05-0220-1} Correction: Corrected wording so that
+          the rule for discriminants governing variant_parts was not
+          effectively circular.  The change makes a few aggregates where
+          a nonstatic discriminant governs an empty variant_part
+          illegal.  However, most Ada implementations already enforce
+          some version of the new rule and already reject these
+          aggregates.  So it is unlikely that any incompatibility will
+          be noticed in practice.
+
+                       _Extensions to Ada 2005_
+
+31.f/3
+          {AI05-0016-1AI05-0016-1} Correction: Fixed the wording so that
+          others => <> can be used in place of null record.  This is
+          needed to avoid a generic contract issue for generic bodies:
+          we do not want to have to assume the worst to disallow others
+          => <> if the record type might be a null record.
+
+31.g/3
+          {AI05-0199-1AI05-0199-1} Correction: We now allow multiple
+          components with anonymous access types to be specified with a
+          single component association.  This is to be consistent with
+          the capabilities of a named access type.
+
+
+File: aarm2012.info,  Node: 4.3.2,  Next: 4.3.3,  Prev: 4.3.1,  Up: 4.3
+
+4.3.2 Extension Aggregates
+--------------------------
+
+1
+[An extension_aggregate specifies a value for a type that is a record
+extension by specifying a value or subtype for an ancestor of the type,
+followed by associations for any components not determined by the
+ancestor_part.]
+
+                     _Language Design Principles_
+
+1.a
+          The model underlying this syntax is that a record extension
+          can also be viewed as a regular record type with an ancestor
+          "prefix."  The record_component_association_list (*note 4.3.1:
+          S0108.) corresponds to exactly what would be needed if there
+          were no ancestor/prefix type.  The ancestor_part determines
+          the value of the ancestor/prefix.
+
+                               _Syntax_
+
+2
+     extension_aggregate ::=
+         (ancestor_part with record_component_association_list)
+
+3
+     ancestor_part ::= expression | subtype_mark
+
+                        _Name Resolution Rules_
+
+4/2
+{AI95-00287-01AI95-00287-01} The expected type for an
+extension_aggregate shall be a single type that is a record extension.
+If the ancestor_part is an expression, it is expected to be of any
+tagged type.
+
+4.a
+          Reason: We could have made the expected type T'Class where T
+          is the ultimate ancestor of the type of the aggregate, or we
+          could have made it even more specific than that.  However, if
+          the overload resolution rules get too complicated, the
+          implementation gets more difficult and it becomes harder to
+          produce good error messages.
+
+4.b/3
+          Ramification: {AI05-0005-1AI05-0005-1} This rule is additive
+          with the rule given in *note 4.3::.  That means the *note
+          4.3:: rule must be satisfied even though it is always
+          syntactically possible to tell that something is an extension
+          aggregate rather than another kind of aggregate.
+          Specifically, that means that an extension aggregate is
+          ambiguous if the context is overloaded on array and/or
+          untagged record types, even though those are never legal
+          contexts for an extension aggregate.  Thus, this rule acts
+          more like a Legality Rules than a Name Resolution Rules.
+
+                           _Legality Rules_
+
+5/3
+{AI95-00306-01AI95-00306-01} {AI05-0115-1AI05-0115-1} If the
+ancestor_part is a subtype_mark, it shall denote a specific tagged
+subtype.  If the ancestor_part is an expression, it shall not be
+dynamically tagged.  The type of the extension_aggregate shall be a
+descendant of the type of the ancestor_part (the ancestor type), through
+one or more record extensions (and no private extensions).  If the
+ancestor_part is a subtype_mark, the view of the ancestor type from
+which the type is descended (see *note 7.3.1::) shall not have unknown
+discriminants.
+
+5.a/2
+          Reason: {AI95-00306-01AI95-00306-01} The expression cannot be
+          dynamically tagged to prevent implicit "truncation" of a
+          dynamically-tagged value to the specific ancestor type.  This
+          is similar to the rules in *note 3.9.2::.
+
+5.1/3
+{AI05-0067-1AI05-0067-1} {AI05-0244-1AI05-0244-1} If the type of the
+ancestor_part is limited and at least one component is needed in the
+record_component_association_list, then the ancestor_part shall not be:
+
+5.2/3
+   * a call to a function with an unconstrained result subtype; nor
+
+5.3/3
+   * a parenthesized or qualified expression whose operand would violate
+     this rule; nor
+
+5.4/3
+   * a conditional_expression having at least one dependent_expression
+     that would violate this rule.
+
+5.b/3
+          Reason: {AI05-0067-1AI05-0067-1} {AI05-0244-1AI05-0244-1} This
+          restriction simplifies implementation, because it ensures that
+          either the caller or the callee knows the size to allocate for
+          the aggregate.  Without this restriction, information from
+          both caller and callee would have to be combined to determine
+          the appropriate size.
+
+5.c/3
+          {AI05-0067-1AI05-0067-1} The (F(...)  with null record) case
+          is exempt from this rule, because such extension aggregates
+          are created internally for inherited functions returning
+          null-extension types -- we can't very well make those illegal.
+          Moreover, we don't need the rule for null extensions, as the
+          result can simply use the space returned by the function call.
+
+                          _Static Semantics_
+
+6
+For the record_component_association_list (*note 4.3.1: S0108.) of an
+extension_aggregate (*note 4.3.2: S0111.), the only components needed
+are those of the composite value defined by the aggregate that are not
+inherited from the type of the ancestor_part (*note 4.3.2: S0112.), plus
+any inherited discriminants if the ancestor_part (*note 4.3.2: S0112.)
+is a subtype_mark (*note 3.2.2: S0028.) that denotes an unconstrained
+subtype.
+
+                          _Dynamic Semantics_
+
+7
+For the evaluation of an extension_aggregate, the
+record_component_association_list (*note 4.3.1: S0108.) is evaluated.
+If the ancestor_part is an expression, it is also evaluated; if the
+ancestor_part is a subtype_mark, the components of the value of the
+aggregate not given by the record_component_association_list (*note
+4.3.1: S0108.) are initialized by default as for an object of the
+ancestor type.  Any implicit initializations or evaluations are
+performed in an arbitrary order, except that the expression for a
+discriminant is evaluated prior to any other evaluation or
+initialization that depends on it.
+
+8/3
+{AI05-0282-1AI05-0282-1} If the type of the ancestor_part has
+discriminants and the ancestor_part is not a subtype_mark that denotes
+an unconstrained subtype, then a check is made that each discriminant
+determined by the ancestor_part has the value specified for a
+corresponding discriminant, if any, either in the
+record_component_association_list (*note 4.3.1: S0108.), or in the
+derived_type_definition for some ancestor of the type of the
+extension_aggregate.  Constraint_Error is raised if this check fails.
+
+8.a
+          Ramification: Corresponding and specified discriminants are
+          defined in *note 3.7::.  The rules requiring static
+          compatibility between new discriminants of a derived type and
+          the parent discriminant(s) they constrain ensure that at most
+          one check is required per discriminant of the ancestor
+          expression.
+
+8.b/3
+          {AI05-0282-1AI05-0282-1} The check needs to be made any time
+          that the ancestor is constrained; the source of the
+          discriminants or the constraints is irrelevant.
+
+     NOTES
+
+9
+     8  If all components of the value of the extension_aggregate are
+     determined by the ancestor_part, then the
+     record_component_association_list (*note 4.3.1: S0108.) is required
+     to be simply null record.
+
+10
+     9  If the ancestor_part is a subtype_mark, then its type can be
+     abstract.  If its type is controlled, then as the last step of
+     evaluating the aggregate, the Initialize procedure of the ancestor
+     type is called, unless the Initialize procedure is abstract (see
+     *note 7.6::).
+
+                              _Examples_
+
+11
+Examples of extension aggregates (for types defined in *note 3.9.1::):
+
+12
+     Painted_Point'(Point with Red)
+     (Point'(P) with Paint => Black)
+
+13
+     (Expression with Left => 1.2, Right => 3.4)
+     Addition'(Binop with null record)
+                  -- presuming Binop is of type Binary_Operation
+
+                        _Extensions to Ada 83_
+
+13.a
+          The extension aggregate syntax is new.
+
+                    _Incompatibilities With Ada 95_
+
+13.b/2
+          {AI95-00306-01AI95-00306-01} Amendment Correction: Eliminated
+          implicit "truncation" of a dynamically tagged value when it is
+          used as an ancestor expression.  If an aggregate includes such
+          an expression, it is illegal in Ada 2005.  Such aggregates are
+          thought to be rare; the problem can be fixed with a type
+          conversion to the appropriate specific type if it occurs.
+
+                     _Wording Changes from Ada 95_
+
+13.c/2
+          {AI95-00287-01AI95-00287-01} Limited extension_aggregates are
+          allowed (since all kinds of aggregates can now be limited, see
+          *note 4.3::).
+
+                    _Inconsistencies With Ada 2005_
+
+13.d/3
+          {AI05-0282-1AI05-0282-1} Correction: An extension_aggregate
+          with an ancestor_part whose discriminants are constrained and
+          inherited might now raise Constraint_Error if the aggregate's
+          type is constrained, while it was OK in Ada 2005.  In almost
+          all cases, this will make no difference as the constraint will
+          be checked by the immediately following use of the aggregate,
+          but it is possible to compare such an aggregate for equality;
+          in this case, no exception would be raised by Ada 2005, while
+          Ada 2012 will raise Constraint_Error.  This should be very
+          rare, and having the possibility means that the representation
+          of the aggregate type has to be able to support unconstrained
+          values of the type, even if the first subtype is constrained
+          and no such objects can be created any other way.
+
+                   _Incompatibilities With Ada 2005_
+
+13.e/3
+          {AI05-0067-1AI05-0067-1} Correction: A limited unconstrained
+          ancestor expression that is a function call is now illegal
+          unless the extension part is null.  Such aggregates were first
+          introduced in Ada 2005 and are very complex to implement as
+          they must be built-in-place with an unknown size; as such, it
+          is unlikely that they are implemented correctly in existing
+          compilers and thus not often used in existing code.
+
+13.f/3
+          {AI05-0115-1AI05-0115-1} Correction: An ancestor_part that is
+          a subtype with unknown discriminants is now explicitly
+          illegal.  Such a subtype should not be used to declare an
+          object, and the ancestor_part acts like an object.  The Ada 95
+          rules did not disallow such cases, so it is possible that code
+          exists that uses such an ancestor, but this should be rare.
+
+
+File: aarm2012.info,  Node: 4.3.3,  Prev: 4.3.2,  Up: 4.3
+
+4.3.3 Array Aggregates
+----------------------
+
+1
+[In an array_aggregate, a value is specified for each component of an
+array, either positionally or by its index.]  For a
+positional_array_aggregate, the components are given in increasing-index
+order, with a final others, if any, representing any remaining
+components.  For a named_array_aggregate, the components are identified
+by the values covered by the discrete_choices.
+
+                     _Language Design Principles_
+
+1.a/1
+          The rules in this subclause are based on terms and rules for
+          discrete_choice_lists defined in *note 3.8.1::, "*note 3.8.1::
+          Variant Parts and Discrete Choices".  For example, the
+          requirements that others come last and stand alone are found
+          there.
+
+                               _Syntax_
+
+2
+     array_aggregate ::=
+       positional_array_aggregate | named_array_aggregate
+
+3/2
+     {AI95-00287-01AI95-00287-01} positional_array_aggregate ::=
+         (expression, expression {, expression})
+       | (expression {, expression}, others => expression)
+       | (expression {, expression}, others => <>)
+
+4
+     named_array_aggregate ::=
+         (array_component_association {, array_component_association})
+
+5/2
+     {AI95-00287-01AI95-00287-01} array_component_association ::=
+         discrete_choice_list => expression
+       | discrete_choice_list => <>
+
+6
+An n-dimensional array_aggregate is one that is written as n levels of
+nested array_aggregates (or at the bottom level, equivalent
+string_literals).  For the multidimensional case (n >= 2) the
+array_aggregates (or equivalent string_literals) at the n-1 lower levels
+are called subaggregates of the enclosing n-dimensional array_aggregate.
+The expressions of the bottom level subaggregates (or of the
+array_aggregate itself if one-dimensional) are called the array
+component expressions of the enclosing n-dimensional array_aggregate.
+
+6.a
+          Ramification: Subaggregates do not have a type.  They
+          correspond to part of an array.  For example, with a matrix, a
+          subaggregate would correspond to a single row of the matrix.
+          The definition of "n-dimensional" array_aggregate applies to
+          subaggregates as well as aggregates that have a type.
+
+6.b
+          To be honest: An others choice is the reserved word others as
+          it appears in a positional_array_aggregate or as the
+          discrete_choice of the discrete_choice_list in an
+          array_component_association.
+
+                        _Name Resolution Rules_
+
+7/2
+{AI95-00287-01AI95-00287-01} The expected type for an array_aggregate
+(that is not a subaggregate) shall be a single array type.  The
+component type of this array type is the expected type for each array
+component expression of the array_aggregate.
+
+7.a/2
+          Ramification: {AI95-00287-01AI95-00287-01} We already require
+          a single array or record type or record extension for an
+          aggregate.  The above rule requiring a single array type (and
+          similar ones for record and extension aggregates) resolves
+          which kind of aggregate you have.
+
+8
+The expected type for each discrete_choice in any discrete_choice_list
+of a named_array_aggregate is the type of the corresponding index; the
+corresponding index for an array_aggregate that is not a subaggregate is
+the first index of its type; for an (n-m)-dimensional subaggregate
+within an array_aggregate of an n-dimensional type, the corresponding
+index is the index in position m+1.
+
+                           _Legality Rules_
+
+9
+An array_aggregate of an n-dimensional array type shall be written as an
+n-dimensional array_aggregate.
+
+9.a
+          Ramification: In an m-dimensional array_aggregate [(including
+          a subaggregate)], where m >= 2, each of the expressions has to
+          be an (m-1)-dimensional subaggregate.
+
+10
+An others choice is allowed for an array_aggregate only if an applicable
+index constraint applies to the array_aggregate.  [An applicable index
+constraint is a constraint provided by certain contexts where an
+array_aggregate is permitted that can be used to determine the bounds of
+the array value specified by the aggregate.]  Each of the following
+contexts (and none other) defines an applicable index constraint:
+
+11/2
+   * {AI95-00318-02AI95-00318-02} For an explicit_actual_parameter, an
+     explicit_generic_actual_parameter, the expression of a return
+     statement, the initialization expression in an object_declaration
+     (*note 3.3.1: S0032.), or a default_expression (*note 3.7: S0063.)
+     [(for a parameter or a component)], when the nominal subtype of the
+     corresponding formal parameter, generic formal parameter, function
+     return object, object, or component is a constrained array subtype,
+     the applicable index constraint is the constraint of the subtype;
+
+12
+   * For the expression of an assignment_statement where the name
+     denotes an array variable, the applicable index constraint is the
+     constraint of the array variable;
+
+12.a
+          Reason: This case is broken out because the constraint comes
+          from the actual subtype of the variable (which is always
+          constrained) rather than its nominal subtype (which might be
+          unconstrained).
+
+13
+   * For the operand of a qualified_expression whose subtype_mark
+     denotes a constrained array subtype, the applicable index
+     constraint is the constraint of the subtype;
+
+14
+   * For a component expression in an aggregate, if the component's
+     nominal subtype is a constrained array subtype, the applicable
+     index constraint is the constraint of the subtype;
+
+14.a
+          Discussion: Here, the array_aggregate with others is being
+          used within a larger aggregate.
+
+15/3
+   * {AI05-0147-1AI05-0147-1} For a parenthesized expression, the
+     applicable index constraint is that, if any, defined for the
+     expression;
+
+15.a
+          Discussion: RM83 omitted this case, presumably as an
+          oversight.  We want to minimize situations where an expression
+          becomes illegal if parenthesized.
+
+15.1/3
+   * {AI05-0147-1AI05-0147-1} For a conditional_expression, the
+     applicable index constraint for each dependent_expression is that,
+     if any, defined for the conditional_expression.
+
+16
+The applicable index constraint applies to an array_aggregate that
+appears in such a context, as well as to any subaggregates thereof.  In
+the case of an explicit_actual_parameter (or default_expression) for a
+call on a generic formal subprogram, no applicable index constraint is
+defined.
+
+16.a
+          Reason: This avoids generic contract model problems, because
+          only mode conformance is required when matching actual
+          subprograms with generic formal subprograms.
+
+17/3
+{AI05-0153-3AI05-0153-3} The discrete_choice_list of an
+array_component_association is allowed to have a discrete_choice that is
+a nonstatic choice_expression or that is a subtype_indication or range
+that defines a nonstatic or null range, only if it is the single
+discrete_choice of its discrete_choice_list, and there is only one
+array_component_association in the array_aggregate.
+
+17.a
+          Discussion: We now allow a nonstatic others choice even if
+          there are other array component expressions as well.
+
+18/3
+{AI05-0262-1AI05-0262-1} In a named_array_aggregate where all
+discrete_choices are static, no two discrete_choices are allowed to
+cover the same value (see *note 3.8.1::); if there is no others choice,
+the discrete_choices taken together shall exactly cover a contiguous
+sequence of values of the corresponding index type.
+
+18.a
+          Ramification: This implies that each component must be
+          specified exactly once.  See AI83-309.
+
+18.b/3
+          Reason: {AI05-0262-1AI05-0262-1} This has to apply even if
+          there is only one static discrete_choice; a single choice has
+          to represent a contiguous range (a subtype_mark with a static
+          predicate might represent a discontiguous set of values).  If
+          the (single) choice is a dynamic subtype, we don't need to
+          make this check as no predicates are allowed (see *note
+          3.2.4::) and thus the range has to be contiguous.
+
+19
+A bottom level subaggregate of a multidimensional array_aggregate of a
+given array type is allowed to be a string_literal only if the component
+type of the array type is a character type; each character of such a
+string_literal shall correspond to a defining_character_literal of the
+component type.
+
+                          _Static Semantics_
+
+20
+A subaggregate that is a string_literal is equivalent to one that is a
+positional_array_aggregate of the same length, with each expression
+being the character_literal for the corresponding character of the
+string_literal.
+
+                          _Dynamic Semantics_
+
+21
+The evaluation of an array_aggregate of a given array type proceeds in
+two steps:
+
+22
+     1.  Any discrete_choices of this aggregate and of its subaggregates
+     are evaluated in an arbitrary order, and converted to the
+     corresponding index type; 
+
+23
+     2.  The array component expressions of the aggregate are evaluated
+     in an arbitrary order and their values are converted to the
+     component subtype of the array type; an array component expression
+     is evaluated once for each associated component.  
+
+23.a
+          Ramification: Subaggregates are not separately evaluated.  The
+          conversion of the value of the component expressions to the
+          component subtype might raise Constraint_Error.
+
+23.b/3
+          {AI05-0005-1AI05-0005-1} We don't need to say that <> is
+          evaluated once for each component, as <> means that each
+          component is initialized by default.  That means that the
+          actions defined for default initialization are applied to each
+          component individually.  Initializing one component by default
+          and copying that to the others would be an incorrect
+          implementation in general (although it might be OK if the
+          default initialization is known to be constant).
+
+23.1/2
+{AI95-00287-01AI95-00287-01} Each expression in an
+array_component_association defines the value for the associated
+component(s).  For an array_component_association with <>, the
+associated component(s) are initialized by default as for a stand-alone
+object of the component subtype (see *note 3.3.1::).
+
+24
+The bounds of the index range of an array_aggregate [(including a
+subaggregate)] are determined as follows:
+
+25
+   * For an array_aggregate with an others choice, the bounds are those
+     of the corresponding index range from the applicable index
+     constraint;
+
+26
+   * For a positional_array_aggregate [(or equivalent string_literal)]
+     without an others choice, the lower bound is that of the
+     corresponding index range in the applicable index constraint, if
+     defined, or that of the corresponding index subtype, if not; in
+     either case, the upper bound is determined from the lower bound and
+     the number of expressions [(or the length of the string_literal)];
+
+27
+   * For a named_array_aggregate without an others choice, the bounds
+     are determined by the smallest and largest index values covered by
+     any discrete_choice_list.
+
+27.a
+          Reason: We don't need to say that each index value has to be
+          covered exactly once, since that is a ramification of the
+          general rule on aggregates that each component's value has to
+          be specified exactly once.
+
+28
+For an array_aggregate, a check is made that the index range defined by
+its bounds is compatible with the corresponding index subtype.
+
+28.a
+          Discussion: In RM83, this was phrased more explicitly, but
+          once we define "compatibility" between a range and a subtype,
+          it seems to make sense to take advantage of that definition.
+
+28.b
+          Ramification: The definition of compatibility handles the
+          special case of a null range, which is always compatible with
+          a subtype.  See AI83-00313.
+
+29/3
+{AI05-0037-1AI05-0037-1} For an array_aggregate with an others choice, a
+check is made that no expression or <> is specified for an index value
+outside the bounds determined by the applicable index constraint.
+
+29.a
+          Discussion: RM83 omitted this case, apparently through an
+          oversight.  AI83-00309 defines this as a dynamic check, even
+          though other Ada 83 rules ensured that this check could be
+          performed statically.  We now allow an others choice to be
+          dynamic, even if it is not the only choice, so this check now
+          needs to be dynamic, in some cases.  Also, within a generic
+          unit, this would be a nonstatic check in some cases.
+
+30
+For a multidimensional array_aggregate, a check is made that all
+subaggregates that correspond to the same index have the same bounds.
+
+30.a
+          Ramification: No array bounds "sliding" is performed on
+          subaggregates.
+
+30.b
+          Reason: If sliding were performed, it would not be obvious
+          which subaggregate would determine the bounds of the
+          corresponding index.
+
+31
+The exception Constraint_Error is raised if any of the above checks
+fail.
+
+     NOTES
+
+32/3
+     10  {AI05-0004-1AI05-0004-1} In an array_aggregate, positional
+     notation may only be used with two or more expressions; a single
+     expression in parentheses is interpreted as a parenthesized
+     expression.  A named_array_aggregate, such as (1 => X), may be used
+     to specify an array with a single component.
+
+                              _Examples_
+
+33
+Examples of array aggregates with positional associations:
+
+34
+     (7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
+     Table'(5, 8, 4, 1, others => 0)  --  see *note 3.6:: 
+
+35
+Examples of array aggregates with named associations:
+
+36
+     (1 .. 5 => (1 .. 8 => 0.0))      --  two-dimensional
+     (1 .. N => new Cell)             --  N new cells, in particular for N = 0
+
+37
+     Table'(2 | 4 | 10 => 1, others => 0)
+     Schedule'(Mon .. Fri => True,  others => False)  --  see *note 3.6::
+     Schedule'(Wed | Sun  => False, others => True)
+     Vector'(1 => 2.5)                                --  single-component 
vector
+
+38
+Examples of two-dimensional array aggregates:
+
+39
+     -- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see 
*note 3.6::):
+
+40
+     ((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))
+
+41
+Examples of aggregates as initial values:
+
+42
+     A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0);        -- A(1)=7, A(10)=0
+     B : Table := (2 | 4 | 10 => 1, others => 0);        -- B(1)=0, B(10)=1
+     C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, 
C'Last(2)=8
+
+43
+     D : Bit_Vector(M .. N) := (M .. N => True);         -- see *note 3.6::
+     E : Bit_Vector(M .. N) := (others => True);
+     F : String(1 .. 1) := (1 => 'F');  -- a one component aggregate: same as 
"F"
+
+44/2
+{AI95-00433-01AI95-00433-01} Example of an array aggregate with
+defaulted others choice and with an applicable index constraint provided
+by an enclosing record aggregate:
+
+45/2
+     Buffer'(Size => 50, Pos => 1, Value => String'('x', others => <>))  -- 
see *note 3.7::
+
+                    _Incompatibilities With Ada 83_
+
+45.a.1/1
+          In Ada 95, no applicable index constraint is defined for a
+          parameter in a call to a generic formal subprogram; thus, some
+          aggregates that are legal in Ada 83 are illegal in Ada 95.
+          For example:
+
+45.a.2/1
+               subtype S3 is String (1 .. 3);
+               ...
+               generic
+                  with function F (The_S3 : in S3) return Integer;
+               package Gp is
+                  I : constant Integer := F ((1 => '!', others => '?'));
+                      -- The aggregate is legal in Ada 83, illegal in Ada 95.
+               end Gp;
+
+45.a.3/1
+          This change eliminates generic contract model problems.
+
+                        _Extensions to Ada 83_
+
+45.a
+          We now allow "named with others" aggregates in all contexts
+          where there is an applicable index constraint, effectively
+          eliminating what was RM83-4.3.2(6).  Sliding never occurs on
+          an aggregate with others, because its bounds come from the
+          applicable index constraint, and therefore already match the
+          bounds of the target.
+
+45.b
+          The legality of an others choice is no longer affected by the
+          staticness of the applicable index constraint.  This
+          substantially simplifies several rules, while being slightly
+          more flexible for the user.  It obviates the rulings of
+          AI83-00244 and AI83-00310, while taking advantage of the
+          dynamic nature of the "extra values" check required by
+          AI83-00309.
+
+45.c
+          Named array aggregates are permitted even if the index type is
+          descended from a formal scalar type.  See *note 4.9:: and
+          AI83-00190.
+
+                     _Wording Changes from Ada 83_
+
+45.d
+          We now separate named and positional array aggregate syntax,
+          since, unlike other aggregates, named and positional
+          associations cannot be mixed in array aggregates (except that
+          an others choice is allowed in a positional array aggregate).
+
+45.e
+          We have also reorganized the presentation to handle
+          multidimensional and one-dimensional aggregates more
+          uniformly, and to incorporate the rulings of AI83-00019,
+          AI83-00309, etc.
+
+                        _Extensions to Ada 95_
+
+45.f/2
+          {AI95-00287-01AI95-00287-01} <> can be used in place of an
+          expression in an array_aggregate, default-initializing the
+          component.
+
+                     _Wording Changes from Ada 95_
+
+45.g/2
+          {AI95-00287-01AI95-00287-01} Limited array_aggregates are
+          allowed (since all kinds of aggregates can now be limited, see
+          *note 4.3::).
+
+45.h/2
+          {AI95-00318-02AI95-00318-02} Fixed aggregates to use the
+          subtype of the return object of a function, rather than the
+          result subtype, because they can be different for an
+          extended_return_statement, and we want to use the subtype
+          that's explicitly in the code at the point of the expression.
+
+                    _Inconsistencies With Ada 2005_
+
+45.i/3
+          {AI05-0037-1AI05-0037-1} Correction: Fixed so the check for
+          components outside of the array applies to both expressions
+          and <>s.  As <> was a new feature in Ada 2005, there should be
+          little existing code that depends on a <> component that is
+          specified outside of the array (and that is nonsense anyway,
+          that a compiler is likely to detect even without an explicit
+          language rule disallowing it).
+
+                    _Wording Changes from Ada 2005_
+
+45.j/3
+          {AI05-0147-1AI05-0147-1} Added a definition of the applicable
+          index constraint for conditional_expressions (which are new).
+
+
+File: aarm2012.info,  Node: 4.4,  Next: 4.5,  Prev: 4.3,  Up: 4
+
+4.4 Expressions
+===============
+
+1/3
+{AI05-0147-1AI05-0147-1} {AI05-0158-1AI05-0158-1}
+{AI05-0176-1AI05-0176-1} An expression is a formula that defines the
+computation or retrieval of a value.  In this International Standard,
+the term "expression" refers to a construct of the syntactic category
+expression or of any of the following categories: choice_expression,
+choice_relation, relation, simple_expression, term, factor, primary,
+conditional_expression, quantified_expression.  
+
+                               _Syntax_
+
+2
+     expression ::=
+          relation {and relation}    | relation {and then relation}
+        | relation {or relation}    | relation {or else relation}
+        | relation {xor relation}
+
+2.1/3
+     {AI05-0158-1AI05-0158-1} choice_expression ::=
+          choice_relation {and choice_relation}
+        | choice_relation {or choice_relation}
+        | choice_relation {xor choice_relation}
+        | choice_relation {and then choice_relation}
+        | choice_relation {or else choice_relation}
+
+2.2/3
+     {AI05-0158-1AI05-0158-1} choice_relation ::=
+          simple_expression [relational_operator simple_expression]
+
+3/3
+     {AI05-0158-1AI05-0158-1} relation ::=
+          simple_expression [relational_operator simple_expression]
+        | simple_expression [not] in membership_choice_list
+
+3.1/3
+     {AI05-0158-1AI05-0158-1} membership_choice_list ::=
+     membership_choice {| membership_choice}
+
+3.2/3
+     {AI05-0158-1AI05-0158-1} membership_choice ::= choice_expression | 
+     range | subtype_mark
+
+4
+     simple_expression ::= [unary_adding_operator] term {
+     binary_adding_operator term}
+
+5
+     term ::= factor {multiplying_operator factor}
+
+6
+     factor ::= primary [** primary] | abs primary | not primary
+
+7/3
+     {AI05-0003-1AI05-0003-1} {AI05-0147-1AI05-0147-1}
+     {AI05-0176-1AI05-0176-1} primary ::=
+        numeric_literal | null | string_literal | aggregate
+      | name | allocator | (expression)
+      | (conditional_expression) | (quantified_expression)
+
+                        _Name Resolution Rules_
+
+8
+A name used as a primary shall resolve to denote an object or a value.
+
+8.a
+          Discussion: This replaces RM83-4.4(3).  We don't need to
+          mention named numbers explicitly, because the name of a named
+          number denotes a value.  We don't need to mention attributes
+          explicitly, because attributes now denote (rather than yield)
+          values in general.  Also, the new wording allows attributes
+          that denote objects, which should always have been allowed (in
+          case the implementation chose to have such a thing).
+
+8.b
+          Reason: It might seem odd that this is an overload resolution
+          rule, but it is relevant during overload resolution.  For
+          example, it helps ensure that a primary that consists of only
+          the identifier of a parameterless function is interpreted as a
+          function_call rather than directly as a direct_name.
+
+                          _Static Semantics_
+
+9
+Each expression has a type; it specifies the computation or retrieval of
+a value of that type.
+
+                          _Dynamic Semantics_
+
+10
+The value of a primary that is a name denoting an object is the value of
+the object.
+
+                     _Implementation Permissions_
+
+11
+For the evaluation of a primary that is a name denoting an object of an
+unconstrained numeric subtype, if the value of the object is outside the
+base range of its type, the implementation may either raise
+Constraint_Error or return the value of the object.
+
+11.a/3
+          Ramification: {AI05-0299-1AI05-0299-1} This means that if
+          extra-range intermediates are used to hold the value of an
+          object of an unconstrained numeric subtype, a Constraint_Error
+          can be raised on a read of the object, rather than only on an
+          assignment to it.  Similarly, it means that computing the
+          value of an object of such a subtype can be deferred until the
+          first read of the object (presuming no side effects other than
+          failing an Overflow_Check are possible).  This permission is
+          over and above that provided by subclause *note 11.6::, since
+          this allows the Constraint_Error to move to a different
+          handler.
+
+11.b
+          Reason: This permission is intended to allow extra-range
+          registers to be used efficiently to hold parameters and local
+          variables, even if they might need to be transferred into
+          smaller registers for performing certain predefined
+          operations.
+
+11.c
+          Discussion: There is no need to mention other kinds of
+          primarys, since any Constraint_Error to be raised can be
+          "charged" to the evaluation of the particular kind of primary.
+
+                              _Examples_
+
+12
+Examples of primaries:
+
+13
+     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 
+
+14
+Examples of expressions:
+
+15/2
+     {AI95-00433-01AI95-00433-01} Volume                      -- primary
+     not Destroyed               -- factor
+     2*Line_Count                -- term
+     -4.0                        -- simple expression
+     -4.0 + A                    -- simple expression
+     B**2 - 4.0*A*C              -- simple expression
+     R*Sin([Unicode 952])*Cos([Unicode 966])             -- simple expression
+     Password(1 .. 3) = "Bwv"    -- relation
+     Count in Small_Int          -- relation
+     Count not in Small_Int      -- relation
+     Index = 0 or Item_Hit       -- expression
+     (Cold and Sunny) or Warm    -- expression (parentheses are required)
+     A**(B**C)                   -- expression (parentheses are required)
+
+                        _Extensions to Ada 83_
+
+15.a
+          In Ada 83, out parameters and their nondiscriminant
+          subcomponents are not allowed as primaries.  These
+          restrictions are eliminated in Ada 95.
+
+15.b
+          In various contexts throughout the language where Ada 83
+          syntax rules had simple_expression, the corresponding Ada 95
+          syntax rule has expression instead.  This reflects the
+          inclusion of modular integer types, which makes the logical
+          operators "and", "or", and "xor" more useful in expressions of
+          an integer type.  Requiring parentheses to use these operators
+          in such contexts seemed unnecessary and potentially confusing.
+          Note that the bounds of a range still have to be specified by
+          simple_expressions, since otherwise expressions involving
+          membership tests might be ambiguous.  Essentially, the
+          operation ".."  is of higher precedence than the logical
+          operators, and hence uses of logical operators still have to
+          be parenthesized when used in a bound of a range.
+
+                    _Wording Changes from Ada 2005_
+
+15.c/3
+          {AI05-0003-1AI05-0003-1} Moved qualified_expression from
+          primary to name (see *note 4.1::).  This allows the use of
+          qualified_expressions in more places.
+
+15.d/3
+          {AI05-0147-1AI05-0147-1} {AI05-0176-1AI05-0176-1} Added
+          conditional_expression and quantified_expression to primary.
+
+15.e/3
+          {AI05-0158-1AI05-0158-1} Expanded membership test syntax (see
+          *note 4.5.2::).
+
+
+File: aarm2012.info,  Node: 4.5,  Next: 4.6,  Prev: 4.4,  Up: 4
+
+4.5 Operators and Expression Evaluation
+=======================================
+
+1
+[ The language defines the following six categories of operators (given
+in order of increasing precedence).  The corresponding operator_symbols,
+and only those, can be used as designators in declarations of functions
+for user-defined operators.  See *note 6.6::, "*note 6.6:: Overloading
+of Operators".]
+
+                               _Syntax_
+
+2
+     logical_operator ::=     and | or  | xor
+
+3
+     relational_operator ::=     =   | /=  | <   | <= | > | >=
+
+4
+     binary_adding_operator ::=     +   | -   | &
+
+5
+     unary_adding_operator ::=     +   | -
+
+6
+     multiplying_operator ::=     *   | /   | mod | rem
+
+7
+     highest_precedence_operator ::=     **  | abs | not
+
+7.a
+          Discussion: Some of the above syntactic categories are not
+          used in other syntax rules.  They are just used for
+          classification.  The others are used for both classification
+          and parsing.
+
+                          _Static Semantics_
+
+8
+For a sequence of operators of the same precedence level, the operators
+are associated with their operands in textual order from left to right.
+Parentheses can be used to impose specific associations.
+
+8.a
+          Discussion: The left-associativity is not directly inherent in
+          the grammar of *note 4.4::, though in *note 1.1.4:: the
+          definition of the metasymbols {} implies left associativity.
+          So this could be seen as redundant, depending on how literally
+          one interprets the definition of the {} metasymbols.
+
+8.b
+          See the Implementation Permissions below regarding flexibility
+          in reassociating operators of the same precedence.
+
+9
+For each form of type definition, certain of the above operators are
+predefined; that is, they are implicitly declared immediately after the
+type definition.  For each such implicit operator declaration, the
+parameters are called Left and Right for binary operators; the single
+parameter is called Right for unary operators.  [An expression of the
+form X op Y, where op is a binary operator, is equivalent to a
+function_call of the form "op"(X, Y). An expression of the form op Y,
+where op is a unary operator, is equivalent to a function_call of the
+form "op"(Y). The predefined operators and their effects are described
+in subclauses *note 4.5.1:: through *note 4.5.6::.]
+
+                          _Dynamic Semantics_
+
+10
+[ The predefined operations on integer types either yield the
+mathematically correct result or raise the exception Constraint_Error.
+For implementations that support the Numerics Annex, the predefined
+operations on real types yield results whose accuracy is defined in
+*note Annex G::, or raise the exception Constraint_Error.  ]
+
+10.a
+          To be honest: Predefined operations on real types can
+          "silently" give wrong results when the Machine_Overflows
+          attribute is false, and the computation overflows.
+
+                     _Implementation Requirements_
+
+11
+The implementation of a predefined operator that delivers a result of an
+integer or fixed point type may raise Constraint_Error only if the
+result is outside the base range of the result type.
+
+12
+The implementation of a predefined operator that delivers a result of a
+floating point type may raise Constraint_Error only if the result is
+outside the safe range of the result type.
+
+12.a
+          To be honest: An exception is made for exponentiation by a
+          negative exponent in *note 4.5.6::.
+
+                     _Implementation Permissions_
+
+13
+For a sequence of predefined operators of the same precedence level (and
+in the absence of parentheses imposing a specific association), an
+implementation may impose any association of the operators with operands
+so long as the result produced is an allowed result for the
+left-to-right association, but ignoring the potential for failure of
+language-defined checks in either the left-to-right or chosen order of
+association.
+
+13.a
+          Discussion: Note that the permission to reassociate the
+          operands in any way subject to producing a result allowed for
+          the left-to-right association is not much help for most
+          floating point operators, since reassociation may introduce
+          significantly different round-off errors, delivering a result
+          that is outside the model interval for the left-to-right
+          association.  Similar problems arise for division with integer
+          or fixed point operands.
+
+13.b
+          Note that this permission does not apply to user-defined
+          operators.
+
+     NOTES
+
+14
+     11  The two operands of an expression of the form X op Y, where op
+     is a binary operator, are evaluated in an arbitrary order, as for
+     any function_call (see *note 6.4::).
+
+                              _Examples_
+
+15
+Examples of precedence:
+
+16
+     not Sunny or Warm    --  same as (not Sunny) or Warm
+     X > 4.0 and Y > 0.0  --  same as (X > 4.0) and (Y > 0.0)
+
+17
+     -4.0*A**2            --  same as -(4.0 * (A**2))
+     abs(1 + A) + B       --  same as (abs (1 + A)) + B
+     Y**(-3)              --  parentheses are necessary
+     A / B * C            --  same as (A/B)*C
+     A + (B + C)          --  evaluate B + C before adding it to A 
+
+                     _Wording Changes from Ada 83_
+
+17.a
+          We don't give a detailed definition of precedence, since it is
+          all implicit in the syntax rules anyway.
+
+17.b
+          The permission to reassociate is moved here from RM83-11.6(5),
+          so it is closer to the rules defining operator association.
+
+* Menu:
+
+* 4.5.1 ::    Logical Operators and Short-circuit Control Forms
+* 4.5.2 ::    Relational Operators and Membership Tests
+* 4.5.3 ::    Binary Adding Operators
+* 4.5.4 ::    Unary Adding Operators
+* 4.5.5 ::    Multiplying Operators
+* 4.5.6 ::    Highest Precedence Operators
+* 4.5.7 ::    Conditional Expressions
+* 4.5.8 ::    Quantified Expressions
+
+
+File: aarm2012.info,  Node: 4.5.1,  Next: 4.5.2,  Up: 4.5
+
+4.5.1 Logical Operators and Short-circuit Control Forms
+-------------------------------------------------------
+
+                        _Name Resolution Rules_
+
+1
+An expression consisting of two relations connected by and then or or
+else (a short-circuit control form) shall resolve to be of some boolean
+type; the expected type for both relations is that same boolean type.
+
+1.a
+          Reason: This rule is written this way so that overload
+          resolution treats the two operands symmetrically; the
+          resolution of overloading present in either one can benefit
+          from the resolution of the other.  Furthermore, the type
+          expected by context can help.
+
+                          _Static Semantics_
+
+2
+The following logical operators are predefined for every boolean type T,
+for every modular type T, and for every one-dimensional array type T
+whose component type is a boolean type: 
+
+3
+     function "and"(Left, Right : T) return T
+     function "or" (Left, Right : T) return T
+     function "xor"(Left, Right : T) return T
+
+3.a/2
+          This paragraph was deleted.{AI95-00145-01AI95-00145-01}
+
+3.b/2
+          Ramification: {AI95-00145-01AI95-00145-01} For these
+          operators, we are talking about the type without any
+          (interesting) subtype, and not some subtype with a constraint
+          or exclusion.  Since it's possible that there is no name for
+          the "uninteresting" subtype, we denote the type with an
+          italicized T. This applies to the italicized T in many other
+          predefined operators and attributes as well.
+
+3.c/2
+          {AI95-00145-01AI95-00145-01} In many cases, there is a subtype
+          with the correct properties available.  The italicized T
+          means:
+
+3.d/2
+             * T'Base, for scalars;
+
+3.e/2
+             * the first subtype of T, for tagged types;
+
+3.f/2
+             * a subtype of the type T without any constraint or null
+               exclusion, in other cases.
+
+3.g/2
+          Note that "without a constraint" is not the same as
+          unconstrained.  For instance, a record type with no
+          discriminant part is considered constrained; no subtype of it
+          has a constraint, but the subtype is still constrained.
+
+3.h/2
+          Thus, the last case often is the same as the first subtype of
+          T, but that isn't the case for constrained array types (where
+          the correct subtype is unconstrained) and for access types
+          with a null_exclusion (where the correct subtype does not
+          exclude null).
+
+3.i/2
+          This italicized T is used for defining operators and
+          attributes of the language.  The meaning is intended to be as
+          described here.
+
+4
+For boolean types, the predefined logical operators and, or, and xor
+perform the conventional operations of conjunction, inclusive
+disjunction, and exclusive disjunction, respectively.
+
+5
+For modular types, the predefined logical operators are defined on a
+bit-by-bit basis, using the binary representation of the value of the
+operands to yield a binary representation for the result, where zero
+represents False and one represents True.  If this result is outside the
+base range of the type, a final subtraction by the modulus is performed
+to bring the result into the base range of the type.
+
+6
+The logical operators on arrays are performed on a
+component-by-component basis on matching components (as for equality --
+see *note 4.5.2::), using the predefined logical operator for the
+component type.  The bounds of the resulting array are those of the left
+operand.
+
+                          _Dynamic Semantics_
+
+7
+The short-circuit control forms and then and or else deliver the same
+result as the corresponding predefined and and or operators for boolean
+types, except that the left operand is always evaluated first, and the
+right operand is not evaluated if the value of the left operand
+determines the result.
+
+8
+For the logical operators on arrays, a check is made that for each
+component of the left operand there is a matching component of the right
+operand, and vice versa.  Also, a check is made that each component of
+the result belongs to the component subtype.  The exception
+Constraint_Error is raised if either of the above checks fails.
+
+8.a
+          Discussion: The check against the component subtype is per
+          AI83-00535.
+
+     NOTES
+
+9
+     12  The conventional meaning of the logical operators is given by
+     the following truth table:
+
+10
+               A     B   (A and B)   (A or B)   (A xor B)
+
+             True     True     True     True     False
+             True     False    False    True     True
+             False    True     False    True     True
+             False    False    False    False    False
+
+                              _Examples_
+
+11
+Examples of logical operators:
+
+12
+     Sunny or Warm
+     Filter(1 .. 10) and Filter(15 .. 24)   --   see *note 3.6.1:: 
+
+13
+Examples of short-circuit control forms:
+
+14
+     Next_Car.Owner /= null and then Next_Car.Owner.Age > 25   --   see *note 
3.10.1::
+     N = 0 or else A(N) = Hit_Value
+
+
+File: aarm2012.info,  Node: 4.5.2,  Next: 4.5.3,  Prev: 4.5.1,  Up: 4.5
+
+4.5.2 Relational Operators and Membership Tests
+-----------------------------------------------
+
+1
+[ The equality operators = (equals) and /= (not equals) are predefined
+for nonlimited types.  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
+scalar types, and for discrete array types, that is, one-dimensional
+array types whose components are of a discrete type.
+
+1.a
+          Ramification: The equality operators are not defined for every
+          nonlimited type -- see below for the exact rule.
+
+2/3
+{AI05-0262-1AI05-0262-1} {AI05-0269-1AI05-0269-1} A membership test,
+using in or not in, determines whether or not a value belongs to any
+given subtype or range, is equal to any given value, has a tag that
+identifies a type that is covered by a given type, or is convertible to
+and has an accessibility level appropriate for a given access type.
+Membership tests are allowed for all types.]
+
+                        _Name Resolution Rules_
+
+3/3
+{AI95-00251-01AI95-00251-01} {AI05-0158-1AI05-0158-1} The tested type of
+a membership test is determined by the membership_choices of the
+membership_choice_list.  Either all membership_choices of the
+membership_choice_list shall resolve to the same type, which is the
+tested type; or each membership_choice shall be of an elementary type,
+and the tested type shall be covered by each of these elementary types.
+
+3.1/3
+{AI05-0158-1AI05-0158-1} If the tested type is tagged, then the
+simple_expression shall resolve to be of a type that is convertible (see
+*note 4.6::) to the tested type; if untagged, the expected type for the
+simple_expression is the tested type.  The expected type of a
+choice_expression in a membership_choice, and of a simple_expression of
+a range in a membership_choice, is the tested type of the membership
+operation.
+
+3.a/2
+          Reason: {AI95-00230-01AI95-00230-01} The part of the rule for
+          untagged types is stated in a way that ensures that operands
+          like a string literal are still legal as operands of a
+          membership test.
+
+3.b/2
+          {AI95-00251-01AI95-00251-01} The significance of "is
+          convertible to" is that we allow the simple_expression to be
+          of any class-wide type that could be converted to the tested
+          type, not just the one rooted at the tested type.  This
+          includes any class-wide type that covers the tested type,
+          along with class-wide interfaces in some cases.
+
+3.c/3
+          {AI05-0158-1AI05-0158-1} The special rule for determining the
+          tested type for elementary types is to allow numeric literals
+          in membership_choice_lists.  Without the rule, A in B | 1
+          would be illegal as B and 1 would have different types (the
+          literal having type universal integer).
+
+                           _Legality Rules_
+
+4
+For a membership test, if the simple_expression is of a tagged
+class-wide type, then the tested type shall be (visibly) tagged.
+
+4.a
+          Ramification: Untagged types covered by the tagged class-wide
+          type are not permitted.  Such types can exist if they are
+          descendants of a private type whose full type is tagged.  This
+          rule is intended to avoid confusion since such derivatives
+          don't have their "own" tag, and hence are indistinguishable
+          from one another at run time once converted to a covering
+          class-wide type.
+
+4.1/3
+{AI05-0158-1AI05-0158-1} If a membership test includes one or more
+choice_expressions and the tested type of the membership test is
+limited, then the tested type of the membership test shall have a
+visible primitive equality operator.
+
+4.b/3
+          Reason: {AI05-0158-1AI05-0158-1} A visible equality operator
+          is required in order to avoid breaking privacy; that is, we
+          don't want to depend on a hidden equality operator.
+
+                          _Static Semantics_
+
+5
+The result type of a membership test is the predefined type Boolean.
+
+6
+The equality operators are predefined for every specific type T that is
+not limited, and not an anonymous access type, with the following
+specifications:
+
+7
+     function "=" (Left, Right : T) return Boolean
+     function "/="(Left, Right : T) return Boolean
+
+7.1/2
+{AI95-00230-01AI95-00230-01} The following additional equality operators
+for the universal_access type are declared in package Standard for use
+with anonymous access types:
+
+7.2/2
+     function "=" (Left, Right : universal_access) return Boolean
+     function "/="(Left, Right : universal_access) return Boolean
+
+8
+The ordering operators are predefined for every specific scalar type T,
+and for every discrete array type T, with the following specifications:
+
+9
+     function "<" (Left, Right : T) return Boolean
+     function "<="(Left, Right : T) return Boolean
+     function ">" (Left, Right : T) return Boolean
+     function ">="(Left, Right : T) return Boolean
+
+                        _Name Resolution Rules_
+
+9.1/2
+{AI95-00230-01AI95-00230-01} {AI95-00420-01AI95-00420-01} At least one
+of the operands of an equality operator for universal_access shall be of
+a specific anonymous access type.  Unless the predefined equality
+operator is identified using an expanded name with prefix denoting the
+package Standard, neither operand shall be of an access-to-object type
+whose designated type is D or D'Class, where D has a user-defined
+primitive equality operator such that:
+
+9.2/2
+   * its result type is Boolean;
+
+9.3/3
+   * {AI05-0020-1AI05-0020-1} it is declared immediately within the same
+     declaration list as D or any partial or incomplete view of D; and
+
+9.4/2
+   * at least one of its operands is an access parameter with designated
+     type D.
+
+9.a/2
+          Reason: The first sentence prevents compatibility problems by
+          ensuring that these operators are not used for named access
+          types.  Also, universal access types do not count for the
+          purposes of this rule.  Otherwise, equality expressions like
+          (X = null) would be ambiguous for normal access types.
+
+9.b/2
+          The rest of the rule makes it possible to call (including a
+          dispatching call) user-defined "=" operators for anonymous
+          access-to-object types (they'd be hidden otherwise), and to
+          write user-defined "=" operations for anonymous access types
+          (by making it possible to see the universal operator using the
+          Standard prefix).
+
+9.c/2
+          Ramification: We don't need a similar rule for anonymous
+          access-to-subprogram types because they can't be primitive for
+          any type.  Note that any nonprimitive user-defined equality
+          operators still are hidden by the universal operators; they'll
+          have to be called with a package prefix, but they are likely
+          to be very uncommon.
+
+                           _Legality Rules_
+
+9.5/2
+{AI95-00230-01AI95-00230-01} At least one of the operands of the
+equality operators for universal_access shall be of type
+universal_access, or both shall be of access-to-object types, or both
+shall be of access-to-subprogram types.  Further:
+
+9.6/2
+   * When both are of access-to-object types, the designated types shall
+     be the same or one shall cover the other, and if the designated
+     types are elementary or array types, then the designated subtypes
+     shall statically match;
+
+9.7/2
+   * When both are of access-to-subprogram types, the designated
+     profiles shall be subtype conformant.
+
+9.d/2
+          Reason: We don't want to allow completely arbitrary
+          comparisons, as we don't want to insist that all access types
+          are represented in ways that are convertible to one another.
+          For instance, a compiler could use completely separate address
+          spaces or incompatible representations.  Instead, we allow
+          compares if there exists an access parameter to which both
+          operands could be converted.  Since the user could write such
+          an subprogram, and any reasonable meaning for "=" would allow
+          using it in such a subprogram, this doesn't impose any further
+          restrictions on Ada implementations.
+
+9.8/3
+{AI05-0123-1AI05-0123-1} If the profile of an explicitly declared
+primitive equality operator of an untagged record type is type
+conformant with that of the corresponding predefined equality operator,
+the declaration shall occur before the type is frozen.  In addition, if
+the untagged record type has a nonlimited partial view, then the
+declaration shall occur in the visible part of the enclosing package.
+In addition to the places where Legality Rules normally apply (see *note
+12.3::), this rule applies also in the private part of an instance of a
+generic unit.
+
+                          _Dynamic Semantics_
+
+10
+For discrete types, the predefined relational operators are defined in
+terms of corresponding mathematical operations on the position numbers
+of the values of the operands.
+
+11
+For real types, the predefined relational operators are defined in terms
+of the corresponding mathematical operations on the values of the
+operands, subject to the accuracy of the type.
+
+11.a
+          Ramification: For floating point types, the results of
+          comparing nearly equal values depends on the accuracy of the
+          implementation (see *note G.2.1::, "*note G.2.1:: Model of
+          Floating Point Arithmetic" for implementations that support
+          the Numerics Annex).
+
+11.b
+          Implementation Note: On a machine with signed zeros, if the
+          generated code generates both plus zero and minus zero, plus
+          and minus zero must be equal by the predefined equality
+          operators.
+
+12
+Two access-to-object values are equal if they designate the same object,
+or if both are equal to the null value of the access type.
+
+13
+Two access-to-subprogram values are equal if they are the result of the
+same evaluation of an Access attribute_reference, or if both are equal
+to the null value of the access type.  Two access-to-subprogram values
+are unequal if they designate different subprograms.  [It is unspecified
+whether two access values that designate the same subprogram but are the
+result of distinct evaluations of Access attribute_references are equal
+or unequal.]
+
+13.a
+          Reason: This allows each Access attribute_reference for a
+          subprogram to designate a distinct "wrapper" subprogram if
+          necessary to support an indirect call.
+
+14/3
+{AI05-0123-1AI05-0123-1} For a type extension, predefined equality is
+defined in terms of the primitive [(possibly user-defined)] equals
+operator for the parent type and for any components that have a record
+type in the extension part, and predefined equality for any other
+components not inherited from the parent type.
+
+14.a
+          Ramification: Two values of a type extension are not equal if
+          there is a variant_part in the extension part and the two
+          values have different variants present.  This is a
+          ramification of the requirement that a discriminant governing
+          such a variant_part has to be a "new" discriminant, and so has
+          to be equal in the two values for the values to be equal.
+          Note that variant_parts in the parent part need not match if
+          the primitive equals operator for the parent type considers
+          them equal.
+
+14.b/2
+          {AI95-00349-01AI95-00349-01} The full type extension's
+          operation is used for a private extension.  This follows as
+          only full types have parent types; the type specified in a
+          private extension is an ancestor, but not necessarily the
+          parent type.  For instance, in:
+
+14.c/2
+               with Pak1;
+               package Pak2 is
+                  type Typ3 is new Pak1.Typ1 with private;
+               private
+                  type Typ3 is new Pak1.Typ2 with null record;
+               end Pak2;
+  
+
+14.d/2
+          the parent type is Pak1.Typ2, not Pak1.Typ1, and the equality
+          operator of Pak1.Typ2 is used to create predefined equality
+          for Typ3.
+
+14.1/3
+{AI05-0123-1AI05-0123-1} For a derived type whose parent is an untagged
+record type, predefined equality is defined in terms of the primitive
+(possibly user-defined) equals operator of the parent type.
+
+14.e/3
+          Reason: This prevents predefined equality from reemerging in
+          generic units for untagged record types.  For other uses the
+          primitive equality is inherited and the inherited routine is
+          primitive.
+
+15/3
+{AI05-0123-1AI05-0123-1} For a private type, if its full type is a
+record type, predefined equality is defined in terms of the primitive
+equals operator of the full type; otherwise, predefined equality for the
+private type is that of its full type.
+
+16
+For other composite types, the predefined equality operators [(and
+certain other predefined operations on composite types -- see *note
+4.5.1:: and *note 4.6::)] are defined in terms of the corresponding
+operation on matching components, defined as follows:
+
+17
+   * For two composite objects or values of the same non-array type,
+     matching components are those that correspond to the same
+     component_declaration or discriminant_specification;
+
+18
+   * For two one-dimensional arrays of the same type, matching
+     components 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;
+
+19
+   * For two multidimensional arrays of the same type, matching
+     components are those whose index values match in successive index
+     positions.
+
+20
+The analogous definitions apply if the types of the two objects or
+values are convertible, rather than being the same.
+
+20.a
+          Discussion: Ada 83 seems to omit this part of the definition,
+          though it is used in array type conversions.  See *note 4.6::.
+
+21
+Given the above definition of matching components, the result of the
+predefined equals operator for composite types (other than for those
+composite types covered earlier) is defined as follows:
+
+22
+   * If there are no components, the result is defined to be True;
+
+23
+   * If there are unmatched components, the result is defined to be
+     False;
+
+24/3
+   * {AI05-0123-1AI05-0123-1} Otherwise, the result is defined in terms
+     of the primitive equals operator for any matching components that
+     are records, and the predefined equals for any other matching
+     components.
+
+24.a/3
+          Reason: {AI05-0123-1AI05-0123-1} This asymmetry between
+          components with and without a record type is necessary to
+          preserve most upward compatibility and corresponds with the
+          corresponding situation with generics, where the predefined
+          operations "reemerge" in a generic for non-record types, but
+          do not for record types.  Also, only tagged types support
+          user-defined assignment (see *note 7.6::), so only tagged
+          types can fully handle levels of indirection in the
+          implementation of the type.  For untagged types, one reason
+          for a user-defined equals operator might be to allow values
+          with different bounds or discriminants to compare equal in
+          certain cases.  When such values are matching components, the
+          bounds or discriminants will necessarily match anyway if the
+          discriminants of the enclosing values match.
+
+24.b
+          Ramification: Two null arrays of the same type are always
+          equal; two null records of the same type are always equal.
+
+24.c/3
+          {AI05-0123-1AI05-0123-1} Note that if a composite object has a
+          component of a floating point type, and the floating point
+          type has both a plus and minus zero, which are considered
+          equal by the predefined equality, then a block compare cannot
+          be used for the predefined composite equality.  Of course,
+          with user-defined equals operators for components that are
+          records, a block compare breaks down anyway, so this is not
+          the only special case that requires component-by-component
+          comparisons.  On a one's complement machine, a similar
+          situation might occur for integer types, since one's
+          complement machines typically have both a plus and minus
+          (integer) zero.
+
+24.d/2
+          To be honest: {AI95-00230-01AI95-00230-01} For a component
+          with an anonymous access type, "predefined equality" is that
+          defined for the universal_access type (anonymous access types
+          have no equality operators of their own).
+
+24.e/3
+          {AI05-0123-1AI05-0123-1} For a component with a record type T,
+          "the primitive equals operator" is the one with two parameters
+          of T which returns Boolean.  We're not talking about some
+          random other primitive function named "=".
+
+24.1/3
+{AI05-0123-1AI05-0123-1} If the primitive equals operator for an
+untagged record type is abstract, then Program_Error is raised at the
+point of any (implicit) call to that abstract subprogram.
+
+24.f/3
+          Reason: An explicit call to an abstract subprogram is illegal.
+          This rule is needed in order to define the effect of an
+          implicit call such as a call that is part of the predefined
+          equality operation for an enclosing composite type that has a
+          component of an untagged record type that has an abstract
+          primitive equals operator.  For tagged types, an abstract
+          primitive equals operator is only allowed for an abstract
+          type, and abstract types cannot be components, so this case
+          does not occur.
+
+24.2/1
+{8652/00168652/0016} {AI95-00123-01AI95-00123-01} For any composite
+type, the order in which "=" is called for components is unspecified.
+Furthermore, if the result can be determined before calling "=" on some
+components, it is unspecified whether "=" is called on those components.
+
+25
+The predefined "/=" operator gives the complementary result to the
+predefined "=" operator.
+
+25.a
+          Ramification: Furthermore, if the user defines an "=" operator
+          that returns Boolean, then a "/=" operator is implicitly
+          declared in terms of the user-defined "=" operator so as to
+          give the complementary result.  See *note 6.6::.
+
+26/3
+{AI05-0264-1AI05-0264-1} For a discrete array type, the predefined
+ordering operators correspond to lexicographic 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).
+
+26.1/3
+{AI05-0269-1AI05-0269-1} An individual membership test is the membership
+test of a single membership_choice.
+
+27/3
+{AI05-0158-1AI05-0158-1} For the evaluation of a membership test using
+in whose membership_choice_list has a single membership_choice, the
+simple_expression and the membership_choice are evaluated in an
+arbitrary order; the result is the result of the individual membership
+test for the membership_choice.
+
+27.1/3
+{AI05-0158-1AI05-0158-1} For the evaluation of a membership test using
+in whose membership_choice_list has more than one membership_choice, the
+simple_expression of the membership test is evaluated first and the
+result of the operation is equivalent to that of a sequence consisting
+of an individual membership test on each membership_choice combined with
+the short-circuit control form or else.
+
+27.a.1/3
+          Ramification: {AI05-0158-1AI05-0158-1} This equivalence
+          includes the evaluation of the membership_choices; evaluation
+          stops as soon as an individual choice evaluates to True.
+
+28/3
+{AI05-0158-1AI05-0158-1} {AI05-0269-1AI05-0269-1} An individual
+membership test yields the result True if:
+
+28.1/3
+   * {AI05-0158-1AI05-0158-1} {AI05-0264-1AI05-0264-1} The
+     membership_choice is a choice_expression, and the simple_expression
+     is equal to the value of the membership_choice.  If the tested type
+     is a record type or a limited type, the test uses the primitive
+     equality for the type; otherwise, the test uses predefined
+     equality.
+
+28.2/3
+   * {AI05-0153-3AI05-0153-3} {AI05-0158-1AI05-0158-1} The
+     membership_choice is a range and the value of the simple_expression
+     belongs to the given range.
+
+29/3
+   * {AI05-0153-3AI05-0153-3} {AI05-0158-1AI05-0158-1} The
+     membership_choice is a subtype_mark, the tested type is scalar, the
+     value of the simple_expression belongs to the range of the named
+     subtype, and the predicate of the named subtype evaluates to True.
+
+29.a/3
+          Ramification: {AI05-0153-3AI05-0153-3} The scalar membership
+          test only does a range check and a predicate check.  It does
+          not perform any other check, such as whether a value falls in
+          a "hole" of a "holey" enumeration type.  The Pos attribute
+          function can be used for that purpose.
+
+29.b
+          Even though Standard.Float is an unconstrained subtype, the
+          test "X in Float" will still return False (presuming the
+          evaluation of X does not raise Constraint_Error) when X is
+          outside Float'Range.
+
+30/3
+   * {AI95-00231-01AI95-00231-01} {AI05-0153-3AI05-0153-3}
+     {AI05-0158-1AI05-0158-1} The membership_choice is a subtype_mark,
+     the tested type is not scalar, the value of the simple_expression
+     satisfies any constraints of the named subtype, the predicate of
+     the named subtype evaluates to True, and:
+
+30.1/2
+             * {AI95-00231-01AI95-00231-01} if the type of the
+               simple_expression is class-wide, the value has a tag that
+               identifies a type covered by the tested type;
+
+30.a
+          Ramification: Note that the tag is not checked if the
+          simple_expression is of a specific type.
+
+30.2/3
+             * {AI95-00231-01AI95-00231-01} {AI05-0149-1AI05-0149-1} if
+               the tested type is an access type and the named subtype
+               excludes null, the value of the simple_expression is not
+               null;
+
+30.3/3
+             * {AI05-0149-1AI05-0149-1} if the tested type is a general
+               access-to-object type, the type of the simple_expression
+               is convertible to the tested type and its accessibility
+               level is no deeper than that of the tested type; further,
+               if the designated type of the tested type is tagged and
+               the simple_expression is nonnull, the tag of the object
+               designated by the value of the simple_expression is
+               covered by the designated type of the tested type.
+
+31/3
+{AI05-0264-1AI05-0264-1} Otherwise, the test yields the result False.
+
+32
+A membership test using not in gives the complementary result to the
+corresponding membership test using in.
+
+32.a/3
+          To be honest: {AI05-0158-1AI05-0158-1} X not in A | B | C is
+          intended to be exactly equivalent to not (X in A | B | C),
+          including the order of evaluation of the simple_expression and
+          membership_choices.
+
+                     _Implementation Requirements_
+
+32.1/1
+{8652/00168652/0016} {AI95-00123-01AI95-00123-01} For all nonlimited
+types declared in language-defined packages, the "=" and "/=" operators
+of the type shall behave as if they were the predefined equality
+operators for the purposes of the equality of composite types and
+generic formal types.
+
+32.a.1/3
+          Ramification: {AI95-00123-01AI95-00123-01}
+          {AI05-0123-1AI05-0123-1} If any language-defined types are
+          implemented with a user-defined "=" operator, then either the
+          full type must be a record type, or the compiler must use
+          "magic" to implement equality for this type.  A normal
+          user-defined "=" operator for a non-record type does not meet
+          this requirement.
+
+     NOTES
+
+33/2
+     This paragraph was deleted.{AI95-00230-01AI95-00230-01}
+
+34
+     13  If a composite 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 length of each dimension is
+     the same for both.
+
+                              _Examples_
+
+35
+Examples of expressions involving relational operators and membership
+tests:
+
+36
+     X /= Y
+
+37
+     "" < "A" and "A" < "Aa"     --  True
+     "Aa" < "B" and "A" < "A  "  --  True
+
+38/3
+     {AI05-0264-1AI05-0264-1} My_Car = null               -- True if My_Car 
has been set to null (see *note 3.10.1::)
+     My_Car = Your_Car           -- True if we both share the same car
+     My_Car.all = Your_Car.all   -- True if the two cars are identical
+
+39/3
+     {AI05-0158-1AI05-0158-1} N not in 1 .. 10            -- range membership 
test
+     Today in Mon .. Fri         -- range membership test
+     Today in Weekday            -- subtype membership test (see *note 3.5.1::)
+     Card in Clubs | Spades      -- list membership test (see *note 3.5.1::)
+     Archive in Disk_Unit        -- subtype membership test (see *note 3.8.1::)
+     Tree.all in Addition'Class  -- class membership test (see *note 3.9.1::)
+
+                        _Extensions to Ada 83_
+
+39.a
+          Membership tests can be used to test the tag of a class-wide
+          value.
+
+39.b
+          Predefined equality for a composite type is defined in terms
+          of the primitive equals operator for tagged components or the
+          parent part.
+
+                     _Wording Changes from Ada 83_
+
+39.c
+          The term "membership test" refers to the relation "X in S"
+          rather to simply the reserved word in or not in.
+
+39.d
+          We use the term "equality operator" to refer to both the =
+          (equals) and /= (not equals) operators.  Ada 83 referred to =
+          as the equality operator, and /= as the inequality operator.
+          The new wording is more consistent with the ISO 10646 name for
+          "=" (equals sign) and provides a category similar to "ordering
+          operator" to refer to both = and /=.
+
+39.e
+          We have changed the term "catenate" to "concatenate".
+
+                        _Extensions to Ada 95_
+
+39.f/2
+          {AI95-00230-01AI95-00230-01} {AI95-00420-01AI95-00420-01} The
+          universal_access equality operators are new.  They provide
+          equality operations (most importantly, testing against null)
+          for anonymous access types.
+
+                     _Wording Changes from Ada 95_
+
+39.g/2
+          {8652/00168652/0016} {AI95-00123-01AI95-00123-01} Corrigendum:
+          Wording was added to clarify that the order of calls (and
+          whether the calls are made at all) on "=" for components is
+          unspecified.  Also clarified that "=" must compose properly
+          for language-defined types.
+
+39.h/2
+          {AI95-00251-01AI95-00251-01} Memberships were adjusted to
+          allow interfaces which don't cover the tested type, in order
+          to be consistent with type conversions.
+
+                    _Inconsistencies With Ada 2005_
+
+39.i/3
+          {AI05-0123-1AI05-0123-1} User-defined untagged record equality
+          is now defined to compose and be used in generics.  Any code
+          which assumes that the predefined equality reemerges in
+          generics and in predefined equals for composite types could
+          fail.  However, it is much more likely that this change will
+          fix bugs, as the behavior that would be expected (the
+          user-defined "=" is used) will be true in more cases.
+
+39.j/3
+          {AI05-0123-1AI05-0123-1} If a composite type contains a
+          component of an untagged record type with an abstract equality
+          operation, calling "=" on the composite type will raise
+          Program_Error, while in the past a result will be returned
+          using the predefined equality.  This is quite possible in ASIS
+          programs; it will detect a bug in such programs but of course
+          the programs will need to be fixed before they will work.
+
+                   _Incompatibilities With Ada 2005_
+
+39.k/3
+          {AI05-0123-1AI05-0123-1} Late and hidden overriding of
+          equality for untagged record types is now prohibited.  This is
+          necessary to make composition of equality predictable.  It
+          should always be possible to move the overriding to an earlier
+          spot where it will be legal.
+
+                       _Extensions to Ada 2005_
+
+39.l/3
+          {AI05-0149-1AI05-0149-1} Membership tests for valid
+          accessibility levels and tag coverage by the designated type
+          for general access types are new.
+
+39.m/3
+          {AI05-0153-3AI05-0153-3} Membership tests now include a
+          predicate check.
+
+39.n/3
+          {AI05-0158-1AI05-0158-1} Membership tests now allow multiple
+          choices.
+
+                    _Wording Changes from Ada 2005_
+
+39.o/3
+          {AI05-0020-1AI05-0020-1} Correction: Wording was added to
+          clarify that universal_access "=" does not apply if an
+          appropriate operator is declared for a partial or incomplete
+          view of the designated type.  Otherwise, adding a partial or
+          incomplete view could make some "=" operators ambiguous.
+
+
+File: aarm2012.info,  Node: 4.5.3,  Next: 4.5.4,  Prev: 4.5.2,  Up: 4.5
+
+4.5.3 Binary Adding Operators
+-----------------------------
+
+                          _Static Semantics_
+
+1
+The binary adding operators + (addition) and - (subtraction) are
+predefined for every specific numeric type T with their conventional
+meaning.  They have the following specifications:
+
+2
+     function "+"(Left, Right : T) return T
+     function "-"(Left, Right : T) return T
+
+3
+The concatenation operators & are predefined for every nonlimited,
+one-dimensional array type T with component type C. They have the
+following specifications:
+
+4
+     function "&"(Left : T; Right : T) return T
+     function "&"(Left : T; Right : C) return T
+     function "&"(Left : C; Right : T) return T
+     function "&"(Left : C; Right : C) return T
+
+                          _Dynamic Semantics_
+
+5
+For the evaluation of a concatenation with result type T, if both
+operands are of type T, the result of the concatenation 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.  If the left
+operand is a null array, the result of the concatenation is the right
+operand.  Otherwise, the lower bound of the result is determined as
+follows:
+
+6
+   * If the ultimate ancestor of the array type was defined by a
+     constrained_array_definition, then the lower bound of the result is
+     that of the index subtype;
+
+6.a
+          Reason: This rule avoids Constraint_Error when using
+          concatenation on an array type whose first subtype is
+          constrained.
+
+7
+   * If the ultimate ancestor of the array type was defined by an
+     unconstrained_array_definition, then the lower bound of the result
+     is that of the left operand.
+
+8
+[The upper bound is determined by the lower bound and the length.]  A
+check is made that the upper bound of the result of the concatenation
+belongs to the range of the index subtype, unless the result is a null
+array.  Constraint_Error is raised if this check fails.
+
+9
+If either operand is of the component type C, the result of the
+concatenation is given by the above rules, using in place of such an
+operand an array having this operand as its only component (converted to
+the component subtype) and having the lower bound of the index subtype
+of the array type as its lower bound.  
+
+9.a
+          Ramification: The conversion might raise Constraint_Error.
+          The conversion provides "sliding" for the component in the
+          case of an array-of-arrays, consistent with the normal Ada 95
+          rules that allow sliding during parameter passing.
+
+10
+The result of a concatenation is defined in terms of an assignment to an
+anonymous object, as for any function call (see *note 6.5::).
+
+10.a
+          Ramification: This implies that value adjustment is performed
+          as appropriate -- see *note 7.6::.  We don't bother saying
+          this for other predefined operators, even though they are all
+          function calls, because this is the only one where it matters.
+          It is the only one that can return a value having controlled
+          parts.
+
+     NOTES
+
+11
+     14  As for all predefined operators on modular types, the binary
+     adding operators + and - on modular types include a final reduction
+     modulo the modulus if the result is outside the base range of the
+     type.
+
+11.a
+          Implementation Note: A full "modulus" operation need not be
+          performed after addition or subtraction of modular types.  For
+          binary moduli, a simple mask is sufficient.  For nonbinary
+          moduli, a check after addition to see if the value is greater
+          than the high bound of the base range can be followed by a
+          conditional subtraction of the modulus.  Conversely, a check
+          after subtraction to see if a "borrow" was performed can be
+          followed by a conditional addition of the modulus.
+
+                              _Examples_
+
+12
+Examples of expressions involving binary adding operators:
+
+13
+     Z + 0.1      --  Z has to be of a real type 
+
+14
+     "A" & "BCD"  --  concatenation of two string literals
+     'A' & "BCD"  --  concatenation of a character literal and a string literal
+     'A' & 'A'    --  concatenation of two character literals 
+
+                     _Inconsistencies With Ada 83_
+
+14.a
+          The lower bound of the result of concatenation, for a type
+          whose first subtype is constrained, is now that of the index
+          subtype.  This is inconsistent with Ada 83, but generally only
+          for Ada 83 programs that raise Constraint_Error.  For example,
+          the concatenation operator in
+
+14.b
+               X : array(1..10) of Integer;
+               begin
+               X := X(6..10) & X(1..5);
+
+14.c
+          would raise Constraint_Error in Ada 83 (because the bounds of
+          the result of the concatenation would be 6..15, which is
+          outside of 1..10), but would succeed and swap the halves of X
+          (as expected) in Ada 95.
+
+                        _Extensions to Ada 83_
+
+14.d
+          Concatenation is now useful for array types whose first
+          subtype is constrained.  When the result type of a
+          concatenation is such an array type, Constraint_Error is
+          avoided by effectively first sliding the left operand (if
+          nonnull) so that its lower bound is that of the index subtype.
+
+
+File: aarm2012.info,  Node: 4.5.4,  Next: 4.5.5,  Prev: 4.5.3,  Up: 4.5
+
+4.5.4 Unary Adding Operators
+----------------------------
+
+                          _Static Semantics_
+
+1
+The unary adding operators + (identity) and - (negation) are predefined
+for every specific numeric type T with their conventional meaning.  They
+have the following specifications:
+
+2
+     function "+"(Right : T) return T
+     function "-"(Right : T) return T
+
+     NOTES
+
+3
+     15  For modular integer types, the unary adding operator -, when
+     given a nonzero operand, returns the result of subtracting the
+     value of the operand from the modulus; for a zero operand, the
+     result is zero.
+
+
+File: aarm2012.info,  Node: 4.5.5,  Next: 4.5.6,  Prev: 4.5.4,  Up: 4.5
+
+4.5.5 Multiplying Operators
+---------------------------
+
+                          _Static Semantics_
+
+1
+The multiplying operators * (multiplication), / (division), mod
+(modulus), and rem (remainder) are predefined for every specific integer
+type T:
+
+2
+     function "*"  (Left, Right : T) return T
+     function "/"  (Left, Right : T) return T
+     function "mod"(Left, Right : T) return T
+     function "rem"(Left, Right : T) return T
+
+3
+Signed integer multiplication has its conventional meaning.
+
+4
+Signed integer division and remainder are defined by the relation:
+
+5
+     A = (A/B)*B + (A rem B)
+
+6
+where (A rem B) has the sign of A and an absolute value less than the
+absolute value of B. Signed integer division satisfies the identity:
+
+7
+     (-A)/B = -(A/B) = A/(-B)
+
+8/3
+{AI05-0260-1AI05-0260-1} The signed integer modulus operator is defined
+such that the result of A mod B is either zero, or has the sign of B and
+an absolute value less than the absolute value of B; in addition, for
+some signed integer value N, this result satisfies the relation:
+
+9
+     A = B*N + (A mod B)
+
+10
+The multiplying operators on modular types are defined in terms of the
+corresponding signed integer operators[, followed by a reduction modulo
+the modulus if the result is outside the base range of the type] [(which
+is only possible for the "*" operator)].
+
+10.a
+          Ramification: The above identity satisfied by signed integer
+          division is not satisfied by modular division because of the
+          difference in effect of negation.
+
+11
+Multiplication and division operators are predefined for every specific
+floating point type T:
+
+12
+     function "*"(Left, Right : T) return T
+     function "/"(Left, Right : T) return T
+
+13
+The following multiplication and division operators, with an operand of
+the predefined type Integer, are predefined for every specific fixed
+point type T:
+
+14
+     function "*"(Left : T; Right : Integer) return T
+     function "*"(Left : Integer; Right : T) return T
+     function "/"(Left : T; Right : Integer) return T
+
+15
+[All of the above multiplying operators are usable with an operand of an
+appropriate universal numeric type.]  The following additional
+multiplying operators for root_real are predefined[, and are usable when
+both operands are of an appropriate universal or root numeric type, and
+the result is allowed to be of type root_real, as in a
+number_declaration]:
+
+15.a
+          Ramification: These operators are analogous to the multiplying
+          operators involving fixed or floating point types where
+          root_real substitutes for the fixed or floating point type,
+          and root_integer substitutes for Integer.  Only values of the
+          corresponding universal numeric types are implicitly
+          convertible to these root numeric types, so these operators
+          are really restricted to use with operands of a universal
+          type, or the specified root numeric types.
+
+16
+     function "*"(Left, Right : root_real) return root_real
+     function "/"(Left, Right : root_real) return root_real
+
+17
+     function "*"(Left : root_real; Right : root_integer) return root_real
+     function "*"(Left : root_integer; Right : root_real) return root_real
+     function "/"(Left : root_real; Right : root_integer) return root_real
+
+18
+Multiplication and division between any two fixed point types are
+provided by the following two predefined operators:
+
+18.a
+          Ramification: Universal_fixed is the universal type for the
+          class of fixed point types, meaning that these operators take
+          operands of any fixed point types (not necessarily the same)
+          and return a result that is implicitly (or explicitly)
+          convertible to any fixed point type.
+
+19
+     function "*"(Left, Right : universal_fixed) return universal_fixed
+     function "/"(Left, Right : universal_fixed) return universal_fixed
+
+                        _Name Resolution Rules_
+
+19.1/2
+{AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} The above two
+fixed-fixed multiplying operators shall not be used in a context where
+the expected type for the result is itself universal_fixed [-- the
+context has to identify some other numeric type to which the result is
+to be converted, either explicitly or implicitly].  Unless the
+predefined universal operator is identified using an expanded name with
+prefix denoting the package Standard, an explicit conversion is required
+on the result when using the above fixed-fixed multiplication operator
+if either operand is of a type having a user-defined primitive
+multiplication operator such that:
+
+19.2/3
+   * {AI05-0020-1AI05-0020-1} {AI05-0209-1AI05-0209-1} it is declared
+     immediately within the same declaration list as the type or any
+     partial or incomplete view thereof; and
+
+19.3/2
+   * both of its formal parameters are of a fixed-point type.
+
+19.4/2
+{AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} A
+corresponding requirement applies to the universal fixed-fixed division
+operator.
+
+19.a/2
+          Discussion: The small of universal_fixed is infinitesimal; no
+          loss of precision is permitted.  However, fixed-fixed division
+          is impractical to implement when an exact result is required,
+          and multiplication will sometimes result in unanticipated
+          overflows in such circumstances, so we require an explicit
+          conversion to be inserted in expressions like A * B * C if A,
+          B, and C are each of some fixed point type.
+
+19.b/2
+          On the other hand, X := A * B; is permitted by this rule, even
+          if X, A, and B are all of different fixed point types, since
+          the expected type for the result of the multiplication is the
+          type of X, which is necessarily not universal_fixed.
+
+19.c/2
+          {AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} We
+          have made these into Name Resolution rules to ensure that
+          user-defined primitive fixed-fixed operators are not made
+          unusable due to the presence of these universal fixed-fixed
+          operators.  But we do allow these operators to be used if
+          prefixed by package Standard, so that they can be used in the
+          definitions of user-defined operators.
+
+Paragraph 20 was deleted.
+
+                          _Dynamic Semantics_
+
+21
+The multiplication and division operators for real types have their
+conventional meaning.  [For floating point types, the accuracy of the
+result is determined by the precision of the result type.  For decimal
+fixed point types, the result is truncated toward zero if the
+mathematical result is between two multiples of the small of the
+specific result type (possibly determined by context); for ordinary
+fixed point types, if the mathematical result is between two multiples
+of the small, it is unspecified which of the two is the result.  ]
+
+22
+The exception Constraint_Error is raised by integer division, rem, and
+mod if the right operand is zero.  [Similarly, for a real type T with
+T'Machine_Overflows True, division by zero raises Constraint_Error.]
+
+     NOTES
+
+23
+     16  For positive A and B, A/B is the quotient and A rem B is the
+     remainder when A is divided by B. The following relations are
+     satisfied by the rem operator:
+
+24
+               A  rem (-B) =   A rem B
+             (-A) rem   B  = -(A rem B)
+
+25
+     17  For any signed integer K, the following identity holds:
+
+26
+             A mod B   =   (A + K*B) mod B
+
+27
+     The relations between signed integer division, remainder, and
+     modulus are illustrated by the following table:
+
+28
+             A      B   A/B   A rem B  A mod B     A     B    A/B   A rem B   
A mod B
+
+29
+             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
+
+30
+             A      B   A/B   A rem B  A mod B     A     B    A/B   A rem B   
A mod B
+
+             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
+
+                              _Examples_
+
+31
+Examples of expressions involving multiplying operators:
+
+32
+     I : Integer := 1;
+     J : Integer := 2;
+     K : Integer := 3;
+
+33
+     X : Real := 1.0;                      --     see *note 3.5.7::
+     Y : Real := 2.0;
+
+34
+     F : Fraction := 0.25;                 --     see *note 3.5.9::
+     G : Fraction := 0.5;
+
+35
+     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.125     same as F, that is, Fraction
+
+     3*F               0.75      same as F, that is, Fraction
+     0.75*G            0.375     universal_fixed, implicitly convertible
+                                 to any fixed point type
+     Fraction(F*G)     0.125     Fraction, as stated by the conversion
+     Real(J)*Y         4.0       Real, the type of both operands after
+                                 conversion of J
+
+                    _Incompatibilities With Ada 83_
+
+35.a.1/2
+          {AI95-00364-01AI95-00364-01} {AI95-00420-01AI95-00420-01} The
+          universal fixed-fixed multiplying operators are now directly
+          available (see below).  Any attempt to use user-defined
+          fixed-fixed multiplying operators will be ambiguous with the
+          universal ones.  The only way to use the user-defined
+          operators is to fully qualify them in a prefix call.  This
+          problem was not documented during the design of Ada 95, and
+          has been mitigated by Ada 2005.
+
+                        _Extensions to Ada 83_
+
+35.a
+          Explicit conversion of the result of multiplying or dividing
+          two fixed point numbers is no longer required, provided the
+          context uniquely determines some specific fixed point result
+          type.  This is to improve support for decimal fixed point,
+          where requiring explicit conversion on every fixed-fixed
+          multiply or divide was felt to be inappropriate.
+
+35.b
+          The type universal_fixed is covered by universal_real, so real
+          literals and fixed point operands may be multiplied or divided
+          directly, without any explicit conversions required.
+
+                     _Wording Changes from Ada 83_
+
+35.c
+          We have used the normal syntax for function definition rather
+          than a tabular format.
+
+                    _Incompatibilities With Ada 95_
+
+35.d/2
+          {AI95-00364-01AI95-00364-01} We have changed the resolution
+          rules for the universal fixed-fixed multiplying operators to
+          remove the incompatibility with Ada 83 discussed above.  The
+          solution is to hide the universal operators in some
+          circumstances.  As a result, some legal Ada 95 programs will
+          require the insertion of an explicit conversion around a
+          fixed-fixed multiply operator.  This change is likely to catch
+          as many bugs as it causes, since it is unlikely that the user
+          wanted to use predefined operators when they had defined
+          user-defined versions.
+
+                    _Wording Changes from Ada 2005_
+
+35.e/3
+          {AI05-0020-1AI05-0020-1} {AI05-0209-1AI05-0209-1} Correction:
+          Wording was added to clarify that universal_fixed "*" and "/"
+          does not apply if an appropriate operator is declared for a
+          partial (or incomplete) view of the designated type.
+          Otherwise, adding a partial (or incomplete) view could make
+          some "*" and "/" operators ambiguous.
+
+35.f/3
+          {AI05-0260-1AI05-0260-1} Correction: The wording for the mod
+          operator was corrected so that a result of 0 does not have to
+          have "the sign of B" (which is impossible if B is negative).
+
+
+File: aarm2012.info,  Node: 4.5.6,  Next: 4.5.7,  Prev: 4.5.5,  Up: 4.5
+
+4.5.6 Highest Precedence Operators
+----------------------------------
+
+                          _Static Semantics_
+
+1
+The highest precedence unary operator abs (absolute value) is predefined
+for every specific numeric type T, with the following specification:
+
+2
+     function "abs"(Right : T) return T
+
+3
+The highest precedence unary operator not (logical negation) is
+predefined for every boolean type T, every modular type T, and for every
+one-dimensional array type T whose components are of a boolean type,
+with the following specification:
+
+4
+     function "not"(Right : T) return T
+
+5
+The result of the operator not for a modular type is defined as the
+difference between the high bound of the base range of the type and the
+value of the operand.  [For a binary modulus, this corresponds to a
+bit-wise complement of the binary representation of the value of the
+operand.]
+
+6
+The operator not 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).  A check is made that each component of the
+result belongs to the component subtype; the exception Constraint_Error
+is raised if this check fails.
+
+6.a
+          Discussion: The check against the component subtype is per
+          AI83-00535.
+
+7
+The highest precedence exponentiation operator ** is predefined for
+every specific integer type T with the following specification:
+
+8
+     function "**"(Left : T; Right : Natural) return T
+
+9
+Exponentiation is also predefined for every specific floating point type
+as well as root_real, with the following specification (where T is
+root_real or the floating point type):
+
+10
+     function "**"(Left : T; Right : Integer'Base) return T
+
+11/3
+{AI05-0088-1AI05-0088-1} The right operand of an exponentiation is the
+exponent.  The value of X**N with the value of the exponent N positive
+is the same as the value of X*X*...X (with N-1 multiplications) except
+that the multiplications are associated in an arbitrary order.  With N
+equal to zero, the result is one.  With the value of N negative [(only
+defined for a floating point operand)], the result is the reciprocal of
+the result using the absolute value of N as the exponent.
+
+11.a
+          Ramification: The language does not specify the order of
+          association of the multiplications inherent in an
+          exponentiation.  For a floating point type, the accuracy of
+          the result might depend on the particular association order
+          chosen.
+
+                     _Implementation Permissions_
+
+12
+The implementation of exponentiation for the case of a negative exponent
+is allowed to raise Constraint_Error if the intermediate result of the
+repeated multiplications is outside the safe range of the type, even
+though the final result (after taking the reciprocal) would not be.
+(The best machine approximation to the final result in this case would
+generally be 0.0.)
+
+     NOTES
+
+13
+     18  As implied by the specification given above for exponentiation
+     of an integer type, a check is made that the exponent is not
+     negative.  Constraint_Error is raised if this check fails.
+
+                     _Inconsistencies With Ada 83_
+
+13.a.1/1
+          {8652/01008652/0100} {AI95-00018-01AI95-00018-01} The
+          definition of "**" allows arbitrary association of the
+          multiplications which make up the result.  Ada 83 required
+          left-to-right associations (confirmed by AI83-00137).  Thus it
+          is possible that "**" would provide a slightly different (and
+          more potentially accurate) answer in Ada 95 than in the same
+          Ada 83 program.
+
+                     _Wording Changes from Ada 83_
+
+13.a
+          We now show the specification for "**" for integer types with
+          a parameter subtype of Natural rather than Integer for the
+          exponent.  This reflects the fact that Constraint_Error is
+          raised if a negative value is provided for the exponent.
+
+                    _Wording Changes from Ada 2005_
+
+13.b/3
+          {AI05-0088-1AI05-0088-1} Correction: The equivalence
+          definition for "**" was corrected so that it does not imply
+          that the operands are evaluated multiple times.
+
+
+File: aarm2012.info,  Node: 4.5.7,  Next: 4.5.8,  Prev: 4.5.6,  Up: 4.5
+
+4.5.7 Conditional Expressions
+-----------------------------
+
+1/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1}
+{AI05-0262-1AI05-0262-1} A conditional_expression selects for evaluation
+at most one of the enclosed dependent_expressions, depending on a
+decision among the alternatives.  One kind of conditional_expression is
+the if_expression, which selects for evaluation a dependent_expression
+depending on the value of one or more corresponding conditions.  The
+other kind of conditional_expression is the case_expression, which
+selects for evaluation one of a number of alternative
+dependent_expressions; the chosen alternative is determined by the value
+of a selecting_expression.
+
+                     _Language Design Principles_
+
+1.a/3
+          {AI05-0188-1AI05-0188-1} As previously noted, there are two
+          kinds of conditional_expression, if_expressions and
+          case_expressions.  Whenever possible, we have written the
+          rules in terms of conditional_expressions to avoid
+          duplication.
+
+1.b/3
+          {AI05-0147-1AI05-0147-1} The rules for conditional_expressions
+          have been designed as much as possible to work similarly to a
+          parenthesized expression.  The intent is that as much as
+          possible, wherever a parenthesized expression would be
+          allowed, a conditional_expression would be allowed, and it
+          should work the same way.
+
+                               _Syntax_
+
+2/3
+     {AI05-0188-1AI05-0188-1} conditional_expression ::= if_expression | 
+     case_expression
+
+3/3
+     {AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} if_expression ::=
+
+        if condition then dependent_expression
+        {elsif condition then dependent_expression}
+        [else dependent_expression]
+
+4/3
+     {AI05-0147-1AI05-0147-1} condition ::= boolean_expression
+
+5/3
+     {AI05-0188-1AI05-0188-1} case_expression ::=
+         case selecting_expression is
+         case_expression_alternative {,
+         case_expression_alternative}
+
+6/3
+     {AI05-0188-1AI05-0188-1} case_expression_alternative ::=
+         when discrete_choice_list =>
+             dependent_expression
+
+7/3
+     {AI05-0147-1AI05-0147-1} Wherever the Syntax Rules allow an
+     expression, a conditional_expression may be used in place of the
+     expression, so long as it is immediately surrounded by parentheses.
+
+7.a/3
+          Discussion: {AI05-0147-1AI05-0147-1} The syntactic category
+          conditional_expression appears only as a primary that is
+          parenthesized.  The above rule allows it to additionally be
+          used in other contexts where it would be directly surrounded
+          by parentheses.
+
+7.b/3
+          The grammar makes the following directly legal:
+
+7.c/3
+               A := (if X then Y else Z); -- parentheses required
+               A := B + (if X then Y else Z) + C; -- parentheses required
+
+7.d/3
+          The following procedure calls are syntactically legal; the
+          first uses the above rule to eliminate the redundant
+          parentheses found in the second:
+
+7.e/3
+               P(if X then Y else Z);
+               P((if X then Y else Z)); -- redundant parentheses
+
+7.f/3
+               P((if X then Y else Z), Some_Other_Param);
+               P(Some_Other_Param, (if X then Y else Z));
+               P(Formal => (if X then Y else Z));
+
+7.g/3
+          whereas the following are illegal:
+
+7.h/3
+               P(if X then Y else Z, Some_Other_Param);
+               P(Some_Other_Param, if X then Y else Z);
+               P(Formal => if X then Y else Z);
+
+7.i/3
+          because in these latter cases, the conditional_expression is
+          not immediately surrounded by parentheses (which means on both
+          sides!).
+
+7.j/3
+          The English-language rule applies in all places that could
+          surround an expression with parentheses, including pragma
+          arguments, type conversion and qualified expression operands,
+          and array index expressions.
+
+7.k/3
+          This English-language rule could have been implemented instead
+          by adding a nonterminal expression_within_parentheses, which
+          would consist of expressions and conditional_expressions.
+          Then, that could be used in all of the syntax which could
+          consist of parens directly around an expression.  We did not
+          do that because of the large amount of change required.  A
+          complete grammar is given in AI05-0147-1AI05-0147-1.
+
+7.l/3
+          Implementation Note: {AI05-0147-1AI05-0147-1} Implementers are
+          cautioned to consider error detection when implementing the
+          syntax for conditional_expressions.  An if_expression and an
+          if_statement are very similar syntactically, (as are a
+          case_expression and a case_statement) and simple mistakes can
+          appear to change one into the other, potentially causing
+          errors to be moved far away from their actual location.  The
+          absence of end if to terminate an if_expression (and end case
+          for a case_expression) also may make error handling harder.
+
+                        _Name Resolution Rules_
+
+8/3
+{AI05-0147-1AI05-0147-1} If a conditional_expression is expected to be
+of a type T, then each dependent_expression of the
+conditional_expression is expected to be of type T. Similarly, if a
+conditional_expression is expected to be of some class of types, then
+each dependent_expression of the conditional_expression is subject to
+the same expectation.  If a conditional_expression shall resolve to be
+of a type T, then each dependent_expression shall resolve to be of type
+T.
+
+9/3
+{AI05-0147-1AI05-0147-1} The possible types of a conditional_expression
+are further determined as follows:
+
+10/3
+   * If the conditional_expression is the operand of a type conversion,
+     the type of the conditional_expression is the target type of the
+     conversion; otherwise,
+
+10.a/3
+          Reason: This rule distributes an enclosing type conversion to
+          the dependent_expressions.  This means that
+
+10.b/3
+               T(if C then A else B)
+
+10.c/3
+          has the same semantics as
+
+10.d/3
+               (if C then T(A) else T(B))
+
+11/3
+   * If all of the dependent_expressions are of the same type, the type
+     of the conditional_expression is that type; otherwise,
+
+12/3
+   * If a dependent_expression is of an elementary type, the type of the
+     conditional_expression shall be covered by that type; otherwise,
+
+12.a/3
+          Reason: This rule supports the use of numeric literals and
+          universal expressions within a conditional_expression.
+
+13/3
+   * If the conditional_expression is expected to be of type T or shall
+     resolve to type T, then the conditional_expression is of type T.
+
+13.a/3
+          Ramification: If the type of the conditional_expression cannot
+          be determined by one of these rules, then Name Resolution has
+          failed for that expression, even if the dependent_expressions
+          would resolve individually.
+
+14/3
+{AI05-0147-1AI05-0147-1} A condition is expected to be of any boolean
+type.
+
+15/3
+{AI05-0188-1AI05-0188-1} The expected type for the selecting_expression
+and the discrete_choices are as for case statements (see *note 5.4::).  
+
+                           _Legality Rules_
+
+16/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} All of the
+dependent_expressions shall be convertible (see *note 4.6::) to the type
+of the conditional_expression.
+
+17/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1}
+{AI05-0269-1AI05-0269-1} If the expected type of a
+conditional_expression is a specific tagged type, all of the
+dependent_expressions of the conditional_expression shall be dynamically
+tagged, or none shall be dynamically tagged.  In this case, the
+conditional_expression is dynamically tagged if all of the
+dependent_expressions are dynamically tagged, is tag-indeterminate if
+all of the dependent_expressions are tag-indeterminate, and is
+statically tagged otherwise.
+
+18/3
+{AI05-0147-1AI05-0147-1} {AI05-0262-1AI05-0262-1} If there is no else
+dependent_expression, the if_expression shall be of a boolean type.
+
+19/3
+{AI05-0188-1AI05-0188-1} {AI05-0269-1AI05-0269-1} All Legality Rules
+that apply to the discrete_choices of a case_statement (see *note 5.4::)
+also apply to the discrete_choices of a case_expression except within an
+instance of a generic unit.
+
+19.a/3
+          Reason: The exemption for a case expression that occurs in an
+          instance allows the following example:
+
+19.b/3
+               generic
+                  with function Int_Func return Integer;
+               package G is
+                  X : Float := (case Int_Func is
+                                 when Integer'First .. -1 => -1.0,
+                                 when 0 => 0.0,
+                                 when Positive => 1.0);
+               end G;
+
+19.c/3
+               function Nat_Func return Natural is (123);
+
+19.d/3
+               package I is new G (Int_Func => Nat_Func); -- Legal
+
+19.e/3
+          Note that the Legality Rules still apply in the generic unit
+          itself; they are just not enforced in an instance of the unit.
+
+                          _Dynamic Semantics_
+
+20/3
+{AI05-0147-1AI05-0147-1} {AI05-0188-1AI05-0188-1} For the evaluation of
+an if_expression, the condition specified after if, and any conditions
+specified after elsif, are evaluated in succession (treating a final
+else as elsif True then), until one evaluates to True or all conditions
+are evaluated and yield False.  If a condition evaluates to True, the
+associated dependent_expression is evaluated, converted to the type of
+the if_expression, and the resulting value is the value of the
+if_expression.  Otherwise (when there is no else clause), the value of
+the if_expression is True.
+
+20.a/3
+          Ramification: Else is required unless the if_expression has a
+          boolean type, so the last sentence can only apply to
+          if