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

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

--- ai12s/ai12-0407-1.txt	2020/11/24 06:43:14	1.1
+++ ai12s/ai12-0407-1.txt	2020/11/28 07:41:17	1.2
@@ -1,4 +1,8 @@
-!standard 13.1.1(17/5)                                 20-11-23  AI12-0407-1/01
+!standard 12.3(15)                                      20-11-27  AI12-0407-1/02
+!standard 13.1(8/5)
+!standard 13.1(8.1/3)
+!standard 13.1.1(17/5)
+!standard 13.14(7.2/5)
 !standard A.5.6(3/5)
 !standard A.5.6(15/5)
 !standard A.5.7(3/5)
@@ -25,6 +29,16 @@
 (3) Aspect No_Controlled_Parts is a representation aspect that looks through
 privacy.
 
+(4) Aspect_definitions are frozen at the freezing point of the entity if
+the aspect is needed for future static semantics and legality checks.
+The freezing point of an aspect_specification given on a construct that is
+not a declaration is considered to occur immediately after the specification.
+
+(5) A definition of type-related aspects is added.
+
+(6) We allow aspects to differ for the replicated actual of a generic formal 
+type.
+
 !problem
 
 (1) AI12-0394-1 added a mechanism to use named numbers with user-defined 
@@ -45,6 +59,25 @@
 controlled components in a private type. That would defeat the purpose of the
 aspect.
 
+(4) The updated rules 13.14(7.2/5) and 13.14(15.2/5) for freezing of 
+aspect_specifications do not cover all possible operational aspects, and
+potentially could defer freezing of operation aspects until after they are 
+needed to enforce a Legality Rule. We don't want constructs for which there is
+no freezing rules defined, and we certainly don't want freezing to happen
+after something is used.
+
+(5) There is no definition of "type-related aspect" and "subtype-related
+aspect" in the RM. There is To Be Honest note that claims to do that, but
+it depends on a definition for representation items (and later, operational
+items). Aspects that do not have a representation item or an operation item
+are not normatively classified at all. Given that we have included
+"type-related" in a number of rules in 13.1, this oversight should be corrected.
+
+(6) 12.3(15) says that the properties of a generic formal parameter in an 
+instance are exactly the same as those of the actual. We allow adding
+additional Pre and Post assertions to generic formal subprograms, but there
+is no allowance for this difference in 12.3(15).
+
 !proposal
 
 (1) Add renamings of From_String to From_Universal_Image to both the 
@@ -58,18 +91,97 @@
 (3) Clarify that No_Controlled_Parts looks through privacy when enforcing its
 restrictions. Improve the generic assume-the-worst rules.
 
+(4) Revise 13.14(7.2/5) to make it clear that it applies to any aspect that
+is needed to enforce a Legality Rule, or otherwise affects static semantics.
+Also revise that paragraph to ensure that it covers aspect_specifications
+given on constructs that do not declare an entity.
+
+(5) Add a definition of type-related aspect and subtype-related aspect after
+13.1(8.1/3).
+
+(6) Add an exception to explicitly defined differences for a generic formal
+parameter in an instance.
+
 !wording
 
 [Editor's note: These changes were applied to Draft 27 of the Ada 202x RM, 
 even though they have not yet been approved, in order that that draft be as
 accurate as possible.]
 
