CVS difference for ais/ai-10318.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-10318.txt

--- ais/ai-10318.txt	2004/11/02 01:50:31	1.8
+++ ais/ai-10318.txt	2004/11/14 06:37:24	1.9
@@ -1,6 +1,7 @@
-!standard 03.10.02(13)                              04-10-05  AI95-00318-02/06
-!standard 03.09(14)
+!standard 03.10.02(13)                              04-11-05  AI95-00318-02/07
+!standard 03.08(14)
 !standard 06.01(13)
+!standard 06.01(24)
 !standard 06.03.01(16)
 !standard 06.05(02)
 !standard 06.05(03)
@@ -24,6 +25,9 @@
 !standard 06.05(21)
 !standard 06.05(22)
 !standard 06.05(24)
+!standard 07.05(02)
+!standard 07.05(08)
+!standard 07.05(09)
 !standard 08.01(4)
 !class amendment 02-10-09
 !status Amendment 200Y 04-09-23
@@ -80,7 +84,7 @@
 is nothing in the declaration of such a function that indicates it
 returns by reference.
 
-The capability to return-by-reference could be useful for non-limited types,
+The capability to return-by-reference could be useful for nonlimited types,
 but it becomes even more useful if a call on such a function could be treated
 as a variable, so it could be used on the left-hand side of an assignment.
 These capabilities exist in the language without introducing the
@@ -155,10 +159,10 @@
 
 !wording
 
-Add before 3.9(14):
+Add before 3.8(14):
 
-If a record_type_declaration includes the reserved word limited, it is called
-a *limited record*.
+If a record_type_declaration includes the reserved word limited, the type
+is called a *limited record* type.
 
 Add after 3.10.2(13):
 
@@ -172,6 +176,16 @@
         [formal_part] RETURN subtype_mark
       | [formal_part] RETURN access_definition
 
+Change 6.1(24) to:
+
+An *access parameter* is a formal in* parameter specified by an
+access_definition.
+An *access result type* is a function result type specified by an
+access_definition.
+An access parameter or result type is of an anonymous general
+access-to-variable type (see 3.10). Access parameters allow dispatching
+calls to be controlled by access values.
+
 Modify 6.3.1(16) as follows:
 
     Two profiles are mode conformant if they are type-conformant, corresponding
@@ -200,11 +214,12 @@
 
                Name Resolution Rules
 
-    The result subtype of a function is the subtype denoted by the
+    The *result subtype* of a function is the subtype denoted by the
     subtype_mark, or defined by the access_definition, after the reserved word
     RETURN in the profile of the function. The expression, if any, of a
-    return_statement is called the return expression. The expected type for a
-    return expression is the result type of the corresponding function.
+    simple_return_statement or extended_return_statement is called the *return
+    expression*. The expected type for a return expression is the result type
+    of the corresponding function.
 
                 Legality Rules
 
@@ -254,14 +269,14 @@
                 Dynamic Semantics
 
     For the execution of an extended_return_statement, the subtype_indication
-    is elaborated. This creates the nominal subtype of the return object. If
-    there is a return expression, it is evaluated and converted to the nominal
-    subtype (which might raise Constraint_Error -- see 4.6) and becomes the
-    initial value of the return object; otherwise, the return object is
-    initialized by default as for a stand-alone object of its nominal subtype
-    (see 3.3.1). If the nominal subtype is indefinite, the return object is
-    constrained by its initial value. The handled sequence of statements, if
-    any, is then executed.
+    or access_definition is elaborated. This creates the nominal subtype of the
+    return object. If there is a return expression, it is evaluated and
+    converted to the nominal subtype (which might raise Constraint_Error -- see 4.6)
+    and becomes the initial value of the return object; otherwise, the return
+    object is initialized by default as for a stand-alone object of its nominal
+    subtype (see 3.3.1). If the nominal subtype is indefinite, the return
+    object is constrained by its initial value. The handled_sequence_of_statements,
+    if any, is then executed.
 
     For the execution of a simple_return_statement, the expression (if any) is
     first evaluated and converted to the result subtype to become the value of
@@ -401,7 +416,7 @@
     begin
         -- Initialize table of squares, extending as necessary
         for I in 1..Max loop
-            Set_Elem(X, I, Elem => I*2);
+            Set_Elem(X, I, Elem => I**2);
         end loop;
 
         -- Add one to each of the elements with indices up to Max/2
@@ -432,7 +447,7 @@
 to create the object being returned and then initialize it further somehow,
 perhaps by calling a procedure, doing a loop (as in the examples above),
 etc. This requires a named object. However, to avoid copying,
-we need this object to be created in its final "resting place,"
+we need this object to be created in its final "resting place",
 i.e. in the target of the function call. This might be in the
 "middle" of some enclosing composite object the caller is initializing,
 or it might be in the heap, or it might be a stand-alone local
@@ -447,7 +462,7 @@
 
 Because it may be necessary to do some computing before deciding
 exactly how the result object should be declared, we permit
