CVS difference for 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