CVS difference for ai12s/ai12-0005-1.txt
--- ai12s/ai12-0005-1.txt 2021/02/13 06:01:58 1.46
+++ ai12s/ai12-0005-1.txt 2021/05/24 22:55:22 1.47
@@ -3046,7 +3046,312 @@
***************************************************************
-Editor's note (February 8, 2021): All of the items above this
+[A summary of the conclusion of a private discussion - Editor.]
+
+We used static rules on SAOAATs (stand-alone objects of an anonymous access
+type) to prevent putting a more nested object into one (which does cause
+issues). In particular, we have in 3.10.2(13.3/4):
+
+ The accessibility level of the type of a stand-alone object of an anonymous
+ access-to-object type is the same as the accessibility level of the type of
+ the access value most recently assigned to the object[; accessibility
+ checks ensure that this is never deeper than that of the declaration of
+ the stand-alone object].
+
+...but there is no justification given for the "redundant" part (in square
+brackets). There should be an AARM note explaining this. The "normal case"
+says that there is no static check by by 3.10.2(19/5) & 3.10.2(19.2/5) (or
+the rule that was there before this version).
+
+(After much discussion) The entire rule of 4.6(24.17/4) says:
+
+ The accessibility level of the operand type shall not be statically deeper
+ than that of the target type, unless the target type is an anonymous access
+ type of a stand-alone object. If the target type is that of such a
+ stand-alone object, the accessibility level of the operand type shall not
+ be statically deeper than that of the declaration of the stand-alone object.
+
+Essentially, conversion to a SAOAAT's type uses a separate static check, and
+that is what is referred to in 3.10.2(13.3/4).
+
+As such, there should be a "The Proof" after 3.10.2(13.3/4) pointing at 4.6,
+something like "Conversions into the anonymous access type of a stand-alone
+object use a stricter (static) accessibility rule - see 4.6; these checks
+are those referred to above."
+
+Another issue: Is it clear that when the "statically deeper relationship does
+not apply" that any Legality Rules about that relationship are not enforced??
+The wording in 3.10.2 rather tip-toes around that by saying that it neither
+deeper nor shallower, but how that applies to Legality Rules (or other rules)
+is not specified. One could easily imagine that all of the rules fail in that
+case. There is an AARM note 3.10.2(19.a/3) that mentions dynamic checks, it
+probably should mention static checks as well. Perhaps:
+
+ In these cases, {no static accessibility checks are made, and} we use
+ dynamic accessibility checks{ to prevent problems}.
+
+***************************************************************
+
+From: Christoph Grein
+Sent: Wednesday, April 28, 2021 3:14 AM
+
+In subclauses C.6.1 and C.6.2, the referenced AI is wrong (AI05-0234-1).
+
+This should be AI12-0234-1.
+
+***************************************************************
+
+[From WG 9 review, issue 12.]
+
+10.2(18.c) mentions RM95; this is a generic reference and should just say "RM".
+
+***************************************************************
+
+[From WG 9 review, issue 21.]
+
+11.4.1 (15.b/2) "Ramification: This routines are used to define the stream
+attributes (see 13.13.2) for Exception_Occurrence."
+
+"This routines" should be "These routines".
+
+***************************************************************
+
+[From WG 9 review, issue 108.]
+
+13.3 (38.l) Typo: "The nonnegative part is missing from RM83 (for mod_clauses,
+[n]{s}ee alignment_clauses, which are an obsolete version of Alignment
+clauses)."
+
+[Editor's reply:
+
+I think "nee" here was used in the sense of "AKA", not a misspelling of "see".
+It would be better to avoid any of these and spell this out (of course, no
+one has complained for 25+ years and many reviews, but still). Thus I used:
+
+... (for mod_clauses, [nee]{known in Ada 83 as} alignment_clauses, which ...]
+
+***************************************************************
+
+From a private discussion about Put_Image:
+
+>>>>The RM says:
+>>>> The image written out for a record having no components (including any
+>>>> interface type) is "(NULL RECORD)".
+>>>>
+>>>>So the default implementation for an interface type is not a null procedure
+>>>>(which would write out nothing at all).
+
+>>>That is pretty awkward, since the user isn't allowed to "confirm" such an
+>>>aspect, unless the make the denoted subprogram something other than a
+>>>primitive. Not impossible, but a bit painful. Not impossible, but a bit
+>>>painful. I also notice that whatever an interface does is pretty much
+>>>irrelevant, except in the weird case when you explicitly convert to the
+>>>interface type, because of the following rule in 4.10(15/5):
+>>>
+>>>For a type extension, the default implementation of T'Put_Image depends on
+>>>whether there exists a noninterface ancestor of T (other than T itself) for
+>>>which the Put_Image aspect has been directly specified. If so, then
+>>>T'Put_Image will generate an image based on extension aggregate syntax where
+>>>the ancestor type of the extension aggregate is the nearest ancestor type
+>>>whose Put_Image aspect has been specified. If no such ancestor exists, then
+>>>the default implementation of T'Put_Image is the same as described below for
+>>>a nonderived record type.
+>>>
+>>>Interestingly, this rule doesn't properly handle the "confirming aspect
+>>>specification has no effect" since there is no way to "confirm" an
+>>>implicitly composed Put_Image for a tagged type without interfering with
+>>>the way the above rule works. We probably ought to have an AARM note
+>>>indicating we "know" that this violates our general rule. Basically, the
+>>> whole notion of "confirming" an implicitly composed aspect doesn't really
+>>>make sense.
+>>
+>>I don't think it makes sense to worry about "confirming" an implicitly
+>>constructed subprogram; it is by definition impossible to confirm such a
+>>thing, since anything you could specify is *not* by definition the implicit
+>>constructed subprogram (it's some explicit subprogram, the effect might be
+>>the same, but that not how "confirming" is defined and it would be a
+>>slippery slope to define in any useful way). There are plenty of aspects
+>>like that; for instance, you can't specify the default for Default_Value
+>>(which is that there isn't a default value - any specification is
+>>necessarily not that).
+>>
+>>It might make sense to add an AARM note after the definition of "confirming"
+>>that that is expected that it might not be possible to specify a confirming
+>>aspect, and give the Default_Value and stream attribute examples. Beyond
+>>that, I don't think it is worth obsessing over.
+>
+>I agree with your sense that "confirming" doesn't really make sense for some
+>aspects (though we went out of our way to provide something to represent
+>"Unspecified" for Global), including for all "implicitly composed" aspects.
+
+I've already handled the AARM note, adding after 13.1(18.2/5):
+
+Discussion: As noted at the beginning of this subclause, we have a language
+design principle that confirming aspects do not change the semantics. However,
+it is not a language design principle that one can always specify a confirming
+aspect. Some aspects can never be confirmed. For instance, the default
+implementation of a stream-oriented attribute cannot be confirmed, as any
+subprogram that can be specified is not the same as the default subprogram,
+and thus is nonconfirming. Whether the effect is the same is not relevant
+for this purpose; it would be very difficult to formally define what it means
+to have the same effect. (Note that one can name any implementation for a
+stream-oriented attribute by using the associated attribute but specifying
+that by name would violate the circular aspect definition rule.) This is true
+for any implicitly composed aspect. Similarly, aspect Default_Value cannot be
+confirmed as the default is that there is no default value; any value that can
+be specified is not that. Other aspects are similar.
+
+So a comment on that isn't needed. A comment on the other topics is still
+needed, of course.
+
+***************************************************************
+
+[From WG 9 review, issue 12.]
+
+13.11.5 (3.a)/5 says: We can't use the do notation {(see ??.??)} as that
+requires a statically denoted dispatching argument (we have a function call
+here).
+
+Not sure what is meant by "do notation". Could we please add a "(see x.x)"
+reference after "do" to point the reader to some place where this is defined?
+
+Editor's reply:
+
+The "do notation" was a forerunner of the Dispatching aspect; apparently, no
+one noticed this note when that other construct was changed. So I will change
+"do notation" to "Dispatching aspect (see H.7.1)". This will be recorded in
+AI12-0005-1.
+
+A minor additional quibble: the Dispatching aspect requires a statically NAMED
+object, not a statically DENOTED object. (That also was a late change.) And
+"object" is better here than "dispatching argument".
+
+***************************************************************
+
+[From WG 9 review, issue 102.]
+
+13.1(14.k/5) says "We need this rule even though static matching explicitly
+excludes confirming values of Object_Size. That's because a general access
+type can designate any aliased object whose subtype statically matches the
+[the] designated subtype. "
+
+Delete one of the two consecutive "the"s. Doesn't matter which one. ;)
+
+***************************************************************
+
+[From WG 9 review, issue 101.]
+
+13.1(14.i/5) says "The same issues apply to Alignment. Similar issues apply
+to Object_Size, Static_Predicate, and Dynamic_Predicate, but the chosen
+solution is different: explicit rules in 4.9.1 [to] ensure that the aspects
+are the same if specified."
+
+Delete "to".
+
+Editor's comment:
+
+It feels to me that we need some word there (or we would need to drop
+"ensure"). The "chosen solution" is "explicit rules in 4.9.1" and we then
+explain what the rules do. Perhaps "that" would be better than "to": "...
+explicit rules in 4.9.1 [to]{that} ensure that ...".
+
+I put this into AI12-0005-1 (as AI12-0059-1 is already WG 9 Approved and thus
+cannot be changed).
+
+***************************************************************
+
+[From WG 9 review, issue 146.]
+
+AARM 7.6(17.q/3): This "To be honest" refers to the "parent part" of an
+extension aggregate. The correct term is "ancestor part" (RM 4.3.2 (2)).
+
+Same comment applies to 7.6.1 (24.k/2).
+
+***************************************************************
+
+[From WG 9 review, issue 147.]
+
+AARM 7.6.1(18.c) says that "The goto statement will first cause Finalize(Y)
+to be called." However, RM 7.6.1 (11/3) says that objects are finalized in
+the reverse order of their creation, so Finalize(Z) should be called before
+Finalize(Y), because Z is declared (and created) after Y. The easiest fix
+is to reverse the order of the declarations of Y and Z in the example.
+Note that RM 7.6.1 (19.a) also refers to this example and to Z.
+
+[Tucker Taft replied:
+Another good catch! Reversing the declaration order of Y and Z is likely to
+lead to other confusion. I would suggest we systematically swap Y and Z
+references to be consistent with the finalization-is-in-reverse-order
+requirement.]
+
+***************************************************************
+
+[From WG 9 review, issue 136.]
+
+Typo in 4.4(9.a/5): "opertive".
+
+***************************************************************
+
+[From WG 9 review, issue 117.]
+
+John Barnes wrote:
+
+A.18(12.l/5) Containers "...behavior of the sorts when ... " might be better
+as "... behavior of sorting when..." Sorts to me relates to feeling out of
+sorts (too much gin) or confectionary (liquorice allsorts).
+
+Editor's reply:
+
+Being rather pendantic, we don't define anything called "sorting" (we do use
+the term informally a few times); what we do is define routines named Sort or
+<something>_Sort. They usually "reorder" elements so they are left "sorted".
+So "the sorts" is short for the "various Sort or <something>_Sort procedures".
+That's too long for this note, but maybe "the Sort procedures" is close
+enough?
+
+Put this into the AARM AI.
+
+***************************************************************
+
+[From WG 9 review, issue 98.]
+
+13.1(8.oo):
+ aspect Exclusi[on]{ve}_Functions
+
+Misnamed aspect
+
+Editor's reply:
+
+Additionally, many of these paragraphs (including this one) are misnumbered,
+they should be inserted (8.mm.xx) and have /5.
+
+***************************************************************
+
+[From WG 9 review, issue 172.]
+
+A typo (an extra 'a' in "streaam") occurs in both 13.13.1 and A.12.1 (in
+the AARM)
+
+In 13.13.1(37.a/5) and A.12.1(36.h/5).
+
+***************************************************************
+
+[From WG 9 review, issue 39.]
+
+12.5(10.a) imprecise wording, "floating point" is not an ancestor of a type
+
+ Ramification: The term “formal floating point type” refers to a type defined
+ by a formal_floating_point_definition. It does not include a formal derived
+ type whose ancestor is {a} floating point {type}.
+
+***************************************************************
+
+***************************************************************
+***************************************************************
+
+***************************************************************
+
+Editor's note (May 22, 2021): All of the items above this
marker have been included in the working version of the AARM.
****************************************************************
Questions? Ask the ACAA Technical Agent