-the extended return statement to occur any place a normal return
+the extended return statement to occur wherever a normal return
 statement is permitted. So different branches of an if or case statement
 could have their own extended return statements, each with its own named
 result object.
@@ -475,7 +490,7 @@
 object being initialized is a component of some larger object.
 
 However, by not allowing the *programmer* to refer to this contextual
-information at the langauge level, we give the implementation more
+information at the language level, we give the implementation more
 flexibility in how it solves the build-in-place requirement for
 "really" limited objects. See the discussion below about implementation
 approaches.
@@ -488,15 +503,15 @@
 current syntax.
 
 We have eliminated the capability for returning by reference, in favor
-of returning a value of an anonymous access type. An alternative proposal
-(AI-318-1) proposed to make return-by-reference a separate capability,
+of returning a value of an anonymous access type. A rejected alternative
+proposal (AI-318-1) proposed to make return-by-reference a separate capability,
 triggered by the presence of the reserved word "ALIASED" in the function
 profile. This was felt by some reviewers to be enshrining the confusing notion
 of return-by-reference, which earlier had been buried in a discussion
 of certain limited types. Furthermore, the implementation model of
 return by reference was clearly to return a "reference" (effectively an access
 value) to the result object. Making this explicit presumably makes
-the feature easier to understand, and we can also piggy back on the
+the feature easier to understand, and we can also piggyback on the
 usual accessibility checks, rather than have to invent special ones
 associated with a return by reference.
 
@@ -508,7 +523,7 @@
 
 POSSIBLE IMPLEMENTATION APPROACHES
 
-The implementation of the extended return statement for non-limited
+The implementation of the extended return statement for nonlimited
 types should minimize the number of copies, but may still require a copy
 in some implementation models and in some calling contexts.
 
@@ -521,7 +536,7 @@
 uses it for the "return" object. Nonlimited controlled components can
 still require some fancy footwork, since they can be explicitly
 initialized, so default initializing them would be inappropriate. But
-compilers already have to deal with returning non-limited controlled
+compilers already have to deal with returning nonlimited controlled
 objects, so presumably this won't create an insurmountable burden.
 
 If the result subtype is unconstrained, then there are two basic possibilities:
@@ -615,7 +630,7 @@
 are semantically neutral. But no copies of a self-referencing object could
 ever really be semantically neutral. Moreover, the definition of object
 creation in 3.3(19) says that the subcomponents are assigned from the
-expression already evaluated. This clearly must be superceded.
+expression already evaluated. This clearly must be superseded.
 
 In addition, we want to tell the reader (Ada user and implementers alike) that
 function calls have changed. In Ada up to this point, function calls were
@@ -624,15 +639,15 @@
 for aggregates, we included such a requirement in the Corrigendum.
 
 
-!corrigendum 3.9(14)
+!corrigendum 3.8(14)
 
 @dinsb
 The @fa<component_definition> of a @fa<component_declaration> defines the
 (nominal) subtype of the component. If the reserved word @b<aliased> appears
 in the @fa<component_definition>, then the component is aliased (see 3.10).
 @dinst
-If a @fa<record_type_declaration> includes the reserved word @b<limited>, it
-is called a @i<limited record>.
+If a @fa<record_type_declaration> includes the reserved word @b<limited>, the
+type is called a @i<limited record> type.
 
 !corrigendum 3.10.2(13)
 
@@ -656,6 +671,24 @@
   | [formal_part] >@ft<@b<return>>@fa< access_definition>>
 
 
+!corrigendum 6.1(24)
+
+@drepl
+An @i<access parameter> is a formal @b<in> parameter specified by an
+@fa<access_definition>.
+An access parameter is of an anonymous general access-to-variable type (see
+3.10). Access parameters allow dispatching calls to be controlled by access
+values.
+@dby
+An @i<access parameter> is a formal @b<in> parameter specified by an
+@fa<access_definition>.
+An @i<access result type> is a function result type specified by an
+@fa<access_definition>.
+An access parameter or result type is of an anonymous general
+access-to-variable type (see 3.10). Access parameters allow dispatching
+calls to be controlled by access values.
+
+
 !corrigendum 6.3.1(16)
 
 @drepl
@@ -677,7 +710,7 @@
 @xcode<@fa<simple_return_statement ::= >@ft<@b<return>>@fa< [expression];>>
 
 @xcode<@fa<extended_return_statement ::=
