CVS difference for ais/ai-00108.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00108.txt

--- ais/ai-00108.txt	2000/04/14 01:45:07	1.6
+++ ais/ai-00108.txt	2000/04/20 20:20:13	1.7
@@ -447,3 +447,277 @@
 Now, I'll don my fireproof suit. :-)
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Friday, April 14, 2000 5:56 AM
+
+> ...
+> After I wrote all of the above, I noticed that inheritance of limited 'Read,
+> etc. is moot. 13.13.2(36) says "An attribute_reference is illegal if the
+> type is limited, unless the attribute has been specified by an
+> attribute_definition_clause". Clearly, any "inherited" or even "predefined"
+> attribute for a derived limited has not been specified by an
+> attribute_definition_clause (which is a syntactic entity).
+
+Here you are wrong.  "Specified" is clearly defined to include
+inherited.  If you want to omit inherited aspects, you need to
+say "directly specified."  ("Look it up," as they say ;-).
+
+> ... Thus, while such
+> an attribute might exist, it is always illegal to call it. Certainly, the
+> proposed changes have no effect on that property.
+
+This does not follow, given your misinterpretation of "specified."
+
+> So, my conclusion is that the Corrigendum wording is correct for 'Read and
+> 'Write.
+
+I understand the need to use the notion of "calling" the parent
+operation for type extensions, because that is just one of the
+things being done, since the predefined 'Read include calls on
+the 'Reads of the components of the extension part.  Using the
+"call the parent" hack for untagged types seems bogus.  Here
+we should say the attribute is inherited.
+
+So I believe that operational attributes should be inherited for untagged.
+For tagged, when the predefined attribute is defined component-wise,
+the parent attribute is incorporated by treating the parent as a
+"component" of the type extension, along with the actual components of
+the extension part.
+
+Using the "hack" of "call the parent but don't inherit" for untagged
+makes no intuitive sense to me.
+
+> There does seem to be a problem for 'Input and 'Output for untagged derived
+> types: the current wording reverts them to their predefined implementation,
+> rather than inheriting them. That would be an gratuitous change, not
+> supported by AI-00108.
+
+Removing inheritance from untagged operational attributes is
+a gratuitous change as far as I am concerned.
+
+Even if you wish tagged and untagged were the same, the fact
+is that from the point of view of "aspects," they need to be
+treated separately.  (Look at the handling of "packed" as another example.)
+
+> I propose to repair this problem by adding the following in front of
+> 13.13.2(26) (and indenting (26-27) further):
+>
+> o If T is an untagged derived type, the Output or Input attribute
+>   of the parent type is called, if one exists.
+
+Yuck.  Just inherit untagged operational attributes.
+
+> o For other types:
+>
+>
+> I believe this takes care of the open problem with inheritance.
+
+I don't agree.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Friday, April 14, 2000 6:30 AM
+
+> Using the
+> "call the parent" hack for untagged types seems bogus.  Here
+> we should say the attribute is inherited.
+
+But that doesn't quite work because the (untagged) derived type may have
+different discriminants than its parent.
+
+I think that part of this discussion is covered by items 3 and 5 of AI 195,
+which in fact corrects some of AI 108:
+
+3 - For a derived type which is limited (tagged or not), the attributes Read
+and Write are inherited, and the attributes Input and Output revert to their
+predefined definition (i.e. they cannot be called).  (This amends AI95-
+00108.)
+
+5 - For an untagged derived type with new discriminants that have defaults,
+the predefined stream-oriented attributes read or write the new
+discriminants, not the old ones.  (This amends AI95-00108.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, April 14, 2000 7:01 AM
+
+> But that doesn't quite work because the (untagged) derived type may have
+> different discriminants than its parent.
+
+I think we discussed this, and concluded that a user-defined
+'Read or 'Write is inherited as is, but if there is no
+user-defined 'Read or 'Write, the predefined one behaves as
+described below.
+
+> I think that part of this discussion is covered by items 3 and 5 of AI 195, which in fact corrects some of AI 108:
+>
+> 3 - For a derived type which is limited (tagged or not), the attributes Read
+> and Write are inherited, and the attributes Input and Output revert to their
+> predefined definition (i.e. they cannot be called).  (This amends AI95-
+> 00108.)
+>
+> 5 - For an untagged derived type with new discriminants that have defaults,
+> the predefined stream-oriented attributes read or write the new
+> discriminants, not the old ones.  (This amends AI95-00108.)
+
+The above clearly indicates that saying that "operational attributes
+are never inherited" is misleading at best.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 14, 2000 3:54 PM
+
+Tucker said:
+
+> Here you are wrong.  "Specified" is clearly defined to include
+> inherited.  If you want to omit inherited aspects, you need to
+> say "directly specified."  ("Look it up," as they say ;-).
+
+I did (now). And the paragraphs in question 13.1(16-18) clearly don't apply
+to operational aspects. :-)
+
+I don't know if this was intentional on Pascal's part (I think so, but I'm
+guessing, none of my mail answers that).
+
+So that is another problem (one way or another) with this stuff.
+
+Tucker replied to me:
+
+> > So, my conclusion is that the Corrigendum wording is correct for 'Read and
+> > 'Write.
+>
+> I understand the need to use the notion of "calling" the parent
+> operation for type extensions, because that is just one of the
+> things being done, since the predefined 'Read include calls on
+> the 'Reads of the components of the extension part.  Using the
+> "call the parent" hack for untagged types seems bogus.  Here
+> we should say the attribute is inherited.
+>
+> ...
+
+> Using the "hack" of "call the parent but don't inherit" for untagged
+> makes no intuitive sense to me.
+
+It's pretty hard to argue with "seems bogus". You seem to prefer a rule of
+"it inherits, except when it doesn't", and I prefer to not call it
+inheritance.
+
+I guess I would like to see an actual suggestion of wording changes for
+13.1(15-18) and 13.13.2(9 and 25) that meet the needs of the AI and have the
+behavior that you want.
+
+Pascal said:
+
+>I think that part of this discussion is covered by items 3 and 5 of AI 195,
+>which in fact corrects some of AI 108:
+
+>3 - For a derived type which is limited (tagged or not), the attributes Read
+>and Write are inherited, and the attributes Input and Output revert to their
+>predefined definition (i.e. they cannot be called).  (This amends AI95-
+>00108.)
+
+>5 - For an untagged derived type with new discriminants that have defaults,
+>the predefined stream-oriented attributes read or write the new
+>discriminants, not the old ones.  (This amends AI95-00108.)
+
+Keep in mind that AI-00195 never was approved or finished. So it isn't clear
+just how much of it we ought to incorporate.
+
+I now believe (having thought about this some more) that 3 is wrong for
+'Read and 'Write for a type extension. That is, using the previous version
+is more likely to cause bugs and confusion than it is to work properly
+(because the extension components are not covered). Moreover, simply making
+a type limited could silently break code. (Breaking it with a compile-time
+error is at least helpful, as it points out the problem.) The situation is
+similar to that for a function, which we do not allow the use of the
+original.
+
+More from Tucker:
+
+> Even if you wish tagged and untagged were the same, the fact
+> is that from the point of view of "aspects," they need to be
+> treated separately.  (Look at the handling of "packed" as
+> another example.)
+
+That is irrelevant to the wording of 13.1. 13.1 only has a two places where
+"tagged" occurs: in 13.1(10) and 13.1(11). And it is those rules that
+triggered AI-00137 in the first place! If they hadn't had special cases for
+untagged types, we probably wouldn't be having this conversation (as
+special-case "patches" for AI-108 probably would have made more sense).
+
+I cannot see fixing one problem by unnecessarily introducing the *exact
+same* problem in the fix. We *will* trip over any such rules again.
+
+So I strongly believe that any rules ought to be specific to a particular
+attribute or set of attributes. (Certainly the non-normative wording of
+"does not inherit" in 13.1 could be dumped, but I'm not quite sure what to
+replace it by.)Now I can imagine defining the entire inheritance blather at
+the start of 13.13.2, but it seems awfully heavy to do so just to say what
+takes two sentences to do otherwise.
+
+Tucker replied to me:
+
+> > I believe this takes care of the open problem with inheritance.
+>
+> I don't agree.
+
+I now agree there are problems here, especially because of the cases noted
+from the unfinished AI-00195.
+
+I don't agree that we are likely to find a resolution without a meeting,
+however. Tucker's argument seems to be purely based on emotion ("seems
+bogus", "the hack of calling..."). Honestly, mine (while clearly superior
+:-) isn't much better, as it is based on potential future uses of the
+feature. To resolve this requires roundtable discussion and additional
+points of view. E-Mail seems to degrade into two people dominating the
+discussion, and rarely develops the consensus needed.
+
+How to proceed from here? I think we only have one practical choice left,
+but I'll let others decide that. The choices are (in no particular order):
+
+A: Leave it as it is.
+        -- Too many problems have been noted, that simply isn't practical.
+
+B: Put in half-baked changes discussed by e-mail.
+        -- Past experience with the corrigendum says that these get
+        -- heavily modified at the next meeting. Which means it is the same
+        -- as C.
+
+C: Fix it at the next meeting.
+        -- This would be OK, but as a practical matter means that we cannot
+        -- meet the schedule. (Substantive changes inserted at a meeting
+        -- should always be reconsidered afterwards, especially in the full
+        -- context of the RM. The problems we're discussing came up because I
+        -- did that with these changes.) To at least come close to the schedule,
+        -- we would have to have an "extra" meeting in September/October.
+
+D: Revert AIs 108 & 137 to the pre-operational attribute version.
+        -- This probably would work, but we would have to re-review the changes
+        -- from those versions, as I don't think that we ever did that. So,
+        -- more than likely, we end up with C again.
+
+E: Vote to remove AI-108 from the corrigendum.
+        -- This can be supported based on the need to complete the recommendation
+        -- (that is, the partial reversal of AI-00108 in AI-195 implies that
+        -- it needs a lot more work, and not all of this work was considered in
+        -- the current wording). After all, there seems to be more than just a
+        -- disagreement in wording here, especially if AI-195 is factored in.
+        -- However, doing this leaves the question of dealing with AI-137 in a
+        -- way that doesn't interfere with the eventual solution of AI-108/195.
+        -- E1 would be to revert it to the original pre-operational attribute form,
+        -- which was quite simple, with the thought that it would be changed again
+        -- "next time". But that probably ends up the same as D. E2 would be to
+        -- "fix" it to be compatible, meaning that we still would have to come up
+        -- with wording for 13.1(15-18) -- which is where we started.
+
+F: Vote to remove both AI-108 and AI-137 from the corrigendum.
+        -- This would be supported by the reasons given above for AI-108, and
+        -- an interaction argument for AI-137. This seems to be the only solution
+        -- that would keep us on schedule. But it is pretty severe, as we're
+        -- delaying answering these questions for more time.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent