!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
!status received 11-07-21
!priority Medium
!difficulty Easy
!subject Rewordings from the Second Editorial Review
!summary


Change wording of existing approved AIs as suggested by various
ARG members and the public during the second editorial review of the draft
standard.

!question

Some of the new wording in the standard is unnecessarily confusing.
Should we improve it? (Yes.)

!recommendation
(See Summary.)

!wording

[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
iteration_scheme being for iterator_specification, see 5.5.2.]

Modify 6.1.1(3/3):

This aspect specifies a class-wide precondition for {an operation of a tagged type}[a
callable entity] and its descendants; ...

Modify 6.1.1(5/3):

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.

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
@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> (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.
@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.

!corrigendum 6.1.1(0)

@dinsc

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
If Storage_Pool is specified for an access type, then if Allocate can satisfy
the request, it should allocate a contiguous block of memory, and return the
address of the first storage element in Storage_Address. The block should
contain Size_In_Storage_Elements storage elements, and should be aligned
according to Alignment. The allocated storage should not be used for any other
purpose while the pool element remains in existence. If the request cannot be
satisfied, then Allocate should propagate an exception (such as Storage_Error).
If Allocate behaves in any other manner, then the program execution is
erroneous.
@dinst
For each of the calls of Allocate described above, @i<P> (equivalent to
@i<T>'Storage_Pool) is passed as the Pool parameter. The
Size_In_Storage_Elements parameter indicates the number of storage elements to
be allocated, and is no more than @i<D>'Max_Size_In_Storage_Elements, where
@i<D> is the designated subtype of @i<T>. The Alignment parameter is at least
@i<D>'Alignment if @i<D> is a specific type, and otherwise is at least the
alignment of the specific type identified by the tag of the object being
created. The Alignment parameter is no more than
@i<D>'Max_Alignment_For_Allocation. The result returned in the Storage_Address
parameter is used as the address of the allocated storage, which is a contiguous
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.

!ASIS

No change needed.

!appendix

From: Randy Brukardt
Sent: Monday, July 18, 2011  10:23 PM

Question of very low importance:

Grein, Christoph wrote:
...
> 5.5 seems incomplete.
> 5.5(7) says: "The loop_statement is complete when a transfer of
> control occurs that transfers control out of the loop, or, in the case
> of an iteration_scheme, as specified below."
> But there is nothing said about iterator_specification.
> Perhaps a reference to 5.5.2 should be added.

"iteration_scheme" clearly includes "iterator_specification", so there is
nothing missing in 5.5(7). The "completion" conditions for iterator
specifications are specified in 5.5.2(10/3, 11/3, and 13/3), so these are in
fact defined. "below" in technical writing generally means "anywhere after this
point in the text" (it is not restricted to the same subclause), and 5.5.2
surely follows 5.5, and even is part of the same clause (all being parts of
5.5), so there is nothing actually wrong here.

However, that is the pedantic answer. It probably wouldn't hurt to put a
cross-reference into the text somewhere. The best way to do that is less than
obvious, however.

We could stick something on the end of 5.5(7):

"The loop_statement is complete when a transfer of control occurs that transfers
control out of the loop, or, in the case of an iteration_scheme, as specified
below. (For iterator_specifications, see 5.5.2.)"

But that doesn't read well, because it seems to contradict "below". (Also see
the next item.)

An alternative is to put the text as a redundant paragraph following 5.5(9):

Redundant[For the details of iterator_specifications, see 5.5.2.]

That reads better, but it is common that part of the semantics of something is
in another clause in the Standard. So it's a bit weird to say this explicitly
here.

Finally, we could just make it an AARM note as above:

Discussion: For the details of iterator_specifications, see 5.5.2.

Any thoughts??

****************************************************************

From: Christoph Grein
Sent: Tuesday, July 19, 2011  1:37 AM

I tend to this solution:

> Redundant[For the details of iterator_specifications, see 5.5.2.]
>
> That reads better, but it is common that part of the semantics of
> something is in another clause in the Standard. So it's a bit weird to
> say this explicitly here.
> ...
> Any thoughts??

This provides the most information for the (non-language-lawyer) reader at the
correct place. After all, the RM is already hard enough to read.

****************************************************************

From: Christoph Grein
Sent: Thursday, July 21, 2011  2:04 AM

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.

I think *one* is confusing here - it makes the reader wonder what about
the others. I think it should say *each* instead - or am I missing something?

****************************************************************

!topic Possible incorrect terminology in 6.1.1
!reference 6.1.1(3/3, 5/3), AARM 6.1.1(22.a/3)
!from Adam Beneschan 11-07-28
!discussion

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
unclear; but since paragraphs 3 and 5 are in a normative part of the
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
to types, not the one that applies to library units.  I'm not sure if
this is a problem.

****************************************************************

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,
> 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
> unclear; but since paragraphs
> 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
(no entries can be primitive operations of a tagged type) is in
13.3.1(28/3) [this paragraph number may have changed since draft 12]:

If the aspect_mark includes 'Class, then:
...
if the associated entity is a primitive subprogram of a tagged type T, the
specification applies to the corresponding primitive subprogram of all descendants
of T.

The wording in 6.1.1(3/3) and 6.1.1(5/3) is intended to be a more informal
description. And I wouldn't call it "incorrect" (since the semantics are defined
formally elsewhere), just "undefined".

But I do agree that it is somewhat uncomfortable to have undefined terminology in
the normative wording, especially as it is the first description of the aspects.
Repeating 6.1.1(18/3) [probably was 14/3 in draft 12, but 6.1.1 was changed a lot
in Edinburgh] isn't helpful and would potentially cause a maintenance problem.

So I have no better idea than the current wording.

****************************************************************

From: Tucker Taft
Sent: Tuesday, August 2, 2011  11:16 AM

How about:

3/3
Pre'Class
This aspect specifies a class-wide precondition for an operation of a tagged
type and its descendants; ...

5/3
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!

****************************************************************