CVS difference for ai12s/ai12-0159-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0159-1.txt

--- ai12s/ai12-0159-1.txt	2015/03/25 23:15:02	1.2
+++ ai12s/ai12-0159-1.txt	2015/03/26 04:54:17	1.3
@@ -1,7 +1,20 @@
 !standard 3.5.9(6)                                     15-03-25  AI05-0159-1/02
+!standard 6.1.1(7/4)
+!standard 6.1.1(26.4/4)
+!standard 6.1.1(37/4)
+!standard 6.3.1(12/4)
+!standard 6.3.1(13/4)
+!standard 6.4.1(5)
+!standard 6.4.1(6.26/4)
+!standard 6.4.1(6.27/4)
+!standard 6.4.1(6.28/4)
+!standard 6.4.1(6.29/4)
+!standard 6.4.1(13.1/4)
 !standard 7.3.2(10/4)
 !standard 7.3.2(21/4)
 !standard 7.3.2(22.1/4)
+!standard 11.3(2/4)
+!standard 11.3(3.2/4)
 !standard 11.3(4.1/4)
 !standard A(3.1/4)
 !standard A.18.10(2/4)
@@ -34,6 +47,49 @@
 
 (6) In 11.3(4.1/4), "rather than" sounds odd. Wouldn't "instead of" be better?
 
+(7) In 11.3(3/4), the original "if any" text makes more sense. Should it be
+replaced? (Yes.)
+
+(8) The type of a raise_expression is too vague. We don't want it to match
+anything in any circumstance, else it becomes impossible to enforce Legality
+Rules that depend on the type of an expression. (For instance, in an extension
+aggregate ((raise Something) with ...), does (raise Something) have a specific
+tagged type?) Should this be fixed? (Yes.)
+
+(9) The last two sentences of 6.1.1(7/4) are non-normative discussion that
+better belongs in the AARM. Should it be moved there? (Yes.)
+
+(10) In 6.3.1(12/4), the first and third (existing) cases start "for a", but
+the (new) second case starts just "a". Should a third "for" be added? (Yes.)
+Similarly 6.3.1(13/4) should include "for", right? (Yes.)
+
+(11) 6.4.1(6.26-6.29/4) look like a continuation of the rules above them
+6.4.1(6.18-6.25/3), but they're not. Would these be better placed after
+6.4.1(5)? (Yes.)
+
+(12) In 6.4.1(13.1-4/4), the "except in the following case:" is awkward
+and ambiguous. Can we do better? (Yes.)
+
+(13) 6.4.1(26.4/4) says "is of an anonymous access, ...". Is the word "type"
+missing here? (Yes.)
+
+(14) 6.1.1(37/4) starts out with
+    For any subprogram or entry call S (including dispatching calls),
+
+which suggests that S is the call (i.e., an expression or statement), not the
+callee (i.e., a subprogram). The rest of the paragraph goes on to treat S as
+though it is the callee.
+
+Contrast this with the correct phrasing in paragraph 38:
+   The class-wide precondition check for a call to a subprogram
+   or entry S...
+
+Should this be fixed? (Yes.)
+
+(15) 4.1.4(9/4) mentions "without constraint or null exclusion" without
+mentioning predicates, which presumably are also ignored here. Should they
+be mentioned? (Yes.)
+
 !recommendation
 
 (See Summary.)
@@ -115,6 +171,121 @@
 exception, that exception is propagated {instead of}[rather than] the one
 denoted by the exception_name of the raise_statement or raise_expression.
 