+Modify 12.3(15):
+
+In an instance, a generic_formal_parameter_declaration declares a view 
+whose properties are identical to those of the actual, except {when}[as]
+specified {otherwise (in particular, see 6.1.1, "Preconditions and Postconditions",}
+[in] 12.4, "Formal Objects"{,} and 12.6, "Formal Subprograms". Similarly, for a 
+declaration within a generic_formal_parameter_declaration, the 
+corresponding declaration in an instance declares a view whose properties
+are identical to the corresponding declaration within the declaration of 
+the actual. 
+
+  AARM Reason: We allow differences in particular for aspects that can be 
+  specified on generic formal parameters. For instance, Pre (see 6.1.1) 
+  can be specified on generic formal subprograms to be added to the Pre 
+  of the actual.
+
+Modify 13.1(8/5):
+
+A representation item /directly specifies a representation aspect/ of the
+entity denoted by the local_name, except in the case of a type-related 
+representation item, whose local_name shall denote a first subtype, and 
+which directly specifies an aspect of the subtype's type. A representation
+item that names a subtype is either subtype-specific (Size, Object_Size, 
+and Alignment clauses) or type-related (all others). [Subtype-specific 
+aspects may differ for different subtypes of the same type.]
+
+[Editor's note: This last sentence is moved below.]
+
+Delete AARM 13.1(8.a).
+
+Add after 13.1(8.1/3):
+
+Aspects that can be specified for types and subtypes are also 
+classified into type-related or subtype-specific aspects. 
+Representation aspects that can be specified for types and subtypes 
+are considered type-related unless specified otherwise. In contrast, 
+the classification of operational aspects are given with the 
+definition of the aspect. Type-related aspects have the same value for all 
+subtypes of (a view of) a type@Redundant[, while subtype-specific aspects may 
+differ for different subtypes of the same type].
+
+  AARM Discussion: We talk about "type-related aspects", which of 
+  course include both type-related representation aspects and 
+  type-related operational aspects. Aspects Size, Object_Size, and
+  Alignment are subtype-specific, as that is specified above. All 
+  other representation aspects are either type-related or not 
+  specifiable for a type or subtype. Unlike representation 
+  aspects, there is no default for operational aspects; whether they 
+  are type-related or subtype-specific should be part of the definition 
+  of the aspect.
+
+
 Replace deleted 13.1.1(17/5) with:
 
 Unless otherwise specified for a specific aspect, a language-defined aspect
 cannot be specified on a renaming_declaration or a
 generic_formal_parameter_declaration.
 
+Modify 13.14(7.2/5):
+
+At the freezing point of the entity associated with an aspect_specification, 
+any static expressions within the aspect_specification cause freezing, as do
+expressions or names in aspect_definitions for representation aspects, or 
+operational aspects that have a corresponding operational attribute.
+{Similarly, if an aspect_definition for an operational aspect, other than an
+assertion aspect, could affect the Name Resolution, Static Semantics, or 
+Legality Rules of a subsequent construct, then any expressions or names 
+within the aspect_definition cause freezing at the freezing point of the 
+associated entity.} Any static expressions within an aspect_specification also
+cause freezing at the end of the immediately enclosing declaration list. 
+{For the purposes of this rule, if there is no declared entity associated with 
+an aspect_specification, the freezing point is considered to occur immediately 
+following the aspect_specification.}
+
 Modify A.5.6(3/5):
 
    type Big_Integer is private
@@ -150,6 +262,78 @@
 takes into account the possibility of nested or child generics. We change it
 to use that.
 
+(4) We want freezing rules to be defined for all kinds of aspects, since no
+one wants implementation-defined aspects to have to invent their own freezing
+rules.
+
+(5) The definition echoes the definition for representation items and for
+operational items. We also add an definition of "type-related" - the value is
+the same for all subtypes of a single view of the type. This has always been
+assumed but not stated.
+
+(6) We chose general wording about properties of generic formal parameters 
+beinging allowed to be different if there is an explicit rule to that effect,
+rather than a specific fix for specific aspects or just for aspects, in order
+that we don't have to revisit this paragraph when defining aspects or other
+characteristics in the future.
+
+!corrigendum 12.3(15)
+
+@drepl
+In an instance, a @fa<generic_formal_parameter_declaration> declares a view 
+whose properties are identical to those of the actual, except as specified 
+in 12.4, “Formal Objects” and 12.6, “Formal Subprograms”. Similarly, for a 
+declaration within a @fa<generic_formal_parameter_declaration>, the 
+corresponding declaration in an instance declares a view whose properties
+are identical to the corresponding declaration within the declaration of 
+the actual. 
+@dby
+In an instance, a @fa<generic_formal_parameter_declaration> declares a view 
+whose properties are identical to those of the actual, except when specified 
+otherwise (in particular, see 6.1.1, "Preconditions and Postconditions", 
+12.4, "Formal Objects", and 12.6, "Formal Subprograms"). Similarly, for a 
+declaration within a @fa<generic_formal_parameter_declaration>, the 
+corresponding declaration in an instance declares a view whose properties
+are identical to the corresponding declaration within the declaration of 
+the actual. 
+
+
+!corrigendum 13.1(8/3)
+
+@drepl
+A representation item @i<directly specifies> a @i<representation aspect> of
+the entity denoted by the @fa<local_name>, except in the case of a type-related
+representation item, whose @fa<local_name> shall denote a first subtype, and
+which directly specifies an aspect of the subtype's type. A representation item
+that names a subtype is either @i<subtype-specific> (Size and Alignment clauses)
+or @i<type-related> (all others). Subtype-specific aspects may differ for
+different subtypes of the same type.
+@dby
+A representation item @i<directly specifies> a @i<representation aspect> of
+the entity denoted by the @fa<local_name>, except in the case of a type-related
+representation item, whose @fa<local_name> shall denote a first subtype, and
+which directly specifies an aspect of the subtype's type. A representation item
+that names a subtype is either @i<subtype-specific> (Size, Object_Size, and
+Alignment clauses) or @i<type-related> (all others).
+
+!corrigendum 13.1(8.1/3)
+
+@dinsa
+An operational item @i<directly specifies> an @i<operational aspect> of the
+entity denoted by the @fa<local_name>, except in the case of a type-related
+operational item, whose @fa<local_name> shall denote a first subtype, and
+which directly specifies an aspect of the type of the subtype.
+@dinst
+Aspects that can be specified for types and 
+subtypes are also classified into type-related or subtype-specific aspects. 
+Representation aspects that can be specified for types and subtypes 
+are considered type-related unless specified otherwise. In contrast, 
+the classification of operational aspects are given with the 
+definition of the aspect. Type-related aspects have the same value for all 
+subtypes of (a view of) a type, while subtype-specific aspects may 
+differ for different subtypes of the same type.
+
+
 !corrigendum 13.1.1(17/3)
 
 @drepl
@@ -162,19 +346,44 @@
 cannot be specified on a @fa<renaming_declaration> or a
 @fa<generic_formal_parameter_declaration>.
 
+!corrigendum 13.14(7.2/3)
+
+@drepl
+@xbullet<At the freezing point of the entity associated with an
+@fa<aspect_specification>, any @fa<expression>s or @fa<name>s within the
+@fa<aspect_specification> cause freezing. Any static expressions within an
+@fa<aspect_specification> also cause freezing at the end of the immediately
+enclosing declaration list.>
+@dby
+@xbullet<At the freezing point of the entity associated with an
+@fa<aspect_specification>, any static expressions within the
+@fa<aspect_specification> cause freezing, as do @fa<expression>s or @fa<name>s in
+@fa<aspect_definition>s for representation aspects, or operational aspects
+that have a corresponding operational attribute. Similarly, if an
+@fa<aspect_definition> for an operational aspect, other than an
+assertion aspect, could affect the Name Resolution, Static Semantics, or 
+Legality Rules of a subsequent construct, then any @fa<expression>s or @fa<name>s 
+within the @fa<aspect_definition> cause freezing at the freezing point of the 
+associated entity. Any static expressions within an @fa<aspect_specification> 
+also cause freezing at the end of the immediately enclosing declaration list. 
+For the purposes of this rule, if there is no declared entity associated with 
+an @fa<aspect_specification>, the freezing point is considered to occur 
+immediately following the @fa<aspect_specification>.>
+
+
 !corrigendum A.5.6(0)
 
-@insc
+@dinsc
 See the conflict file for the changes.
 
 !corrigendum A.5.7(0)
 
-@insc
+@dinsc
 See the conflict file for the changes.
 
 !corrigendum H.7.1(0)
 
-@insc
+@dinsc
 See the conflict file for the changes.
 
 !corrigendum H.4.1(0)
@@ -437,7 +646,7 @@
 
 The reason that we had No_Controlled_Parts as operational was so that it
 could be visibly specified on a private type. The reason that we had 
-No_Contolled_Parts as nonoverridable was to deal with the conflicting 
+No_Controlled_Parts as nonoverridable was to deal with the conflicting 
 progenitor problem. (We don't care about breaking privacy for the aspect,
 since we're doing that in any case, but it would be too painful to
 define a separate set of rules just for this aspect.)
@@ -445,3 +654,224 @@
 As such, I've removed those changes from the proposal.
 
 ****************************************************************
+
+Part of a private review of AI12-0396-1.
+
+From: Randy Brukardt, November 25.
+
+The current wording for the freezing rules in AI12-0396-1 is:
+
+13.14(7.2/5):
+
+  At the freezing point of the entity associated with an
+  aspect_specification, any static expressions within the
+  aspect_specification cause freezing, as do expressions or names in
+  aspect_definitions for representation aspects, or operational aspects
+  that have a corresponding operational attribute. Any static
+  expressions within an aspect_specification also cause freezing at the
+  end of the immediately enclosing declaration list. 
+  
+13.14(15.2/5):
+
+  * At the place where a construct causes freezing, if the construct
+    includes a check associated with some assertion aspect [Redundant:
+    (independent of whether the check is enabled)], or depends on the
+    definition of some operational aspect as part of its Dynamic
+    Semantics, any names or expressions in the aspect_definition for the
+    aspect cause freezing.
+
+These rules collectively determine when an aspect_specification (and the
+included aspect_definitions) are frozen. But for operational aspects, we 
+seem to be missing some cases.
+
+Aside: I don't think any cases are missing for language-defined aspects. But 
+it seems to me that we don't want implementation-defined freezing rules (and I
+doubt any implementers want to be inventing such things). So I don't think we 
+want holes here.
+
+There are two cases that aren't covered. First of all, when we have constructs 
+that are not declarations (like loops) that allow aspect_specifications, the 
+first rule doesn't apply at all. Thus, the only aspects that have a rule in 
+loop contexts are those that are covered by the second rule [assertion aspects
+and operational aspects with Dynamic Semantics effects]. Even if we assume
+that there aren't any representation aspects for loops (not sure if that makes
+sense or not), that seems to leave a truck-sized hole for any (operational) 
+aspects that only have Static Semantic/Legality Effects -- and even if those 
+have Dynamic Semantics as well, they very well might be frozen too late for 
+Legality enforcement.
+
+Second, the aspect_definition for any operational aspects that don't require 
+static expressions and don't have Dynamic Semantics nor associated operational 
+items are never frozen anywhere. I note that a lot of types can't be static, 
+including System.Address and any composite type. Nor can objects or 
+subprograms be static. So it is relatively easy to imagine aspects that would
+not have any freezing rules at all. (Imagine an aspect that required a 
+compile-time address or a library-level object.) As noted previously, I don't
+think this is a good idea to leave these cases undefined.
+
+It's fairly clear that there should be a "else" here!
+
+The second problem is fairly easy to fix. We just need to ensure that the 
+rules in the two paragraphs are mirrors of each other. I'd suggest doing that
+by changing the first paragraph to be closer to the second:
+
+  At the freezing point of the entity associated with an
+  aspect_specification, any static expressions within the
+  aspect_specification cause freezing, as do expressions or names in
+  aspect_definitions for representation aspects, or operational aspects
+  that have a corresponding operational attribute {or are neither
+  assertion aspect nor have a Dynamic Semantics effect}. Any static
+  expressions within an aspect_specification also cause freezing at the
+  end of the immediately enclosing declaration list. 
+
+or maybe more positively (since it isn't a problem to freeze something twice):
+
+  At the freezing point of the entity associated with an
+  aspect_specification, any static expressions within the
+  aspect_specification cause freezing, as do expressions or names in
+  aspect_definitions for representation aspects, or operational aspects
+  that have a corresponding operational attribute {or have an
+  effect on the legality of some other construct and are not an assertion
+  aspect}. Any static expressions within an aspect_specification also
+  cause freezing at the end of the immediately enclosing declaration
+  list. 
+
+The first problem appears to need an additional rule (put it after 13.14(8.2/1)):
+
+  For an aspect_specification that appears in a construct that is not
+  the declaration of an entity, any static expressions within the
+  aspect_specification cause freezing, as do expressions or names in
+  aspect_definitions for aspects that have an effect on the legality
+  of some construct (including the construct with the
+  aspect_specification) and are not an assertion aspect. 
+
+  AARM To Be Honest: This rule applies to aspect_specifications in
+  loop_statements. A loop may contain contains a declaration of a
+  loop parameter, but that is a separate syntactic construct from
+  the one that contains the aspect_specification. A similar analysis
+  applies to other kinds of iterator.
+
+Thoughts??
+
+From: Tucker Taft, November 26, 2020.
+
+...
+>  At the freezing point of the entity associated with an  
+> aspect_specification, any static expressions within the  
+> aspect_specification cause freezing, as do expressions or names in  
+> aspect_definitions for representation aspects, or operational aspects  
+> that have a corresponding operational attribute {or have an effect on 
+> the legality of some other construct and are not an assertion  
+> aspect}. Any static expressions within an aspect_specification also  
+> cause freezing at the end of the immediately enclosing declaration  
+> list.
+
+That first sentence seems to be getting a bit complex.  Perhaps we can break
+it up a bit:
+
+ At the freezing point of the entity associated with an aspect_specification, 
+ any static expressions within the aspect_specification cause freezing, as do
+ expressions or names in aspect_definitions for representation aspects, or 
+ operational aspects that have a corresponding operational attribute.
+ {Similarly, if an aspect_definition for an operational attribute, other than 
+ an assertion aspect, could affect the Name Resolution, Static Semantics, or 
+ Legality Rules of a subsequent construct, then any expressions or names 
+ within the  aspect_definition cause freezing at the freezing point of the 
+ associated entity.} Any static expressions within an aspect_specification
+ also cause freezing at the end of the immediately enclosing declaration list. 
+
+> The first problem appears to need an additional rule (put it after
+> 13.14(8.2/1)):
+> 
+>  For an aspect_specification that appears in a construct that is not  
+> the declaration of an entity, any static expressions within the  
+> aspect_specification cause freezing, as do expressions or names in  
+> aspect_definitions for aspects that have an effect on the legality  of 
+> some construct (including the construct with the
+>  aspect_specification) and are not an assertion aspect. 
+> 
+>  AARM To Be Honest: This rule applies to aspect_specifications in  
+> loop_statements. A loop may contain contains a declaration of a  loop 
+> parameter, but that is a separate syntactic construct from  the one 
+> that contains the aspect_specification. A similar analysis  applies to 
+> other kinds of iterator.
+
+This seems a bit excessive for this one special case.  How about we just add
+this to the end of 13.14(7.2):
+
+  For the purposes of this rule, if there is no declared entity associated 
+  with an aspect_specification, the freezing point is considered to occur 
+  immediately following the aspect_specification.
+
+****************************************************************
+
+Part of a private review of AI12-0396-1.
+
+From: Randy Brukardt, November 25.
+
+13.1(8/3) is now:
+ 
+A representation item directly specifies a representation aspect of 
+the entity denoted by the local_name, except in the case of a 
+type-related representation item, whose local_name shall denote a 
+first subtype, and which directly specifies an aspect of the subtype's 
+type. A representation item that names a subtype is either 
+subtype-specific (Size, Object_Size, and Alignment clauses) or type-related 
+(all others). [Redundant: Subtype-specific aspects may differ for different 
+subtypes of the same type.]
+
+This is mostly unchanged from Ada 2012. But we have a To Be Honest 
+note following it:
+
+To be honest: Type-related and subtype-specific are defined likewise 
+for the corresponding aspects of representation.
+
+This means that we have no normative definition for "type-related 
+representation aspect", and in particular, we have no definition at 
+all (even in the AARM) for an aspect that doesn't have any representation items.
+To "fix" this latter problem, I added some text to the note above:
+
+To be honest: Type-related and subtype-specific are defined likewise 
+for the corresponding aspects of representation. {The terms are also 
+defined for aspects of representation that do not have corresponding 
+representation items; these also are type-related unless explicitly 
+specified otherwise.}
+ 
+I also added a similar note after the following paragraph about 
+operational aspects.
+
+To Be Honest: Type-related and subtype-related are defined likewise 
+for the corresponding operational aspects, and are defined as well for 
+operational aspects that apply to types but do not have corresponding 
+operational items. Unlike representation aspects, we explicitly define
+operational aspects to be type-related (that is the default for 
+representation aspects).
+
+However, I think this is very much a bridge too far. I think it would 
+be a lot better to add an appropriate overall definition after 13.1(8.1/3).
+Perhaps something like:
+
+  Aspects that can be specified for types and subtypes are also 
+  classified into type-related or subtype-specific aspects. 
+  Representation aspects that can be specified for types and subtypes 
+  are considered type-related unless specified otherwise. In contrast, 
+  the classification of operational aspects are given with the 
+  definition of the aspect.
+
+    AARM Discussion: We talk about "type-related aspects", which of 
+    course include both type-related representation aspects and 
+    type-related operational aspects. Aspects Size, Object_Size, and
+    Alignment are subtype-specific, as that is specified above. All 
+    other representation aspects are either type-related or not 
+    specifiable for a type or subtype. Unlike representation 
+    aspects, there is no default for operational aspects; whether they 
+    are type-related or subtype-specific should be part of the definition 
+    of the aspect.
+
+If we added this, we could get rid of both of those "To Be Honest" notes.
+(Perhaps the AARM note could be tightened up - it's not my best work!)
+
+From: Tucker Taft, November 26
+
+The above seems like a good change.
+

Questions? Ask the ACAA Technical Agent