CVS difference for ai05s/ai05-0262-1.txt
--- ai05s/ai05-0262-1.txt 2011/08/04 01:48:45 1.2
+++ ai05s/ai05-0262-1.txt 2011/09/29 06:34:03 1.3
@@ -1,6 +1,38 @@
-!standard 5.5(9) 11-08-03 AI05-0262-1/02
+!standard 1.1.2(23) 11-09-26 AI05-0262-1/03
+!standard 3.1(1)
+!standard 3.2.4(0)
+!standard 3.3(19)
+!standard 3.5(30/2)
+!standard 3.8.1(10)
+!standard 3.8.1(11)
+!standard 3.8.1(15)
+!standard 3.9(25.1/2)
+!standard 3.10.2(16.1/2)
+!standard 4.3.3(18)
+!standard 4.5.2(2)
+!standard 4.5.2(9.7/2)
+!standard 4.5.2(39)
+!standard 4.5.7(0)
+!standard 4.9(33)
+!standard 4.9(34)
+!standard 5.4(7)
+!standard 5.5(9)
!standard 6.1.1(0)
+!standard 6.2(3)
+!standard 6.3.1(16/2)
+!standard 6.3.1(18)
+!standard 6.4.1(6)
+!standard 6.6(3)
+!standard 6.8(0)
+!standard 7.4(6)
+!standard 7.5(2.1/2)
+!standard 7.6.1(13.1/2)
+!standard 7.6.1(20)
+!standard 10.1.1(12.2/2)
+!standard 10.1.1(12.3/2)
!standard 13.11(21)
+!standard A.18.10(0)
+!standard A.18.18(0)
!class presentation 11-07-27
!status Amendment 2012 11-07-27
!status work item 11-07-27
@@ -27,6 +59,145 @@
[Note: /3 paragraph numbers are from draft 13.]
+Add after 1.1.2(23):
+
+* Annex Q, "Language-Defined Entities"
+
+Add "access" to the list of anonymous types in 3.3.1(1).
+
+Add after 3.2.4(14/3):
+
+A predicate shall not be specified for an incomplete subtype.
+
+Replace 3.2.4(16/3) with:
+
+The discrete_subtype_definition of a loop_parameter_specification shall not denote a
+subtype to which Dynamic_Predicate specifications apply.
+
+The discrete_choice of a
+named_array_aggregate shall not denote a non-static subtype to which predicate specifications
+apply.
+
+[Editor's note: The former rule is included in the new one, as a Dynamic_Predicate necessarily
+makes the subtype non-static.]
+
+AARM Reason: This rule prevents non-contiguous 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.
+
+Add after 3.2.4(18/3):
+
+A value *satisfies* a predicate if the predicate is True for that value.
+
+Replace 3.3(19) by:
+
+ * a loop parameter unless specified to be a variable for a generalized loop (see 5.5.2);
+ * a choice parameter or entry index;
+
+In 3.5(30/3), "sequence of character" should be "sequence of graphic characters".
+[This is the wording used in 'Image, this should be the same.]
+
+Move the second sentence of 3.2.4(19/3) to after 3.2.4(16/3), and make it plural. Delete the second
+line of the AARM note after 3.2.4(19/3).
+
+In 3.8.1(10), replace "expression" with "choice_expression" (two places).
+
+Modify 3.8.1(10.1/3):
+
+* A discrete_choice that is a subtype_indication covers all values (possibly none)
+ that belong to the subtype{ and that satisify the static predicate of the subtype (see 3.2.4)}.
+
+AARM Ramification: A dynamic predicate is never allowed in this case (for variants and
+case_statements, a subtype with a dynamic predicate isn't static and thus isn't
+allowed in a discrete_choice, and for a choice in an aggregate, a dynamic predicate is explicitly
+disallowed - see 3.2.4).
+
+Modify 3.8.1(15/3):
+
+Replace "satisfy the predicate" with "satisfy its predicate" (two places).
+
+Add "Is_Abstract, " to the list of 3.9(25.1/3).
+
+Add to 3.10.2(16.1/2):
+
+Similarly, the dependent_expression of a conditional_expression is considered to be used in
+a context if the conditional_expression itself is used in that context.
+
+Modify 4.3.3(18):
+
+In a named_array_aggregate {where all discrete_choices are static}[with more than one discrete_choice],
+no two discrete_choices are allowed to cover the same value (see 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.
+
+AARM Reason: 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 3.2.4) and thus the range has to be contiguous.
+
+Modify 4.5.2(2):
+
+A membership test, using in or not in, determines whether or not a value belongs to
+{any} [a] given subtype or range, {is equal to any given value,} [or] has a tag that
+identifies a type that is covered by a given type{, or is convertible to and with
+accessibility level appropriate for a given access type}. Membership tests are allowed
+for all types.
+
+Modify 4.5.2(9.8/3):
+
+Replace the first sentence the the first word of the second sentence by:
+
+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 ...
+
+Add to 4.5.2(39):
+
+ Card in Clubs | Spades -- list membership test (see 3.5.1)
+
+Modify 4.5.7(1/3):
+
+[Another]{The other} kind of conditional_expression...
+
+Replace 4.5.7(18/3) by:
+
+If there is no else dependent_expression, the if_expression shall be of a
+boolean type.
+
+Modify 4.9(32.6/3):
+
+Replace "which" by "that" (two places).
+
+Modify 4.9(34):
+
+The expression is illegal if its evaluation fails a language-defined check other than
+Overflow_Check. {For the purposes of this evaluation, the assertion policy is assumed
+to be Check.}
+
+AARM Reason: Assertion policies can control whether checks are made, but we don't want
+assertion policies to affect legality. For Ada 2012, subtype predicates are the only checks
+controlled by the assertion policy that can appear in static expressions.
+
+
+Modify 5.4(7/3):
+
+Replace "satisfy the predicate" with "satisfy its predicate" (two places), and
+add (see 3.2.4) after the first occurrence of "predicate". Remove last to "a"s in
+"If the selecting_expression is a name (including a type_conversion,
+a qualified_expression, or a function_call) having a static and..."
+
+
+Modify 5.5(9):
+
+... Otherwise, the sequence_of_statements is executed once for each value of the
+discrete subtype defined by the discrete_subtype_definition {that satisfies the
+predicate of the subtype} (or until the loop is left as a consequence
+of a transfer of control).
+
+AARM Ramification: The predicate (if any) necessarily has to be a static predicate as a
+dynamic predicate is explicitly disallowed - see 3.2.4.
+
Add after 5.5(9):
Redundant[For details about the execution of a loop_statement with the
@@ -42,26 +213,363 @@
This aspect specifies a class-wide postcondition for {an operation of a tagged type}[a
callable entity] and its descendants; ...
+Modify 6.1.1(7/3):
+
+"... This ensures {that }the expression..."
+
+Insert after 6.1.1(18/3):
+
+If the Assertion_Policy in effect at the point of a
+subprogram or entry declaration is Check, then preconditions and
+postconditions are considered to be @i<enabled> for that subprogram or
+entry.
+
+Modify 6.1.1(27/3):
+
+"... For [a task or protected]{an} entry call..."
+
+Modify 6.1.1(28/3):
+
+"...[Ada.]Assertions.Assertion_Error..."
+
+Modify 6.1.1(29/3):
+
+"...subprogram {or entry}."
+
+Modify 6.1.1(33/3) by deleting the last sentence.
+
+Modify 6.1.1(35/3):
+
+"...[may]{need} not..." ["May not" is not allowed by ISO drafting rules - ED].
+
+Replace the last sentence of 6.2(3/3) with: ""A parameter of a by-copy type is passed by copy, unless the
+formal parameter is explicitly aliased."
+
+Add "and" to the end of 6.3.1(16.1/3).
+
+Modify 6.3.1(18/3): "...and {for} corresponding parameters [have]:"
+
+Replace 6.3.1(18.1/3) by "* they have the same names; and"
+
+Modify 6.6(3/3):
+
+"...has the corresponding number of parameters{, and they are all of mode in}[of
+mode in and no other parameters]."
+
+Modify 6.8(7/3):
+
+"...subprogram_body {executes an implicit}[is equivalent to a] function body
+
+
+Modify 7.4(6/3):
+"If the deferred constant declaration includes a subtype_indication {*S*}
+that defines a constrained subtype, then the constraint defined by the
+subtype_indication in the full declaration shall match [it]{the constraint
+defined by *S*} statically. ..."
+
+Modify 7.5(2.1/3):
+"...a parenthesized expression{,} or qualified_expression..."
+
+Modify 7.6.1(13.1/3):
+"...and {all} use of the objects..."
+
+Modify 7.6.1(20.2/3):
+"...instead of {at} the first freezing point..."
+
+
+Modify 10.1.1(12.2/3) and 10.1.1(12.3/3): "...{immediately within}[directly in]..."
+
Modify the start of 13.11(21.5/3):
For [one]{each} of the calls of Allocate described above, P
(equivalent to T'Storage_Pool) is passed as the Pool parameter. ...
+Modify A.18.10(3/3):
+
+...and has [no]{neither an} associated element value {nor any parent node}. ...
+
+Modify A.18.10(5/3): "...[could]{can} be visited..."
+
+Add "Delete_Subtree" and "Copy_Subtree" to the list in A.18.10(81/3).
+
+Modify A.18.10(92/3): "... and a cursor [designated] {designating} the corresponding child..."
+
+Modify A.18.10(94/3): "... with [a] cursor{s} designating the root node{s} of Left
+and Right."
+
+Modify A.18.10(143/3): "... The search [checks] {traverses}..."
+
+Modify A.18.10(145/3):
+"Find_In_Subtree searches [a subtree of the elements of Container]
+{the subtree rooted by Position} for an element equal to Item (using..."
+"... The search [checks] {traverses}..."
+
+Modify A.18.10(161/3): "...; [in this case] Program_Error..."
+
+Modify A.18.10(162/3, 165/3, 167/3):
+
+"...and {Parent does not designate the parent node of of the node designated by Before}[Container.Parent (Before)
+is not equal to Parent], then..."
+
+Replace "dependent elements" in A.18.10(173/3) with "descendant nodes".
+
+Modify A.18.10(175/3, 177/3, 180/3):
+
+"...and {Parent does not designate the parent node of of the node designated by Before}[Target.Parent (Before)
+is not equal to Parent], then..."
+
+Modify A.18.10(182/3, 189/3):
+
+"...and {Target_Parent does not designate the parent node of of the node designated by Before}[Target.Parent (Before)
+is not equal to Target_Parent], then..."
+
+Modify A.18.18(29/3, 30/3, 48/3, 49/3, 57/3, 60/3, 67/3):
+
+"tamper with elements" should be "tamper with the element".
+
+
!discussion
These wording changes seem to be an improvement in readability and
understandability, but are not intended to change the meaning of the words,
except in the case of clear mistakes. The latter are listed below:
+3.3(19): 5.5.2(8/3) specifies that some loop parameters are variables; this wording had
+better reflect that.
+
6.1.1(3/3, 5/3): the term "descendant" is not defined for subprograms, so the original
wording is dubious. The formal definition in 6.1.1(18/3) is correct, but too wordy to use
in this introductory text.
+7.4(6/3): There is no matching defined between constraints and subtypes. We have to match
+two constraints.
-!corrigendum 5.5(9)
+10.1.1(12.2/3, 12.3/3): "directly in" is not defined, while "immediately within" is a
+defined term, so we prefer that.
+
+A.18.10(162/3, 165/3, 167/3, 175/3, 177/3, 180/3, 182/3, 189/3): The Container.Parent (Before)
+text was supposed to represent a prefix call. Unfortunately, the function Parent has
+no Container parameter, so this call is impossible. In addition, most of these functions
+have a Parent parameter, so just saying "Parent" would be ambiguous. Thus we change the
+wording to give the full definition of the Parent operation; it's not that much longer
+and it prevents any confusion.
+
+
+!corrigendum 1.1.2(23)
@dinsa
+@xbullet<Annex P, "Syntax Summary">
+@dinst
+@xbullet<Annex Q, "Language-Defined Entities">
+
+!corrigendum 3.2.4(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+!corrigendum 3.3(19)
+
+@drepl
+@xbullet<a loop parameter, choice parameter, or entry index;>
+@dby
+@xbullet<a loop parameter unless specified to be a variable for a
+generalized loop (see 5.5.2);>
+@xbullet<a choice parameter or entry index;>
+
+!corrigendum 3.3.1(1)
+
+@drepl
+An @fa<object_declaration> declares a @i<stand-alone> object with a given nominal
+subtype and, optionally, an explicit initial value given by an initialization expression.
+For an array, task, or protected object, the @fa<object_declaration> may include the
+definition of the (anonymous) type of the object.
+
+!corrigendum 3.5(30/2)
+
+@drepl
+@xindent<The function returns an image of the value of @i<Arg> as a Wide_String.
+The lower bound of the result is one. The image has the same sequence of
+character 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).>
+@dby
+@xindent<The function returns an image of the value of @i<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).>
+
+!corrigendum 3.8.1(10)
+
+@drepl
+@xbullet<A @fa<discrete_choice> that is an @fa<expression> covers a value
+if the value equals the value of the @fa<expression> converted to the expected type.>
+@dby
+@xbullet<A @fa<discrete_choice> that is a @fa<choice_expression> covers a value
+if the value equals the value of the @fa<choice_expression> converted to the expected type.>
+
+!corrigendum 3.8.1(11)
+
+@drepl
+@xbullet<A @fa<discrete_choice> that is a @fa<discrete_range> covers all values
+(possibly none) that belong to the range.>
+@dby
+@xbullet<A @fa<discrete_choice> that is a @fa<subtype_indication> covers all values
+(possibly none) that belong to the subtype and that satisfy the static predicate of
+the subtype (see 3.2.4).>
+
+@xbullet<A @fa<discrete_choice> that is a @fa<range> covers all values
+(possibly none) that belong to the range.>
+
+!corrigendum 3.8.1(15)
+
+@drepl
+@xbullet<If the discriminant is of a static constrained scalar subtype, then each
+non-@b<others> @fa<discrete_choice> shall cover only values in that subtype, and
+each value of that subtype shall be covered by some @fa<discrete_choice> (either
+explicitly or by others);>
+@dby
+@xbullet<If the discriminant is of a static constrained scalar subtype then,
+except within an instance of a generic unit, each
+non-@b<others> @fa<discrete_choice> shall cover only values in that subtype that
+satisfy its predicate (see 3.2.4), and each value of that subtype that satisfies its
+predicate shall be covered by some @fa<discrete_choice> (either explicitly or by others);>
+
+
+!corrigendum 3.9(25.1/2)
+
+@drepl
+Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag,
+Interface_Ancestor_Tag, Is_Descendant_At_Same_Level, or Parent_Tag if any tag
+passed is No_Tag.
+@dby
+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.
+
+
+!corrigendum 3.10.2(16.1/2)
+
+@drepl
+In the above rules, the operand of a view conversion, parenthesized expression or
+@fa<qualified_expression> is considered to be used in a context if the view conversion,
+parenthesized expression or @fa<qualified_expression> itself is used in that context.
+@dby
+In the above rules, the operand of a view conversion, parenthesized expression or
+@fa<qualified_expression> is considered to be used in a context if the view conversion,
+parenthesized expression or @fa<qualified_expression> itself is used in that context.
+Similarly, the @i<dependent_>@fa<expression> of a @fa<conditional_expression> is
+considered to be used in a context if the @fa<conditional_expression> itself is
+used in that context.
+
+
+!corrigendum 4.3.3(18)
+
+@drepl
+In a @fa<named_array_aggregate> with more than one @fa<discrete_choice>, no two
+@fa<discrete_choice>s are allowed to cover the same value (see 3.8.1); if there is no @b<others> choice,
+the @fa<discrete_choice>s taken together shall exactly cover a contiguous sequence of values of the
+corresponding index type.
+@dby
+In a @fa<named_array_aggregate> where all @fa<discrete_choice>s are static, no two
+@fa<discrete_choice>s are allowed to cover the same value (see 3.8.1); if there is no @b<others> choice,
+the @fa<discrete_choice>s taken together shall exactly cover a contiguous sequence of values of the
+corresponding index type.
+
+
+!corrigendum 4.5.2(2)
+
+@drepl
+A @i<membership test>, using @b<in> or @b<not in>, determines whether or not a value
+belongs to a given subtype or range, or has a tag that identifies a type that is
+covered by a given type. Membership tests are allowed for all types.
+@dby
+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 with accessibility level appropriate for a given access type.
+Membership tests are allowed for all types.
+
+!corrigendum 4.5.2(9.7/2)
+
+@dinsa
+@xbullet<When both are access-to-subprogram types, the designated profiles
+shall be subtype conformant.>
+@dinst
+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 12.3),
+this rule applies also in the private part of an instance of a generic unit.
+
+!corrigendum 4.5.2(39)
+
+@drepl
+@xcode<N @b<not in> 1 .. 10 -- @ft<@i<range membership test>>
+Today @b<in> Mon .. Fri -- @ft<@i<range membership test>>
+Today @b<in> Weekday -- @ft<@i<subtype membership test (see 3.5.1)>>
+Archive @b<in> Disk_Unit -- @ft<@i<subtype membership test (see 3.8.1)>>
+Tree.@b<all in> Addition'Class -- @ft<@i<class membership test (see 3.9.1)>>>
+@dby
+@xcode<N @b<not in> 1 .. 10 -- @ft<@i<range membership test>>
+Today @b<in> Mon .. Fri -- @ft<@i<range membership test>>
+Today @b<in> Weekday -- @ft<@i<subtype membership test (see 3.5.1)>>
+Card @b<in> Clubs | Spades -- @ft<@i<list membership test (see 3.5.1)>>
+Archive @b<in> Disk_Unit -- @ft<@i<subtype membership test (see 3.8.1)>>
+Tree.@b<all in> Addition'Class -- @ft<@i<class membership test (see 3.9.1)>>>
+
+!corrigendum 4.5.7(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+!corrigendum 4.9(33)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+!corrigendum 4.9(34)
+
+@drepl
+@xbullet<The expression is illegal if its evaluation fails a language-defined check other than
+Overflow_Check.>
+>
+@dby
+@xbullet<The expression is illegal if its evaluation fails a language-defined check other than
+Overflow_Check. For the purposes of this evaluation, the assertion policy is assumed
+to be Check.>
+
+!corrigendum 5.4(7)
+
+@drepl
+@Xbullet<If the @fa<expression> is a @fa<name> (including a
+@fa<type_conversion> or a @fa<function_call>)
+having a static and constrained nominal subtype, or is a
+@fa<qualified_expression> whose @fa<subtype_mark> denotes a static and
+constrained scalar subtype, then each non-@b<others> @fa<discrete_choice>
+shall cover only values in that subtype, and each value of that
+subtype shall be covered by some @fa<discrete_choice>
+(either explicitly or by @b<others>).>
+@dby
+@Xbullet<If the @i<selecting_>@fa<expression> is a @fa<name> (including a
+@fa<type_conversion>, @fa<qualified_expression>, or @fa<function_call>)
+having a static and constrained nominal subtype, then each non-@b<others>
+@fa<discrete_choice> shall cover only values in that subtype that satisfy
+its predicate (see 3.2.4), and each value of that subtype that satisfies its
+predicate shall be covered by some @fa<discrete_choice> (either explicitly or
+by @b<others>).>
+
+!corrigendum 5.5(9)
+
+@drepl
For the execution of a @fa<loop_statement> with a @b<for> @fa<iteration_scheme>,
the @fa<loop_parameter_specification> is first elaborated. This
elaboration creates the loop parameter and elaborates the
@@ -76,7 +584,23 @@
loop parameter. These values are assigned in increasing order unless
the reserved word @b<reverse> is present, in which case the values
are assigned in decreasing order.
-@dinst
+@dby
+For the execution of a @fa<loop_statement> with a @b<for> @fa<iteration_scheme>,
+the @fa<loop_parameter_specification> is first elaborated. This
+elaboration creates the loop parameter and elaborates the
+@fa<discrete_subtype_definition>.
+If the @fa<discrete_subtype_definition> defines a subtype with a null range,
+the execution of the @fa<loop_statement> is complete. Otherwise, the
+@fa<sequence_of_statements> is executed once for each value of the
+discrete subtype defined by the @fa<discrete_subtype_definition> that
+satisfy the predicate of the subtype (or until
+the loop is left as a consequence of a transfer of control).
+Prior to each such iteration,
+the corresponding value of the discrete subtype is assigned to the
+loop parameter. These values are assigned in increasing order unless
+the reserved word @b<reverse> is present, in which case the values
+are assigned in decreasing order.
+
For details about the execution of a @fa<loop_statement> with the
@fa<iteration_scheme> being @b<for> @fa<iterator_specification>, see 5.5.2.
@@ -86,6 +610,154 @@
Force a conflict; the real text is found in the conflict file.
+!corrigendum 6.2(3)
+
+@drepl
+A type is a @i<by-copy> type if it is an elementary type, or if it is a descendant of a private
+type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy.
+@dby
+A type is a @i<by-copy> type if it is an elementary type, or if it is a descendant of a private
+type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy, unless
+the formal parameter is explicitly aliased.
+
+!corrigendum 6.3.1(16/2)
+
+@drepl
+Two profiles are @i<mode conformant> if they are type-conformant, and
+corresponding parameters have identical modes, and, for access parameters or
+access result types, the designated subtypes statically match, or the
+designated profiles are subtype conformant.
+@dby
+Two profiles are @i<mode conformant> if:
+@xbullet<they are type conformant; and>
+@xbullet<corresponding parameters have identical modes and both or neither are explicitly
+aliased parameters; and>
+@xbullet<for corresponding access parameters and any access result type, the
+designated subtypes statically match and either both or neither are
+access-to-constant, or the designated profiles are subtype conformant.>
+
+!corrigendum 6.3.1(18)
+
+@drepl
+Two profiles are @i<fully conformant> if they are subtype-conformant, and corresponding
+parameters have the same names and default_expressions that are fully conformant with
+one another.
+@dby
+Two profiles are @i<fully conformant> if they are subtype-conformant, if they have
+access-to-subprogram results whose designated profiles are fully conformant, and
+for corresponding parameters:
+@xbullet<they have the same names; and>
+@xbullet<both or neither have @fa<null_exclusion>s; and>
+@xbullet<neither have @fa<default_expression>s, or they both have @fa<default_expression>s
+that are fully conformant with one another; and>
+@xbullet<for access-to-subprogram parameters, the designated profiles are fully conformant.>
+
+!corrigendum 6.6(3)
+
+@drepl
+The @fa<subprogram_specification> of a unary or binary operator shall have one or two
+parameters, respectively. A generic function instantiation whose @fa<designator> is an
+@fa<operator_symbol> is only allowed if the specification of the generic function has
+the corresponding number of parameters.
+@dby
+The @fa<subprogram_specification> of a unary or binary operator shall have one or two
+parameters, respectively. The parameters shall be of mode @b<in>. A generic function
+instantiation whose @fa<designator> is an @fa<operator_symbol> is only allowed if the
+specification of the generic function has the corresponding number of parameters,
+and they are all of mode @b<in>.
+
+!corrigendum 6.8(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+
+!corrigendum 7.4(6/2)
+
+@drepl
+@xbullet<If the deferred constant declaration includes a @fa<subtype_indication>
+that defines a constrained subtype, then the subtype defined by the
+@fa<subtype_indication> in the full declaration shall match it statically.
+On the other hand, if the subtype of the deferred constant is unconstrained,
+then the full declaration is still allowed to impose a constraint. The constant
+itself will be constrained, like all constants;>
+@dby
+@xbullet<If the deferred constant declaration includes a @fa<subtype_indication> @i<S>
+that defines a constrained subtype, then the constraint defined by the
+@fa<subtype_indication> in the full declaration shall match the constraint defined by @i<S>
+statically. On the other hand, if the subtype of the deferred constant is unconstrained,
+then the full declaration is still allowed to impose a constraint. The constant
+itself will be constrained, like all constants;>
+
+!corrigendum 7.5(2.1/2)
+
+@drepl
+In the following contexts, an @fa<expression> of a limited type is not permitted
+unless it is an @fa<aggregate>, a @fa<function_call>, or a parenthesized
+@fa<expression> or @fa<qualified_expression> whose operand is permitted by
+this rule:
+@dby
+In the following contexts, an @fa<expression> of a limited type is not permitted
+unless it is an @fa<aggregate>, a @fa<function_call>, a parenthesized
+@fa<expression>, or @fa<qualified_expression> whose operand is permitted by this
+rule, or a @fa<conditional_expression> all of whose
+@i<dependent_>@fa<expression>s are permitted by this rule:
+
+!corrigendum 7.6.1(13.1/2)
+
+@drepl
+In the case of an @fa<expression> that is a master, finalization of any
+(anonymous) objects occurs as the final part of evaluation of the
+@fa<expression>.
+@dby
+In the case of an @fa<expression> that is a master, finalization of any
+(anonymous) objects occurs after completing
+evaluation of the @fa<expression> and all use of the objects, prior to starting
+the execution of any subsequent construct.
+
+!corrigendum 7.6.1(20)
+
+@dinsa
+@xbullet<For a Finalize invoked by a transfer of control due to an abort or selection
+of a terminate alternative, the exception is ignored; any other finalizations due to
+be performed are performed.>
+@dinst
+@s8<@i<Implementation Permissions>>
+
+If the execution of an @fa<allocator> propagates an exception, any parts of the
+allocated object that were successfully initialized may be finalized as
+part of the finalization of the innermost master enclosing the @fa<allocator>.
+
+The implementation may finalize objects created by @fa<allocator>s for an access type
+whose storage pool supports subpools (see 13.11.4) as if the objects were created
+(in an arbitrary order) at the point where the storage pool was elaborated instead
+of at the first freezing point of the access type.
+
+
+!corrigendum 10.1.1(12.2/2)
+
+@drepl
+@xbullet<For each nested @fa<package_declaration>, a declaration of the
+limited view of that package, with the same @fa<defining_program_unit_name>.>
+@dby
+@xbullet<For each nested @fa<package_declaration> immediately with the visible
+part, a declaration of the limited view of that package, with the same
+@fa<defining_program_unit_name>.>
+
+!corrigendum 10.1.1(12.3/2)
+
+@drepl
+@xbullet<For each @fa<type_declaration> in the visible part, an
+incomplete view of the type; if the @fa<type_declaration> is tagged, then the
+view is a tagged incomplete view.>
+@dby
+@xbullet<For each @fa<type_declaration> immediately within the visible part that is
+not an @fa<incomplete_type_declaration>, an incomplete view of the type with no
+@fa<discriminant_part>; if the @fa<type_declaration> is tagged, then the view
+is a tagged incomplete view.>
+
+
!corrigendum 13.11(21)
@dinsa
@@ -112,6 +784,18 @@
block of memory of Size_In_Storage_Elements storage elements. Any exception
propagated by Allocate is propagated by the construct that contained the call.
+!corrigendum A.18.10(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
+!corrigendum A.18.18(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
!ACATS Test
None needed.
@@ -217,7 +901,7 @@
library unit, or Multiway_Trees node. Since paragraph 14 explains
just what the semantics are, I don't think the meaning of the RM is
unclear; but since paragraphs 3 and 5 are in a normative part of the
-RM, the language they use should probably be correct.
+RM, the language they use should probably be correct.
Side note: The glossary (appendix N) contains a definition of
"descendant", but that definition covers only the meaning that applies
@@ -229,18 +913,18 @@
From: Randy Brukardt
Sent: Saturday, July 30, 2011 1:21 AM
-> 6.1.1(3/3) says about Pre'Class, "This aspect specifies a class-wide
-> precondition for a callable entity and its descendants". However,
+> 6.1.1(3/3) says about Pre'Class, "This aspect specifies a class-wide
+> precondition for a callable entity and its descendants". However,
> nowhere in the RM is a "descendant"
> of a callable entity defined.
-> "Descendants" are defined for types, library units, and nodes in
-> Containers.Multiway_Trees, but not for subprograms. Also, aside from
-> paragraphs 3 and 5, and possibly 22.a in the AARM, the term
-> "descendant" is never used to refer to anything besides a type,
-> library unit, or Multiway_Trees node. Since paragraph 14 explains
-> just what the semantics are, I don't think the meaning of the RM is
+> "Descendants" are defined for types, library units, and nodes in
+> Containers.Multiway_Trees, but not for subprograms. Also, aside from
+> paragraphs 3 and 5, and possibly 22.a in the AARM, the term
+> "descendant" is never used to refer to anything besides a type,
+> library unit, or Multiway_Trees node. Since paragraph 14 explains
+> just what the semantics are, I don't think the meaning of the RM is
> unclear; but since paragraphs
-> 3 and 5 are in a normative part of the RM, the language they use
+> 3 and 5 are in a normative part of the RM, the language they use
> should probably be correct.
Actually, the normative description of class-wide aspects applied to subprograms
@@ -280,6 +964,344 @@
Post'Class
This aspect specifies a class-wide postcondition for an operation of a tagged
type and its descendants; ...
+
+****************************************************************
+
+From: John Barnes
+Sent: Thursday, August 18, 2011 4:02 PM
+
+I've started and immediately run into trouble with the phrase "satisfy the
+predicate" which doesn't seem to be defined. See 3.8.1.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 18, 2011 4:22 PM
+
+Specifically, 3.8.1(15/3).
+
+I can't find any attempt to define it in AI05-0153-3, so it just isn't done. The
+language specifically defines what it means to "satisfy" each individual kind of
+constraint (see, for instance, 3.6.1(7), 3.5(4), 3.7.1(11)). There has to be
+such a statement in 3.2.4. "A value *satisfies* a predicate if the predicate
+evaluates to True for the value." Or something like that. But...
+
+I also note that "satisfy" is typically defined as a dynamic property. The rule
+John was referring to is a legality rule, so that could be trouble. ("Satisfy"
+as typically defined ignores privacy; that would be a bad idea for a legality
+rule!)
+
+So I think this is the wrong term to use (given that it already has a dynamic,
+privacy breaking meaning) AND whatever term is used needs to be defined as
+"static semantics" (so it is view-dependent). [Note that we could give
+"satisfies a predicate" a static meaning here, and that would work properly, but
+that would be confusing at best.]
+
+Suggestions welcome.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, August 18, 2011 7:30 PM
+
+I don't see the problem with using "satisfies" in a static context. We do lots
+of "dynamic" things when evaluating expressions statically, including worry
+about exceptions.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, August 18, 2011 8:23 PM
+
+> I don't see the problem with using "satisfies" in a static context.
+> We do lots of "dynamic" things when evaluating expressions statically,
+> including worry about exceptions.
+
+I agree.
+
+...
+> > Specifically, 3.8.1(15/3).
+> >
+> > I can't find any attempt to define it in AI05-0153-3, so it just isn't done.
+
+OK, that's my handiwork, so let me defend it: In plain English, "predicate"
+and "satifies" (of a predicate) are well-understood. OK, maybe not "plain
+English", but at least plain English as understood by maths guys. Can't we rely
+on math-guy English in the RM?
+
+A predicate is satisfied if it's true. Pretty simple.
+
+> > The language specifically defines what it means to "satisfy" each
+> > individual kind of constraint (see, for instance, 3.6.1(7), 3.5(4), 3.7.1(11)).
+
+OK, but those are really just telling us what the predicate (math-wise) is.
+
+> > ...There
+> > has to be such a statement in 3.2.4. "A value *satisfies* a
+> > predicate if the predicate evaluates to True for the value." Or something like that. But...
+
+If you insist on such wording, please can't we make it simple:
+"A value *satisfies* a predicate if it is True for that value."
+"evaluates to" adds nothing.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, August 19, 2011 3:03 AM
+
+> OK, that's my handiwork, so let me defend it: In plain English,
+> "predicate"
+> and "satifies" (of a predicate) are well-understood. OK, maybe not
+> "plain English", but at least plain English as understood by maths guys.
+> Can't we rely on math-guy English in the RM?
+
+My problem is that it doesn't say what predicate we are talking about. In other
+words, it doesn't define "predicate" in the context. I am happy with satisfy.
+
+And I totally disagree with Bob that predicate is plain English as understood
+my maths folk in general. I certainly never used the word when I did maths at
+Cambridge. I must admit we never studied logic - probably considered too
+elementary. It's OK for formal methods folk - a very specialzed community - and
+we ought to make the RM understandable by typcial programmers if possible. When
+I encountered it, I was looking for a bit of syntax called predicate or some
+such.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 19, 2011 3:40 PM
+
+> I don't see the problem with using "satisfies" in a static context.
+> We do lots of "dynamic" things when evaluating expressions statically,
+> including worry about exceptions.
+
+But that wasn't my concern! My concern was that dynamic rules ignore privacy,
+and using such a concept in a Legality Rule thus is potentially privacy
+breaking.
+
+It would be OK to use "satisfies" so long as we are sure that it will never
+appear in a legality rule where privacy could matter. The one in 3.8.1(15) isn't
+a problem (which I had forgotten about yesterday) because it requires the type
+to be discrete, and a private type is never discrete. So there probably is no
+problem with using "satisfies" in Ada 2012.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 19, 2011 4:16 PM
+
+...
+> > > I can't find any attempt to define it in AI05-0153-3, so it just
+> > > isn't done.
+>
+> OK, that's my handiwork, so let me defend it: In plain English,
+> "predicate"
+> and "satifies" (of a predicate) are well-understood. OK, maybe not
+> "plain English", but at least plain English as understood by maths
+> guys.
+> Can't we rely on math-guy English in the RM?
+
+No, with the exception of technical terms. The standard explicitly says that we
+rely on the meaning of words from some particular dictionary if they are not
+defined by the Standard.
+
+So, I disagree that "satisfies" is that well defined. I realize that anyone that
+basically understands Ada can figure out what is meant, but "satisfies" doesn't
+add anything to that -- you could have said that the "value bellywomps the
+predicate" and it would have made just as much sense.
+
+Worse, "satisfied" has a technical meaning in the Standard (its in the index),
+and it is very, very bad to use a defined term in an English meaning. We've had
+all kinds of trouble with wording where some word was intended to be English but
+the defined meaning causes some unusual side-effect. (I recall discussions over
+"mentioned", "named", and "corresponding".) This case is especially bad because
+of the clear definition of similar cases. In any case, "if in doubt, spell it
+out"!! Electrons are cheap.
+
+As for "predicate" goes, the term is defined in paragraph 3.2.4(6/3) [you
+apparently thought *that* term needed to be defined!], it's in the index as
+such, and therefore I have no idea what John is complaining about there. Even if
+you are worried that the defined term is "predicate of a subtype", the actual
+sentence "value of that subtype that satisfies the predicate" surely makes it
+clear enough that it is the predicate of the subtype that we're talking about.
+
+> A predicate is satisfied if it's true. Pretty simple.
+>
+> > > The language specifically defines what it means to "satisfy" each
+> > > individual kind of constraint (see, for instance,
+> 3.6.1(7), 3.5(4), 3.7.1(11)).
+>
+> OK, but those are really just telling us what the predicate
+> (math-wise) is.
+
+Give me a break. This defines the technical meaning of "satisfies", no more and
+no less -- there is no predicate to be seen here, even in an expansive sense.
+
+I think you are making this up as you go along...
+
+> > > ...There
+> > > has to be such a statement in 3.2.4. "A value *satisfies* a
+> > > predicate if the predicate evaluates to True for the
+> > > value." Or something like that. But...
+>
+> If you insist on such wording, please can't we make it simple:
+> "A value *satisfies* a predicate if it is True for that value."
+> "evaluates to" adds nothing.
+
+I do insist on such wording, but I don't care that much about the exact details.
+I was just echoing the wording of 3.2.4(18/3) -- this rule will be very close to
+that one (probably directly following it). Given that this is a dynamic term
+that potentially could apply to dynamic predicates (even if the current wording
+doesn't use it that way), it seemed best to use similar wording. (And it still
+does.)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, August 19, 2011 4:45 PM
+
+> > Can't we rely on math-guy English in the RM?
+
+> No, with the exception of technical terms. The standard explicitly
+> says that we rely on the meaning of words from some particular
+> dictionary if they are not defined by the Standard.
+
+That part is fairly bogus.
+
+> So, I disagree that "satisfies" is that well defined. I realize that
+> anyone that basically understands Ada can figure out what is meant, but "satisfies"
+> doesn't add anything to that -- you could have said that the "value
+> bellywomps the predicate" and it would have made just as much sense.
+
+[snipped all sorts of useful and correct argumentation]
+
+OK, I cry "Uncle!".
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, August 22, 2011 4:12 AM
+
+...
+> My problem is that it doesn't say what predicate we are talking about.
+> In other words, it doesn't define "predicate" in the context. I am
+> happy with satisfy.
+>
+> And I totally disagree with Bob that predicate is plain English as
+> understood my maths folk in general. I certainly never used the word
+> when I did maths at Cambridge. I must admit we never studied logic -
+> probably considered too elementary. It's OK for formal methods folk -
+> a very specialzed community - and we ought to make the RM
+> understandable by typcial programmers if possible. When I encountered
+> it, I was looking for a bit of syntax called predicate or some such.
+
+I see now that in 3.2.4(6/3) it defines the predicate of a subtype. Is that what
+we are talking about? It also says that if no subtype predicates apply then the
+predicate is true. Sounds like a null event then.
+
+In 3.8.1(15/3) again says "that satisfy the predicate" . I ask again what
+predicate? Is this really all about subtype predicates in which case there
+should be a reference to 3.2.4 in the appropriate places.
+
+Maybe it would be clearer to say "that satisfies its predicate" in which case we
+would know to look for the predicate of the subtype and not to some other
+predicate which does not exist.
+
+I hadn't realised that the (evil) tentacles of subtype predicates had spread all
+over the language. You may recall that I was unwell when this was dscussed and
+missed a couple of meetings. And of course we didn't do a formal editorial
+review of these later AIs otherwise I would have mentioned this earlier.
+
+I found subtype predicates distasteful when writing the intro to teh rat.
+
+
+Incidentally, a fellow member of the ARG (of mathematical inclination) sent me a
+private mesage to say that a predicate is verb plus object. Indeed, if you had
+asked me what a predicate was when I had just finished my maths degree at
+Cambridge I would have said just that.
+
+Anyway, we need to make this stuff intelligible to a bright programmer writing
+Ada programs for real applications. So it has to be accessible to hairy
+electronic engineers as well as to pure program provers.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September 22, 2011 7:22 PM
+
+To reply to John's old message that came while I was on vacation:
+
+...
+> I see now that in 3.2.4(6/3) it defines the predicate of a subtype. Is
+> that what we are talking about? It also says that if no subtype
+> predicates apply then the predicate is true. Sounds like a null event
+> then.
+
+Yes, that is what we're talking about. It's the only use of "predicate" in the
+Ada language, so there can't be any confusion.
+
+> In 3.8.1(15/3) again says "that satisfy the predicate" . I ask again
+> what predicate? Is this really all about subtype predicates in which
+> case there should be a reference to 3.2.4 in the appropriate places.
+
+Generally, we only put in cross-references if the reference is a forward
+reference to a term not yet defined. In this case, the term is defined earlier
+in the Standard, so we don't put in a cross-reference.
+
+Given that the Standard is rarely read in a linear fashion, it would make some
+sense to relax that principle. But it would be hard to know where to draw the
+line. This case is close enough to the line to add the reference (so I did so).
+
+In any case, the first thing to do when confronted with a term that is
+unfamiliar is to look it up in the index. If that doesn't help, then complain
+(loudly) both about the term AND the index.
+
+> Maybe it would be clearer to say "that satisfies its predicate" in
+> which case we would know to look for the predicate of the subtype and
+> not to some other predicate which does not exist.
+
+I suppose. Or we could add "of the subtype" after predicate. But that seems like
+more words, and "its" is probably good enough here.
+
+> I hadn't realised that the (evil) tentacles of subtype predicates had
+> spread all over the language. You may recall that I was unwell when
+> this was dscussed and missed a couple of meetings. And of course we
+> didn't do a formal editorial review of these later AIs otherwise I
+> would have mentioned this earlier.
+
+That's kinda the point of this review, so don't worry about that. As far as
+"predicates all over the language" goes, that also was kinda the point -- the
+whole idea was to allow static predicates in case statements, so it is necessary
+to explain what that means for case coverage. Anytime we add anything, it ends
+up having consequences "all over the language" (think of the number of places
+that we've had to add aspects or conditional expressions).
+
+> I found subtype predicates distasteful when writing the intro to teh
+> rat.
+
+I think you're just getting grumpy. I see that happening to me, too, because
+changes mean more work for me but usually not more money. But I think most of
+these changes are for the better (especially aspects and predicates).
+
+> Incidentally, a fellow member of the ARG (of mathematical
+> inclination) sent me a private mesage to say that a predicate is verb
+> plus object.
+> Indeed, if you had asked me what a predicate was when I had just
+> finished my maths degree at Cambridge I would have said just that.
+>
+> Anyway, we need to make this stuff intelligible to a bright programmer
+> writing Ada programs for real applications. So it has to be accessible
+> to hairy electronic engineers as well as to pure program provers.
+
+Fair enough - again, that's the point of these reviews.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, September 23, 2011 10:23 AM
+
+Many thanks for your reply which settles that one nicely. And I do know
+that I am getting more grumpy!
****************************************************************
Questions? Ask the ACAA Technical Agent