-    >@ft<@b<return>>@fa< identifier : [>@ft<@b<aliased>>@fa<] >@ft<@i<return>>@fa<_subtype_indication [:= expression] [>@ft<@b<do>>@fa<
+    >@ft<@b<return>>@fa< identifier : [>@ft<@b<aliased>>@fa<] return_subtype_indication [:= expression] [>@ft<@b<do>>@fa<
         handled_sequence_of_statements
     >@ft<@b<end return>>@fa<];>>
 
@@ -695,8 +728,9 @@
 The @i<result subtype> of a function is the subtype denoted by the
 @fa<subtype_mark>, or defined by the @fa<access_definition>, after the reserved
 word @b<return> in the profile of the function. The @fa<expression>, if any, of
-a @fa<return_statement> is called the @i<return expression>. The expected type
-for a return expression is the result type of the corresponding function.
+a @fa<simple_return_statement> or @fa<extended_return_statement> is called the
+@i<return expression>. The expected type for a return expression is the result
+type of the corresponding function.
 
 !corrigendum 6.5(04)
 
@@ -705,8 +739,8 @@
 to> the innermost one. A @fa<return_statement> shall not be within a body that
 is within the construct to which the @fa<return_statement> applies.
 @dby
-A @fa<return_statement> shall be within a callable construct, and it applies to
-the innermost callable construct or @fa<extended_return_statement> that
+A @fa<return_statement> shall be within a callable construct, and it @i<applies
+to> the innermost callable construct or @fa<extended_return_statement> that
 contains it. A @fa<return_statement> shall not be within a body that is within
 the construct to which the @fa<return_statement> applies.
 
@@ -749,7 +783,7 @@
 
 Within an @fa<extended_return_statement>, the @i<return object> is declared
 with the given identifier, with nominal subtype defined by the
-@i<return>@fa<_subtype_indication>.
+@fa<return_subtype_indication>.
 
 !corrigendum 6.5(06)
 
@@ -758,18 +792,19 @@
 first evaluated and converted to the result subtype.
 @dby
 For the execution of an @fa<extended_return_statement>, the
-@fa<subtype_indication> is elaborated. This creates the nominal subtype of the
-return object. If there is an @fa<expression>, it is evaluated and converted
+@fa<subtype_indication> or @fa<access_definition> is elaborated. This creates
+the nominal subtype of the return object. If there is a return expression,
+it is evaluated and converted
 to the nominal subtype (which might raise Constraint_Error -- see 4.6) and
 becomes the initial value of the return object; otherwise, the return object is
 initialized by default as for a stand-alone object of its nominal subtype
 (see 3.3.1). If the nominal subtype is indefinite, the return object is
-constrained by its initial value. The handled sequence of statements, if
+constrained by its initial value. The @fa<handled_sequence_of_statements>, if
 any, is then executed.
 
-For the execution of a @fa<simple_return_statement>, the expression (if any) is
-first evaluated and converted to the result subtype to become the value of
-the anonymous @i<return object>.
+For the execution of a @fa<simple_return_statement>, the @fa<expression>
+(if any) is first evaluated and converted to the result subtype to become
+the value of the anonymous @i<return object>.
 
 !corrigendum 6.5(07)
 
@@ -878,11 +913,11 @@
 !corrigendum 6.5(24)
 
 @drepl
-@xcode<@b<return>;                         -- @ft<@i<in a procedure body, entry_body, or accept_statement>>
+@xcode<@b<return>;                         -- @ft<@i<in a procedure body, >>@fa<entry_body>@ft<@i<, or >>@fa<accept_statement>
 @b<return> Key_Value(Last_Index);   -- @ft<@i<in a function body>>>
 @dby
-@xcode<@b<return>;                         -- @ft<@i<in a procedure body, entry_body,>>
-                                -- @ft<@i<accept_statement, or extended_return_statement>>>
+@xcode<@b<return>;                         -- @ft<@i<in a procedure body, >>@fa<entry_body>@ft<@i<,>>
+                                -- @fa<accept_statement>@ft<@i<, or >>@fa<extended_return_statement>>
 
 @xcode<@b<return> Key_Value(Last_Index);   -- @ft<@i<in a function body>>>
 
@@ -905,12 +940,12 @@
 or a parenthesized @fa<expression> or @fa<qualified_expression> whose operand
 is permitted by this rule:
 @xbullet<the initialization @fa<expression> of an @fa<object_declaration> (see 3.3.1)>
-@xbullet<the @fa<default_expression> of a component_declaration (see 3.8)>
+@xbullet<the @fa<default_expression> of a @fa<component_declaration> (see 3.8)>
 @xbullet<the @fa<expression> of a @fa<record_component_association> (see 4.3.1)>
 @xbullet<the @fa<expression> for an @fa<ancestor_part> of an @fa<extension_aggregate> (see 4.3.2)>
 @xbullet<an @fa<expression> of a @fa<positional_array_aggregate> or the
 @fa<expression> of an @fa<array_component_association> (see 4.3.3)>
-@xbullet<the @fa<qualified_expression> of an initialized @fa<allocator> (see 4.8)>
+@xbullet<the @fa<qualified_expression> of an initialized allocator (see 4.8)>
 @xbullet<the @fa<expression> of a @fa<return_statement> (see 6.5)>
 @xbullet<the @fa<default_expression> or actual parameter for a formal object
 of mode @b<in> (see 12.4)>

Questions? Ask the ACAA Technical Agent