+(7)
+
+Modify 11.3(3/4): [Taft]
+
+[An exception_name]{The exception_name, if any} of a raise_statement
+or raise_expression ...
+
+[Editor's note: Careful: if we don't use "if any" here, revisit the wording
+of 11.3(3.1/4), which also uses "if any" after Editorial Review.]
+
+(8)
+
+Replace 11.3(3.2/4) by: [Taft]
+
+   The expected type for a raise_expression shall be any single type.
+
+(9)
+
+Modify 6.1.1(7/4): [Ploedereder]
+
+Within the expression for a Pre'Class or Post'Class aspect for a 
+primitive subprogram S of a tagged type T, a name that denotes a 
+formal parameter (or S'Result) of type T is interpreted as though it 
+had a (notional) type NT that is a formal derived type whose ancestor 
+type is T, with directly visible primitive operations. Similarly, a 
+name that denotes a formal access parameter (or S'Result) of type 
+access-to-T is interpreted as having type access-to-NT. [The result of 
+this interpretation is that the only operations that can be applied to 
+such names are those defined for such a formal derived type. This 
+ensures that the expression is well-defined for any primitive 
+subprogram of a type descended from T.]
+
+Add an AARM note:
+
+Reason: The result of this interpretation is that the only operations
+that can be applied to  such names are those defined for such a formal
+derived type. This  ensures that the expression is well-defined for
+any primitive subprogram of a type descended from T.
+
+[Editor's note: 7.3.2(5/4) has the same wording, which should get the same
+treatment, if any. See discussion.]
+
+(10)
+
+Modify 6.3.1(12/4): [Ploedereder]
+
+* The default calling convention is *protected* for a protected 
+  subprogram, {for} a prefixed view of a subprogram with a synchronization 
+  kind of By_Protected_Procedure, and for an access-to-subprogram type 
+  with the reserved word protected in its definition.
+
+Modify 6.3.1(13/4): [Baird]
+* The default calling convention is *entry*
+  for an entry and {for} a prefixed view of a subprogram with
+  a synchronization kind of By_Entry.
+
+(11)
+
+Move 6.4.1(6.26-6.29/4) after 6.4.1(5). [Ploedereder]
+
+(12)
+
+Modify 6.3.1(13.1/4): [Ploedereder]
+
+* For a scalar type that has the Default_Value aspect specified, the 
+  formal parameter is initialized from the value of the actual, without 
+  checking that the value satisfies any constraint or any predicate{.
+  If, however, }[, except in the following case: if] the actual parameter is
+  a view conversion and either
+
+(13)
+
+Modify 6.1.1(26.4/4): [Baird]
+
+ * If X is of an anonymous access {type} defined by an access_definition
+   A then
+
+(14)
+
+Modify 6.1.1(37/4): [Baird]
+
+For any {call to a} subprogram or entry [call] S (including dispatching
+calls), the checks
+that are performed to verify specific precondition expressions and specific
+and class-wide postcondition expressions are determined by those for the
+subprogram or entry actually invoked. Note that the class-wide postcondition
+expressions verified by the postcondition check that is part of a call on a
+primitive subprogram of type T includes all class-wide postcondition
+expressions originating in any progenitor of T, even if the primitive
+subprogram called is inherited from a type T1 and some of the postcondition
+expressions do not apply to the corresponding primitive subprogram of T1.
+Any operations within a class-wide postcondition expression that were
+resolved as primitive operations of the (notional) formal derived type NT,
+are in the evaluation of the postcondition bound to the corresponding
+operations of the type identified by the controlling tag of the call on
+S. This applies to both dispatching and non-dispatching calls on S.
+
+(15)
+
+Modify 4.1.4(9/4): [Baird]
+
+An attribute_reference denotes a value, an object, a subprogram, or some
+other kind of program entity. Unless explicitly specified otherwise, for 
+an attribute_reference that denotes a value or an object, if its type is
+scalar, then its nominal subtype is the base subtype of the type; if its
+type is tagged, its nominal subtype is the first subtype of the type;
+otherwise, its nominal subtype is a subtype of the type without any
+constraint{,}[ or] null_exclusion{, or predicate}. Similarly, unless
+explicitly specified otherwise, for an attribute_reference that denotes a
+function, when its result type is scalar, its result subtype is the base
+subtype of the type, when its result type is tagged, the result subtype
+is the first subtype of the type, and when the result type is some other
+type, the result subtype is a subtype of the type without any
+constraint{,}[ or] null_exclusion{, or predicate}. 
+
 !discussion
 
 (1) This appears to be an oversight.
@@ -135,7 +306,68 @@
 to 55) Still, "instead of" sounds better to the Editor's ear as well as the
 commenter.
 
+(7) The wording was changed from the original "if any" wording (which is now the
+new wording), to the "An" wording, during discussion during the Stockholm ARG
+meeting. The objection appears to have been that the exception_name is not
+optional for a raise_expression, so "if any" is weird.
+
+Reverting the wording of course also brings back the objection. We'll have to
+discuss this to see which is stronger.
+
+(8) The suggested wording is similar to the way aggregates and string literals
+work, other entities that themselves do not provide a type.
+
+(9) The last sentence of 6.1.1(7/4) comes unmodified from Ada 2012 text.
+The penultimate sentence was added to explain the last sentence. If the last
+sentence was valuable for Ada 2012, it's even more valuable now, as the
+semantics are less intuitive.
+
+An alternative would a user note, but of course that is not near the rules
+in question.
+
+The author of this AI would rather not make this change, but it's a close call.
+
+(10) These are uninitended inconsistencies in wording.
+
+(11) In addition to the reason given in the question, the reviewer gave two
+additional reasons to move this text. First, he notes that paragraphs 6 all the
+way to 6.25 talks about alias rules, while the new text is about initialization.
+
+There are several unrelated rules in that large clump of text; in particular the
+first 5 paragraphs are about aliased parameters while the rest are about
+anti-aliasing in calls.
 
+Indeed, the best place to move these rules would be after 6.4.1(6.4/3), except
+for the fact that inserting them there would change all of the paragraph
+numbers following (we don't allow inserts of inserts for paragraph numbers).
+
+The reviewer also stated that it remains unclear to which rules the "these rules
+also apply"-boilerplate is referring: only to the last two bullets or to all
+the aliasing rules as well.
+
+While this is true, with one well-known exception, the boilerplate can and
+probably should apply to all Legality Rules. For many rules (those that can't
+depend in any way on the properties of a generic formal), it doesn't matter
+either way. For the rest, experience says that they almost always have to be
+rechecked. So this is a weak reason to move the rules.
+
+Still, after 6.4.1(5) is the only sensible alternative for the placement of
+these rules. It's either there or leave them where they are.
+
+(12) Since this additional text specifies an additional, non-optional check,
+it doesn't really matter to which it applies, other than the part about
+"for a scalar type with Default_Value specified". Thus separating it as
+suggested (or even making it a separate paragraph under the same bullet) is
+OK.
+
+(13) "anonymous access" by itself doesn't mean anything, it needs to modify
+something. In this case, that's a type.
+
+(14) The questioner is correct about the change in meaning of S. The wording
+should be fixed.
+
+(15)
+
 !corrigendum 3.5.9(6)
 
 @dinsa
@@ -377,6 +609,126 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Monday, March  9, 2015  3:21 PM
+
+Here are my comments.  I reviewed the text in the AARM PDF.
+...
+[Editor's note: Only normative comments that caused items in this AI are
+recorded here. That goes for much of the following mail through March 25, 2015.]
+
+11.2(3/4) "[An exception_name]{The exception_name, if any} of a raise_statement
+or raise_expression ..." (AI12-0022-1)
+
+11.2(3.1/4) "[A string_expression]{The string_expression or 
+string_simple_expression, if any} of a raise_statement or raise_expression,
+..." (AI12-0022-1)
+
+11.2(3.2/4) "A raise_expression is expected to be of any type." doesn't make 
+sense to me. I believe this should say:
+
+    "The expected type for a raise_expression shall be any single type."
+
+analogous to the way aggregates and string literals work. (AI12-0022-1)
+...
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, March 11, 2015  2:12 PM
+
+...
+Typo (missing word "type") in 6.1.1(26.4/4)
+
+    If X is of an anonymous access [type]
+    defined by an access_definition A then
+
+====
+
+6.1.1(37/4) starts out with
+    For any subprogram or entry call S (including dispatching calls),
+
+which suggests that S is the call (i.e., an expression or statement), not
+the callee (i.e., a subprogram). The rest of the paragraph goes on to treat
+S as though it is the callee.
+
+Contrast this with the correct phrasing in paragraph 38:
+   The class-wide precondition check for a call to a subprogram
+   or entry S
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, March 12, 2015  1:30 PM
+
+
+I've sent the simple editorial ones to Randy and Jeff in a separate message.
+
+These are the more interesting ones.
+
+====
+
+In 4.1.4 we've got
+
+   Unless explicitly specified otherwise, for an attribute_reference
+   that denotes a value or an object, if its type is scalar, then its
+   nominal subtype is the base subtype of the type; if its type is
+   tagged, its nominal subtype is the first subtype of the type;
+   otherwise, its nominal subtype is a subtype of the type without
+   any constraint or null_exclusion.
+
+a) I don't think "first subtype" is defined for a generic formal type
+    (and this definition occurs in a "static semantics" section).
+
+b) "without any constraint or null_exclusion" doesn't mention
+    predicates.
+
+I haven't tried to find a specific attribute where either of these makes a
+difference. Randy pointed out (in private communication) that the "first
+subtype" issue might be a problem in other (static semantics) contexts
+where that term is used.
+
+====
+
+In 4.1.6, we've got a new note
+    The Constant_Indexing and Variable_Indexing aspects
+    cannot be redefined when inherited for a derived type,
+    but the functions that they denote can be modified by overriding
+    or overloading.
+
+I'm thinking about the case of a derived type which inherits, say, a
+Constant_Indexing aspect. I think the RM wording correctly handles this case
+but it is obscure enough that a clarifying note is needed.
+
+The crux of the matter is the name resolution rule
+
+   When a generalized_indexing is interpreted as a constant (or
+   variable) indexing, it is equivalent to a call on a prefixed view of
+   one of the functions named by the Constant_Indexing (or
+   Variable_Indexing) aspect of the type of the
+   indexable_container_object_prefix with the given
+   actual_parameter_part, and with the indexable_container_object_prefix
+   as the prefix of the prefixed view.
+
+and the meaning, in the case of a derived type which inherits the aspect, of
+the phrase
+
+   "the functions named by the Constant_Indexing (or
+    Variable_Indexing) aspect of the type"
+.
+
+We want that phrase to mean the set of subprograms where the equivalent
+prefixed call would work as defined in 4.1.3(9.2/3).
+And it does mean that - the wording is correct; the name given in the aspect
+spec is, roughly speaking, re-resolved in the context of the derived type.
+
+My point is that this is far from obvious. I was quite confused about this
+until Randy pointed out to me the significance of the use of the word "named"
+instead of "denoted". This is subtle stuff and there is nothing similar to
+this kind of re-resolution in other Ada constructs.
+
+****************************************************************
+
 From: Brad Moore
 Sent: Sunday, March 15, 2015  1:36 PM
 
