Version 1.3 of ai05s/ai05-0262-1.txt

Unformatted version of ai05s/ai05-0262-1.txt version 1.3
Other versions for file ai05s/ai05-0262-1.txt
!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)
Insert after the paragraph:
the new paragraph:
!corrigendum 3.2.4(0)
Insert new clause:
Force a conflict; the real text is found in the conflict file.
!corrigendum 3.3(19)
Replace the paragraph:
by:
!corrigendum 3.3.1(1)
Replace the paragraph:
An object_declaration declares a stand-alone object with a given nominal subtype and, optionally, an explicit initial value given by an initialization expression. For an array, task, or protected object, the object_declaration may include the definition of the (anonymous) type of the object.
!corrigendum 3.5(30/2)
Replace the paragraph:
The function returns an image of the value of Arg as a Wide_String. The lower bound of the result is one. The image has the same sequence of 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).
by:
The function returns an image of the value of Arg as a Wide_String. The lower bound of the result is one. The image has the same sequence of graphic characters as defined for S'Wide_Wide_Image if all the graphic characters are defined in Wide_Character; otherwise, the sequence of characters is implementation defined (but no shorter than that of S'Wide_Wide_Image for the same value of Arg).
!corrigendum 3.8.1(10)
Replace the paragraph:
by:
!corrigendum 3.8.1(11)
Replace the paragraph:
by:
!corrigendum 3.8.1(15)
Replace the paragraph:
by:
!corrigendum 3.9(25.1/2)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
In the above rules, the operand of a view conversion, parenthesized expression or qualified_expression is considered to be used in a context if the view conversion, parenthesized expression or qualified_expression itself is used in that context.
by:
In the above rules, the operand of a view conversion, parenthesized expression or qualified_expression is considered to be used in a context if the view conversion, parenthesized expression or qualified_expression itself is used in that context. Similarly, 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.
!corrigendum 4.3.3(18)
Replace the paragraph:
In a named_array_aggregate 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.
by:
In a named_array_aggregate where all discrete_choices are static, 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.
!corrigendum 4.5.2(2)
Replace the paragraph:
A membership test, using in or 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.
by:
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)
Insert after the paragraph:
the new paragraph:
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)
Replace the paragraph:
N not in 1 .. 10 -- range membership test Today in Mon .. Fri -- range membership test Today in Weekday -- subtype membership test (see 3.5.1) Archive in Disk_Unit -- subtype membership test (see 3.8.1) Tree.all in Addition'Class -- class membership test (see 3.9.1)
by:
N not in 1 .. 10 -- range membership test Today in Mon .. Fri -- range membership test Today in Weekday -- subtype membership test (see 3.5.1) Card in Clubs | Spades -- list membership test (see 3.5.1) Archive in Disk_Unit -- subtype membership test (see 3.8.1) Tree.all in Addition'Class -- class membership test (see 3.9.1)
!corrigendum 4.5.7(0)
Insert new clause:
Force a conflict; the real text is found in the conflict file.
!corrigendum 4.9(33)
Insert new clause:
Force a conflict; the real text is found in the conflict file.
!corrigendum 4.9(34)
Replace the paragraph:
>
by:
!corrigendum 5.4(7)
Replace the paragraph:
by:
!corrigendum 5.5(9)
Replace the paragraph:
For the execution of a loop_statement with a for iteration_scheme, the loop_parameter_specification is first elaborated. This elaboration creates the loop parameter and elaborates the discrete_subtype_definition. If the discrete_subtype_definition defines a subtype with a null range, the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed once for each value of the discrete subtype defined by the 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 reverse is present, in which case the values are assigned in decreasing order.
by:
For the execution of a loop_statement with a for iteration_scheme, the loop_parameter_specification is first elaborated. This elaboration creates the loop parameter and elaborates the discrete_subtype_definition. If the discrete_subtype_definition defines a subtype with a null range, the execution of the loop_statement is complete. Otherwise, the sequence_of_statements is executed once for each value of the discrete subtype defined by the 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 reverse is present, in which case the values are assigned in decreasing order.
For details about the execution of a loop_statement with the iteration_scheme being for iterator_specification, see 5.5.2.
!corrigendum 6.1.1(0)
Insert new clause:
Force a conflict; the real text is found in the conflict file.
!corrigendum 6.2(3)
Replace the paragraph:
A type is a 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.
by:
A type is a 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)
Replace the paragraph:
Two profiles are 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.
by:
Two profiles are mode conformant if:
!corrigendum 6.3.1(18)
Replace the paragraph:
Two profiles are fully conformant if they are subtype-conformant, and corresponding parameters have the same names and default_expressions that are fully conformant with one another.
by:
Two profiles are fully conformant if they are subtype-conformant, if they have access-to-subprogram results whose designated profiles are fully conformant, and for corresponding parameters:
!corrigendum 6.6(3)
Replace the paragraph:
The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters.
by:
The subprogram_specification of a unary or binary operator shall have one or two parameters, respectively. The parameters shall be of mode in. A generic function instantiation whose designator is an operator_symbol is only allowed if the specification of the generic function has the corresponding number of parameters, and they are all of mode in.
!corrigendum 6.8(0)
Insert new clause:
Force a conflict; the real text is found in the conflict file.
!corrigendum 7.4(6/2)
Replace the paragraph:
by:
!corrigendum 7.5(2.1/2)
Replace the paragraph:
In the following contexts, an expression of a limited type is not permitted unless it is an aggregate, a function_call, or a parenthesized expression or qualified_expression whose operand is permitted by this rule:
by:
In the following contexts, an expression of a limited type is not permitted unless it is an aggregate, a function_call, a parenthesized expression, or qualified_expression whose operand is permitted by this rule, or a conditional_expression all of whose dependent_expressions are permitted by this rule:
!corrigendum 7.6.1(13.1/2)
Replace the paragraph:
In the case of an expression that is a master, finalization of any (anonymous) objects occurs as the final part of evaluation of the expression.
by:
In the case of an expression that is a master, finalization of any (anonymous) objects occurs after completing evaluation of the expression and all use of the objects, prior to starting the execution of any subsequent construct.
!corrigendum 7.6.1(20)
Insert after the paragraph:
the new paragraph:
Implementation Permissions
If the execution of an 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 allocator.
The implementation may finalize objects created by allocators 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)
Replace the paragraph:
by:
!corrigendum 10.1.1(12.3/2)
Replace the paragraph:
by:
!corrigendum 13.11(21)
Insert after the paragraph:
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.
the new paragraph:
For each of the calls of Allocate described above, P (equivalent to 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 D'Max_Size_In_Storage_Elements, where D is the designated subtype of T. The Alignment parameter is at least D'Alignment if 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 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)
Insert new clause:
Force a conflict; the real text is found in the conflict file.
!corrigendum A.18.18(0)
Insert new clause:
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!

****************************************************************
Questions? Ask the ACAA Technical Agent