CVS difference for ai05s/ai05-0099-1.txt
--- ai05s/ai05-0099-1.txt 2008/05/29 04:36:46 1.2
+++ ai05s/ai05-0099-1.txt 2008/08/08 02:14:30 1.3
@@ -1,5 +1,7 @@
-!standard 7.6.1(7) 08-05-28 AI05-0099-1/01
+!standard 7.6.1(6) 08-08-06 AI05-0099-1/02
+!standard 7.6.1(7)
!standard 7.6.1(8)
+!standard 7.6.1(9)
!class binding interpretation 08-05-28
!status work item 08-05-28
!status received 06-04-09
@@ -31,22 +33,32 @@
!wording
+Modify 7.6.1(6):
+
+* If {the full type of} the object is [of] an elementary type, finalization
+ has no effect;
+
Replace 7.6.1(7) by:
-* If the object is of a tagged type, and the tag of the object identifies
- a controlled type, the Finalize procedure of that controlled type is
- called.
+* If the full type of the object is a tagged type, and the tag of the object
+ identifies a controlled type, the Finalize procedure of that controlled type
+ is called;
-Replace 7.6.1(8) by:
+Modify 7.6.1(8):
-* If the object is of a protected type, or if the object is of a tagged
- type and the tag of the object identifies a protected type, the
- the actions defined in 9.4 are performed;
+* If {the full type of} the object is [of] a protected type, {or if the
+ full type of the object is of tagged type and the tag of the object
+ identifies a protected type, }the actions defined in 9.4 are performed;
+
+Modify the start of 7.6.1(9):
+
+* If {the full type of} the object is [of] a composite type, then after
+ performing the above actions...
Add an AARM note after 7.6.1(9.a):
To Be Honest: The components discussed here are all of the components that
-the actual object has, not just those component that are identified by the
+the actual object has, not just those components that are identified by the
type of of the actual object. These can be different if the object has a
classwide type.
@@ -54,16 +66,32 @@
The rule in question is a dynamic semantics rule, so depending on a static
concept like "nominal subtype" is suspicious. However, there is no clear
-definition of the "dynamic type" of an object. Since T'Class can include an
-object of any decendant of T, we surely do not want to be calling the Finalize
-(if any) that is statically associated with T.
-
-Argubly, this problem could occur in other dynamic cases, but in the absense
-of any examples of such cases, it is not possible to craft a general solution.
-
-In any case, the existing wording is either vague or misleading, as it doesn't
-make it clear which Finalize routine is called. That needs to be corrected in
-any case.
+definition of the "dynamic type" of an object in the Standard. Since
+T'Class can include an object of any decendant of T, we surely do not
+want to be calling the Finalize (if any) that is statically associated
+with T.
+
+In similar cases in the Standard, we have wording specifically to handle class-wide
+cases. For instance, membership operations specifically mention testing the
+tag (4.5.2(30.1/2)). Type conversions also mention testing the tag (4.6(42)).
+
+There doesn't seem to be other places where this problem occurs, so it doesn't
+seem necessary to define a new term like "dynamic type"; we can just fix this
+occurrence. This wording was OK (although vague) for Ada 95, as any
+class-wide type that could have controlled specific types would necessarily
+be controlled. But that is not true in Ada 2005 because of interfaces.
+
+The original wording is vague as to which type's Finalize is called, especially
+for class-wide types. We might as well eliminate this vagueness as well.
+This is why we do not try to follow the lead of other similar wording and
+talk only about class-wide types - we need to say which type's Finalize is
+called in every case. The new wording makes it crystal clear which Finalize
+routine is called (the one belonging to the specific type identified by the
+tag of the object - it never has anything to do with the nominal subtype).
+
+Finally, the new wording also eliminates any confusion about whether privacy
+has any bearing on finalization (it does not). We add the "full type" wording
+to all of the bullets here to be consistent.
7.6.1(8) has a similar problem for a (tagged) protected type that inherits from
a limited or synchronized interface. Thus we reword it as well.
@@ -210,3 +238,243 @@
****************************************************************
+From: Randy Brukardt
+Sent: Friday, July 11, 2008 6:18 PM
+
+The (draft) minutes from the recent meeting say for AI05-0099-1:
+
+Tucker wonders about privacy, this wording doesn't cover that. An untagged
+private type can be completed with a tagged type. Randy tries to point out
+that dynamic semantics ignore privacy. But then Tucker says that there is
+nothing wrong with the original wording.
+
+So most feel that a Ramification is more appropriate. Rewrite the AI as
+a ramification with just a To Be Honest AARM note.
+
+Approve intent of AI: 7-0-1.
+
+---
+
+There are only two problems with this resolution: (1) It's not responsive
+to the question in the AI; (2) It's inconsistent with the way that the rest
+of the language handles similar cases.
+
+Let me explain. Adam's original question was about an object whose nominal
+subtype is a class-wide interface type, and whose object (created by some
+constructor function) has a tag identifying a controlled type that implements
+that interface. That class-wide type is surely not a controlled type, yet we
+hope (expect?) that the object gets finalized.
+
+The discussion about privacy mentioned in the minutes is correct as far as
+it goes; Tucker is surely correct that there is nothing wrong with the
+original wording vis-a-vis privacy. But that is irrelevant to answering the
+question, which was how the type is determined for a class-wide type.
+
+One could try to argue that using the specific type in such a case is
+how the language works. But in that case, it would be necessary to provide
+some proof - some existing wording to that effect.
+
+Which brings us to the second point. In an attempt to figure out the proof,
+I looked at some similar cases in the language:
+
+Membership operations - 4.5.2(30.1/2) says:
+
+ if the type of the simple_expression is class-wide, the value has a tag
+ that identifies a type covered by the tested type;
+
+Type conversions - 4.6(42) says:
+
+ The tag of the result is that of the operand. If the operand type is
+ class-wide, a check is made that the tag of the operand identifies a
+ (specific) type that is covered by or descended from the target type.
+
+Both of these wordings are quite clear that for class-wide types, we forget
+the type and do the operation based on the tag of the object. And note that
+in both cases, they specifically mention this case. They don't depend on some
+magical meaning of type defined elsewhere.
+
+Now, it's true that the original wording of 7.6.1(7) and 7.6.1(8) worked fine
+for Ada 95. Since all controlled types are descended from a single root type,
+any class-wide type that covers a controlled type must also be a controlled type.
+And protected types can't ever be tagged. So the only issue is privacy, and for
+that we can ignore it as this is dynamic semantics.
+
+However, once we add interface types to this mix, none of that is true. A
+synchronized interface class-wide type could have an object that is either a
+protected object or a task, and the interface is considered to be neither.
+Similarly, an interface class-wide type can have an object that is controlled,
+or one that is not, but surely the interface is not controlled (it is not
+descended from one of the root controlled types).
+
+The wording I proposed attempted to handle this problem with a minimum of
+wording. But I'm not wedded to that wording -- but I'm certain we do need
+wording to handle at least class-wide case. If we can make the privacy
+explicit, so much the better.
+
+One heavier way to do this would be to define the dynamic type of an object:
+
+The *dynamic type* of an object is:
+ * If the full type of the nominal subtype of the object is tagged, the
+ dynamic type is the type identified by the tag of the object;
+ * Otherwise, the dynamic type is the full type of the object.
+
+[I covered all tagged types in the first bullet so that this term would work
+in the future on formal parameters, for which the nominal subtype and the
+*real* type can differ even for static types. If we're going to define a term,
+it seems likely that it will get reused. But that's not necessary for this use,
+so it could just cover the class-wide case.]
+
+Then rewrite the bullets 7.6.1(6-9) to say "If the dynamic type of the object
+is <something>", rather than "If the object is of a <something> type".
+
+Another alternative would be to leave the existing text alone, but to add
+another bullet to specifically call out the class-wide case:
+
+* If the object is of a class-wide type, the finalization action appropriate
+ for the type identified by the tag of the object is performed;
+
+I find this a bit funky, because it overlaps the other cases, and is recursive,
+into a set of bullets that is already somewhat ordered.
+
+Finally, here is my original attempt at revising 7.6.1(7-8):
+
+* If the object is of a tagged type, and the tag of the object identifies
+ a controlled type, the Finalize procedure of that controlled type is
+ called.
+
+* If the object is of a protected type, or if the object is of a tagged
+ type and the tag of the object identifies a protected type, the
+ the actions defined in 9.4 are performed;
+
+One could address the privacy issue with something like:
+
+* If the full type of the object is a tagged type, and the tag of the object identifies
+ a controlled type, the Finalize procedure of that controlled type is called.
+
+although that's not strictly necessary, given that the implicit "view of"
+does not apply to dynamic semantics.
+
+Any of these would work, and probably there are variations that would work as well.
+
+---
+
+Anyway, if the group still wants a Ramification only, we'll need to find another
+author (in the absence of someone finding existing wording that covers this),
+because I have no interest in writing an AI that I would have to vote against
+in the next meeting.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, July 13, 2008 9:17 PM
+
+I wonder if we could generalize the definition of "part" to cover this case?
+That is, when we say if a "part" of an object is controlled/protected, that
+includes the case where it is of a class-wide type for an interface and the
+tag identifies a controlled/protected type.
+
+I guess my main concern is that I would like something that works in general,
+rather than this being another thing we have to keep worrying about every
+time we write a dynamic-semantics rule.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, July 29, 2008 6:17 PM
+
+Revisiting this issue so I can proceed with it in some way.
+
+Tucker [1] replied on July 13th:
+
+> I wonder if we could generalize the definition of "part" to cover this
+> case? That is, when we say if a "part" of an object is
+> controlled/protected, that includes the case where it is of a
+> class-wide type for an interface and the tag identifies a
+> controlled/protected type.
+>
+> I guess my main concern is that I would like something that works in
+> general, rather than this being another thing we have to keep worrying
+> about every time we write a dynamic-semantics rule.
+
+Tucker [2] wrote yesterday:
+
+> By the way, why don't we officially adopt the term the "specific type
+> of an object" as a solution to the problem we were wrestling with a
+> few weeks ago about the meaning of "type" of an object in dynamic
+> semantics, when its declared type is class-wide? That is, "specific
+> type of an object" is the type determined by its tag, while the
+> "declared type of an object" is the type determined by its
+> declaration. We should use one or the other in dynamic semantic
+> rules. We shouldn't just say "type" except in static semantics and
+> legality rules. And even in static semantics, we might talk about the
+> "specific type of an object" created by an allocator.
+
+Humm. I'm having a hard time reconciling Tucker [1] and Tucker [2],
+particularly without any input from the rest of the ARG.
+
+Tucker [1]'s suggestion of changing "part" seems very risky, given the
+number of rules that use part as a technical term. But I surely sympathize
+with his concern about having a continual concern in dynamic semantics rules.
+
+OTOH, Tucker [2] seems to be saying "let's start over and rewrite *all* of
+the dynamic semantic rules that talk about type"! Besides not really helping
+with the continual concern with new rules (we'd always have to remember to
+not use "type"), that seems to be too much of a change for too little reason.
+
+My research into this problem shows that the language does in fact have
+wording to avoid depending on the type of class-wide objects in the
+dynamic semantics rules that I checked. 7.6.1 didn't need such a rule in
+Ada 95 (because any class-wide type would necessarily be controlled if
+the specific types could be controlled). So I think the real problem is
+actually limited to Adam's question (7.6.1(7) and 7.6.1(8) do not work as
+written for class-wide interface types). Making changes beyond that doesn't
+seem to be justified given the known scope of the problem. If we later find
+more instances of the problem, we should worry about generalizing it then.
+
+So, at this point, I still think the minimum change is the best idea. Given
+that that was rejected (more or less) in Venice, I'm not sure how to proceed.
+I don't want to bring back essentially the same proposal with a minor tweak
+unless there is more agreement that it is the right course. (I don't want to
+act like I'm above the process here; I just don't want to waste time writing
+an AI that is not responsive to the question that was asked.)
+
+Here's the wording I'm proposing now (adding only "full type" to the wording
+so that the ignoring of views is crystal clear, although no one thought that
+necessary for Ada 95) to replace 7.6.1(7-8):
+
+* If the full type of the object is of a tagged type, and the tag of the object
+ identifies a controlled type, the Finalize procedure of that controlled type
+ is called;
+
+* If the full type of the object is of a protected type, or if the full type of
+ the object is of a tagged type and the tag of the object identifies a protected
+ type, the actions defined in 9.4 are performed;
+
+This isn't very similar to the wording used elsewhere for class-wide cases, but
+the only way to make it similar would be to add a bullet like:
+
+* If the full type of the object is of a class-wide type, the finalization action
+ appropriate for the type identified by the tag of the object is performed;
+
+after 7.6.1(8) [leaving 7.6.1(7-8) alone except for the full type stuff]. I find
+that rather squirrelly, as this bullet would overlap 7.6.1(7) [as a class-wide type
+can be a controlled type]. We could say "interface class-wide type" in order to
+avoid that, but then the rule looks more like a wart than something intended
+[and it is not a wart, it is intended]. And in any case it is a bit
+weird: "action appropriate for the type identified by the tag?"
+
+Thoughts?
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Wednesday, July 30, 2008 8:06 AM
+
+> So, at this point, I still think the minimum change is the best idea.
+
+Here's what I think: During "language design", one should try hard to get
+everything exactly right. During "language maintenance", one should stay closer
+to the "if it ain't broke, don't fix it" idea. This is language maintenance,
+so we should just fix the specific problem, as your proposed wording does.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent