CVS difference for ai05s/ai05-0115-1.txt
--- ai05s/ai05-0115-1.txt 2009/06/02 22:42:07 1.4
+++ ai05s/ai05-0115-1.txt 2010/10/26 00:49:13 1.5
@@ -1,5 +1,4 @@
-!standard 4.3.1(13) 09-06-02 AI05-0115-1/04
-!standard 4.3.1(14)
+!standard 4.3.1(14) 10-10-25 AI05-0115-1/05
!standard 4.3.2(5/2)
!class binding interpretation 08-10-15
!status work item 08-10-15
@@ -99,83 +98,30 @@
!wording
-Add after 4.3.1(13):
+Add a sentence to the end of 4.3.1(14):
- Static Semantics
+ If the type of a record_aggregate is a record extension, then it shall be
+ a descendant of a record type, through one or more record extensions (and
+ no private extensions). {Furthermore, the type of the record_aggregate shall
+ not have an ancestor record extension that is derived from a partial view
+ at the point of the record extension, unless the record_aggregate occurs
+ within the immediate scope of the record extension, as well as within the
+ scope of the partial view's full type.}
- A view of a specific tagged type T is said to "have known components"
- if it is not a partial view, nor a descendant of a type which
- does not have known components. Given a specific tagged type T
- having an ancestor type A, a view of T is said to "extend A with known
- components" if T is A, or if T is a record extension of A, or if
- T is a record extension of type B, and B extends A with known components.
-
-[Editor's note: See the last mail from Randy. This wording doesn't capture
-the locality very well, in that it is the view WRT to the type derivation
-that matters. Should we work this hard to preserve an annoying Ada feature??
-See also AI05-0125-1.]
+Modify 4.3.2(5/2):
- AARM Note:
- Having known components and extending an ancestor type A with known
- components are characteristics of the type T (see 7.3 and 7.3.1). That
- means that these properties can be added as more information becomes
- available about an ancestor type, and thus whether or not a type
- has known components depends on its view.
-
- Consider the following example:
-
- package Pkg1 is
- type T1 is tagged private
- -- T1 does not have known components here.
- private
- type T1 is tagged null record;
- -- T1 has known components here.
- end Pkg1;
-
- package Pkg1.Pkg2 is
- type T2 is new Pkg1.T1 with null record;
- -- T2 does not have known components here because
- -- T1 does not have known components (as seen from
- -- here).
- private
- -- T2 has known components here.
- end Pkg2;
-
- with Pkg1.Pkg2;
- package body Pkg1 is
- type T3 is new Pkg2.T2 with null record;
- -- T3 does not have known components here because T2
- -- does not have known components (as seen from here)
- -- even though T1 does (as seen from here).
- end Pkg1;
-
-
-Replace 4.3.1(14):
-
- The type of a record aggregate shall have known components.
-
-Replace 4.3.2(5/2):
-
If the ancestor_part is a subtype_mark, it shall denote a specific tagged
- subtype, and it shall not denote a type with unknown discriminants.
+ subtype{, and it shall not denote a type with unknown discriminants}.
If the ancestor_part is an expression, it shall not be dynamically tagged.
- The type of the extension_aggregate shall be derived from the type
- of the ancestor_part. The type of the extension aggregate shall
- extend the type of the ancestor_part with known components.
+ The type of the extension_aggregate shall be derived from the type of the
+ ancestor_part, through one or more record extensions (and no private
+ extensions). {Furthermore, apart from the immediate descendant of the type
+ of the ancestor part, none of those record_extensions shall derive from
+ a partial view in their declaration, unless the extension_aggregate occurs
+ within the immediate scope of the record extension, as well as within the
+ scope of the full type of the record extension's parent type.}
-Modify 7.3(15):.
-In the sentence
- Moreover, within the scope of the declaration of the full view, the
- characteristics of the type are determined by the full view; in particular,
- within its scope, the full view determines the classes that include the
- type, which components, entries, and protected subprograms are visible,
- what attributes and other predefined operations are allowed, [and ]whether
- the first subtype is static{, whether the type has known components,
- and (for any ancestor type A of the given type) whether the type
- extends A with known components}.
-
-
!discussion
Logically, an aggregate is a shorthand for setting each component individually.
@@ -183,19 +129,48 @@
then the same rule ought to apply to the equivalent aggregate. Thus all of the
example aggregates are illegal.
+Note that a similar case can be constructed for extension aggregates: Make
+type T1 in the example derived from a root type, then consider aggregates like:
+
+ R := (Root with C1 => 1, C2 => 2, C3 => 3); -- (Illegal.)
+ R := (Root with C2 => 2, C3 => 3, others => 1); -- (Illegal.)
+ R := (Root with others => 4); -- (Illegal.)
+
+\\\\\
We tried a number of different wording attempts, but it became clear that any
attempt to create wording that didn't leverage the existing characteristics
rules was doomed to failure. Thus we defined some new characteristics that
make it clear whether an aggregate is legal.
+\\\\\
-Note that a similar case can be constructed for extension aggregates: Make type T1
-in the example derived from a root type, then aggregates like:
- R := (Root with C1 => 1, C2 => 2, C3 => 3); -- (Illegal.)
- R := (Root with C2 => 2, C3 => 3, others => 1); -- (Illegal.)
- R := (Root with others => 4); -- (Illegal.)
+We tried a number of different wording attempts, none of which were entirely
+satisfactory. Conceptually, all we really want to do is to add a rule that
+makes record (and extension) aggregates illegal if the type of the aggregate
+has any "hidden" components. However, we have no way of talking about hidden
+components. In general, such components may never even be inherited, even
+though they exist behind the scenes, and changing the rules for component
+inheritance would be too large a change to address this specific problem.
+
+An attempt was made to define a new characteristic of type views that indicates
+when a view of a type has "known components". However, it seems heavy to have
+to introduce a new characteristic and technical term to address this narrow
+problem. There were also reservations expressed about that the proposed wording
+did not capture locality very well (see !discussion of the previous version
+of this AI (AI05-0115-1/04)). In this version of the AI, an attempt is made
+to specify an additional criterion for the legality of the aggregate on top
+of the existing rule about deriving through record extensions and not private
+extensions. The additional wording attempts to impose the condition of
+prohibiting aggregates when there is an ancestor record extension that derives
+from a partial view in that ancestor's declaration when the aggregate does
+not occur at a point where it would not be within the immediate scope of
+both the record extension and full type of the record extension's parent.
+[Note: It remains for further ARG discussion to determine whether these
+revised rules adequately express the desired condition. If not, it may be
+necessary consider revisiting the approach based on adding the
+"known components" characteristic.]
An alternative way to solve this problem would be to allow the components to be
-visible in cases like those given in the question. Essetially, characteristics
+visible in cases like those given in the question. Essentially, characteristics
could be inherited from any ancestor, not just the parent. In that case, no
legality rule change would be needed here. But conflicting components would have
to be illegal when a type is declared, so there is some incompatibility. And
@@ -284,8 +259,6 @@
Note that X5 through X8 are not illegal by the Ada 2005 rules.
---!corrigendum 4.3.1(13)
-
!corrigendum 4.3.1(14)
@drepl
@@ -293,26 +266,36 @@
descendant of a record type, through one or more record extensions (and no
private extensions).
@dby
-The type of a record aggregate shall have known components.
+If the type of a @fa<record_aggregate> is a record extension, then it shall be a
+descendant of a record type, through one or more record extensions (and no
+private extensions). Furthermore, the type of the @fa<record_aggregate> shall
+not have an ancestor record extension that is derived from a partial view at the
+point of the record extension, unless the @fa<record_aggregate> occurs within
+the immediate scope of the record extension, as well as within the scope of the
+partial view's full type.
+
!corrigendum 4.3.2(5/2)
@drepl
If the @fa<ancestor_part> is a @fa<subtype_mark>, it shall denote a specific
-tagged subtype, and it shall not denote a type with unknown discriminants.
+tagged subtype.
If the @fa<ancestor_part> is an @fa<expression>, it shall
not be dynamically tagged. The type of the @fa<extension_aggregate> shall
be derived from the type of the @fa<ancestor_part>, through one or more
record extensions (and no private extensions).
@dby
If the @fa<ancestor_part> is a @fa<subtype_mark>, it shall denote a specific
-tagged subtype. If the @fa<ancestor_part> is an @fa<expression>, it shall
-not be dynamically tagged. The type of the @fa<extension_aggregate>
-shall be derived from the type of the @fa<ancestor_part>. The type of the
-extension aggregate shall extend the type of the @fa<ancestor_part>
-with known components.
-
---!corrigendum 7.3(15)
+tagged subtype, and it shall not denote a type with unknown discriminants.
+If the @fa<ancestor_part> is an @fa<expression>, it shall
+not be dynamically tagged. The type of the @fa<extension_aggregate> shall
+be derived from the type of the @fa<ancestor_part>, through one or more
+record extensions (and no private extensions).
+Furthermore, apart from the immediate descendant of the type of the ancestor
+part, none of those @fa<record_extension>s shall derive from a partial view in
+their declaration, unless the @fa<extension_aggregate> occurs within the
+immediate scope of the record extension, as well as within the scope of the full
+type of the record extension's parent type.
!ACATS Test
@@ -1383,6 +1366,162 @@
subtype, and it shall not denote a type with unknown discriminants.
Or something to that effect.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, October 25, 2010 7:02 PM
+
+I was assigned this AI, probably partly as penance for not attending the last
+ARG meeting, and tasked with coming up with a "fresh approach" to the problem,
+which was discussed at excruciating length by Randy, Tucker, and Steve back in
+late 2008:
+
+> Gary gets AI05-0115-1. This is large part because Tucker, Steve, and I
+> spent a lot of time attempting to draft wording that solves the
+> problem (of aggregate components that aren't visible) and we never could get it right.
+> We need someone with a fresh approach to make an attempt at it (but
+> reading the old mail to see why we were having such trouble would be instructive).
+
+After wrestling with understanding the details of the earlier lengthy e-mail
+discussions (which are incomplete in certain respects, as Randy distilled the
+lengthy e-mail discussions and didn't include some cases of wording attempts),
+one thing that became clear to me is that this AI's definitely a toughie. I
+won't claim to have managed to have come up with a better approach, but I gave
+it my best shot, and have proposed tentative wording as described below under
+alternative 3.
+
+I've given a summary below of three main alternatives considered for addressing
+this AI. There actually were probably more than that considered during the 2008
+discussions, including various aborted attempts at wording for different
+alternatives. My proposed "fresh approach" proposal is given as the third
+alternative. I believe we'll have to make a decision between going with
+Alternative 2, which is the current approach described in the AI and the
+proposed Alternative 3. If it turns out that Alt. 3 is not viable, which is
+entirely possible, since most other attempts to solve this based on localized
+wording have turned out to have problems of one kind or another, then in the
+absence of any sudden brainstorm from others for a better way, I think we'll
+just have to go with Alt. 2, despite existing misgivings about it (Randy, at
+least, was apparently not happy with the wording).
+
+I've made a rough update to the AI to reflect the newly proposed wording, plus
+updated the !discussion section to briefly discuss some of the considered
+alternatives, and included it at the end of this message. I considered just
+adding the new wording alongside the older proposal (clearly marked), but Randy
+prefers an update for the new proposal, as older version can be retrieved easily
+enough from CVS for comparison purposes.
+
+(Side Note: I'm not proposing any changes to the wording proposed in the
+previous version that addresses the cases involving types with unknown
+discriminants, since that part seems to be handled fine by the proposed wording
+in the AI.)
+
+
+Alternative 1 (approach based on component visiblity)
+-------------
+
+Conceptually, all we really want to do is to add a rule that makes record (and
+extension) aggregates illegal if the type of the aggregate has any "hidden"
+components. I spent/wasted a moderate amount of time pursuing this line, though
+it was evidently also pursued in earlier discussions, so I should have known
+better (but unfortunately that part of the discussion didn't make it into the AI
+appendix, apart from a statement that using component visibility couldn't work).
+
+What I wanted to do was simply augment the current rule in section 4.3.1:
+
+ 14 If the type of a record_aggregate is a record extension, then it shall
+ be a descendant of a record type, through one or more record extensions (and
+ no private extensions).
+
+with an additional rule along the lines of:
+
+ A record_aggregate is illegal if the type of the aggregate inherits
+ components that are not visible.
+
+The idea here was that the existing paragraph would continue to cover "outside
+view" cases where the aggregate sees partial views of its ancestors, and the
+additional rule would serve as an additional filter to catch "inside view" cases
+such as those given as examples in the AI.
+
+However, this runs into the major difficulty that we have no way of talking
+about certain hidden components, because they don't get addressed at all by the
+current inheritance rules. In general, such components may never even be
+inherited, even though they exist behind the scenes. I think there's a potential
+to make an approach based on component visibility work, but it would require
+changing the definitions of inheritance and declaration for components in
+section 3.4, and for that reason alone I think that making such changes wouldn't
+be acceptable for solving this specific problem (though I tend to believe it
+could be done without affecting existing legality and semantics, but I could
+also be completely wrong about that...). So I somewhat reluctantly gave up on
+this line of thought.
+
+
+Alternative 2 (approach based on new "has known components" characteristic)
+-------------
+
+This is the approach adopted (apparently with some trepidation) in the current
+version of the AI, which defines a new type characteristic that indicates
+whether a type "has known components", and uses that in defining the legality of
+aggregates. In the AI, the editor (aka Randy) expresses reservations about
+whether the proposed wording "captures the locality very well". I'm not sure
+whether I fully see the problem, but it's certainly the case that this approach
+adds a fair bit of verbiage (though my proposal in Alt. 3. suffers from that as
+well). Personally, I dislike the idea of adding a new characteristic (and
+tehnical temr) of this kind, whose only purpose is to address this very narrow
+problem, but I can live with this approach if nothing else seems to work better.
+
+
+Alternative 3 (attempt to exclude problem cases based on type visibility)
+-------------
+
+The approach I've attempted is to augment the current 4.3.1 and 4.3.2 rules
+directly to outlaw the problematic aggregate cases, by managing to express the
+condition of an aggregate type having an ancestor type that derives from a
+partial view, when that ancestor might inherit components from its parent type's
+full view that are not visible at the point of the aggregate. (I say "might",
+because there's the case where the full view of the ancestor's parent is a null
+extension.) The proposed wording tries to do this by talking directly about the
+point of the ancestor type's declaration as well as the context where the
+aggregate appears vis-a-vis the scopes of the ancestor and parent type's full
+view. Intuitively, the idea is that when there are ancestors that derive from
+partial views, the aggregate will only be allowed if it occurs in a place where
+such an ancestor type would actually be able to inherit components (if any) of
+the corresponding full views.
+
+That condition would seem to capture the cases that slip through the rule of
+4.3.1(14/2), at least it seems to work properly on the kind of cases described
+in the AI, as far as I can tell. Whether that condition can be adequately
+expressed in proper RM-ese is another question, but following is what I came up
+with.
+
+Here's the proposed wording, to be added to the end of 4.3.1(14/2), that
+attempts to capture this condition:
+
+ Furthermore, the type of the record_aggregate shall not have an ancestor
+ record extension that is derived from a partial view at the point of the
+ record extension, unless the record_aggregate occurs within the immediate
+ scope of the record extension, as well as within the scope of the partial
+ view's full type.
+
+This is admittedly a mouthful, and there may well be some problems with this
+wording, and it can probably be simplified, but I wanted to make sure that I
+captured the salient details of the desired condition before trying to improve
+it. (I freely admit this is neither pretty nor fresh.;-)
+
+Note that the use of 'immediate scope' for the record extension and 'scope' for
+the partial view's full type is deliberate, and intended to capture the right
+visiblity context for the aggregate.
+
+(BTW, maybe it's sufficient to say "... that is derived from a partial view"
+without adding "at the point of the record extension", but for now I wanted to
+make clear that this is talking about that specific place in the program text.
+Perhaps there's a better way to phrase it, if it's legitimate to state this kind
+of condition at all.)
+
+Similarly, a rule such as the following needs to be added to 4.3.2(5/2), to
+cover extension aggregates:
+
+[Following was version /05 of the AI - Editor.]
****************************************************************
Questions? Ask the ACAA Technical Agent