@@ -519,5 +871,93 @@
 Sent: Wednesday, March 24, 2015  2:57 AM
 
 Maybe "and also" rather than just "and" after the bold comma would help
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, March 23, 2015  7:53 PM
+
+Results of my review ... I have not yet followed John's suggestion of
+reading everything in AA context, but I figured that you wanted stuff
+now...not sure I can get to the AA review before Thu.
+
+-=====================
+
+for 6.1.1.
+
+> Replace paragraph 7: [8652/0145]
+> ...
+> by:
+> Within the expression for a Pre'Class or Post'Class aspect for a 
+> primitive subprogram S of a tagged type T, a name that denotes a 
+> formal parameter (or S'Result) of type T is interpreted as though it 
+> had a (notional) type NT that is a formal derived type whose ancestor 
+> type is T, with directly visible primitive operations. Similarly, a 
+> name that denotes a formal access parameter (or S'Result) of type 
+> access-to-T is interpreted as having type access-to-NT. The result of 
+> this interpretation is that the only operations that can be applied to 
+> such names are those defined for such a formal derived type. This 
+> ensures that the expression is well-defined for any primitive 
+> subprogram of a type descended from T.
+
+The last sentence is clearly not RM style. Turn it into an AARM statement.
+
+The penultimate sentence is neither, in my opinion (even if could pass as
+derivable semantics in the RM). Still, I have the same suggestion.
+
+...
+========================
+
+for 6.3.1.
+
+> Replace paragraph 12: [8652/0147]
+> ...
+> by:
+>  The default calling convention is protected for a protected 
+> subprogram, a prefixed view of a subprogram with a synchronization 
+> kind of By_Protected_Procedure, and for an access-to-subprogram type 
+> with the reserved word protected in its definition.
+
+Make that:
+
+ The default calling convention is protected for a protected subprogram, for
+  a prefixed view of a ...
+
+to be uniform with the 1. and 3. case.
+
+===========================
+
+for 6.4.1.
+
+> Insert after paragraph 6.25: [8652/0138] ...
+> the new paragraph:
+> If the mode is out, the actual parameter is a view conversion ....
+
+I urge insertion after paragraph 5 instead. Several reasons:
+- Para 6 all the way to 6.25 talks about alias rules, while the new text is
+  about initialization.
+- The text syntactically reads like a continuation of 6.25, but isn't.
+- It remains unclear to which rules the "these rules also apply"-boilerplate
+  is referring: only to the last two bullets or to all the aliasing rules as
+  well.
+
+
+> Replace paragraph 13.1: [8652/0138]
+> ....
+> by:
+>  For a scalar type that has the Default_Value aspect specified, the 
+> formal parameter is initialized from the value of the actual, without 
+> checking that the value satisfies any constraint or any predicate, 
+> except in the following case: if the actual parameter is a view 
+> conversion and either  there exists no type (other than a root 
+> numeric type) that is an ancestor of both the target type and the type 
+> of the operand of the conversion; or  the Default_Value aspect is 
+> unspecified for the type of the operand of the conversion then 
+> Program_Error is raised;
+
+The "except in the following case"-construct reads really awkwardly and is
+quite ambiguous whether it refers to the checking or to the initializing.
+But I have no good suggestion either. Best I could do is to replace it by
+"...predicate. If, however, the actual ...."
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent