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

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

--- ai12s/ai12-0435-1.txt	2021/05/29 23:21:42	1.1
+++ ai12s/ai12-0435-1.txt	2021/06/03 02:45:18	1.2
@@ -287,3 +287,145 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Sunday, May 30, 2021  9:00 AM
+
+Randy recently posted AIs for our upcoming review of WG9 comments.  He asked
+me to comment on the Put_Image/Stream attribute fixups.  Here are two of the
+four issues for which I had a comment:
+
+>(1) Modify 4.10(6/5):
+>   For an untagged derived type{, or a null extension}, the default
+>   implementation of T'Put_Image invokes the Put_Image for its parent type
+>   on a conversion of the parameter of type T to the parent type.
+>Modify 4.10(15/5):
+>   For a {nonnull} 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.
+>...
+>(4) Modify 13.13.2(9.1/5):
+>  {For derived types, the default implementations of the Write and Read
+>  attributes are not inherited, but are rather implicitly composed.} For
+>  type extensions, the Write or Read attribute for the parent type is
+>  called, followed by the Write or Read attribute of each component of the
+>  extension part, in canonical order. For a limited type extension, if the
+>  attribute of the parent type or any progenitor type of T is available
+>  anywhere within the immediate scope of T, and the attribute of the parent
+>  type or the type of any of the extension components is not available at
+>  the freezing point of T, then the attribute of T shall be directly
+>  specified. For untagged derived types, the Write (resp. Read) attribute
+>  invokes the corresponding attribute of the parent type, if the attribute
+>  is available for the parent type.
+>[Editor's complaint: This only covers Read and Write. What about Input
+>and Output, and the class-wide versions of all of these?? I would have expected
+>a general statement at the top of 13.13.2 instead of this.]
+
+I think we could instead put a general statement at the end of paragraph 
+13.13.2(38/4):
+
+Modify 13.13.2(38/4):
+The stream-oriented attributes may be specified for any type via an 
+attribute_definition_clause. [Alternatively, each of the specific 
+stream-oriented attributes may be specified using an aspect_specification
+on any type_declaration, with the aspect name being the corresponding
+attribute name.] Each of the class-wide stream-oriented attributes may be
+specified using an aspect_specification for a tagged type T using the name
+of the stream-oriented attribute followed by 'Class; such class-wide aspects
+do not apply to other descendants of T. {If not directly specified, a default
+implementation of a stream-oriented attribute is implicitly composed for a
+nonlimited type, and for certain limited types, as defined above.}
+ 
+>!discussion
+>(1) It's unclear to the Editor whether this is really a principle that we
+>want to support. OTOH, he has consistently objected to treating null
+>extensions specially and has lost that argument consistently.
+
+As far as the proposal about null extensions identified as issue (1) above,
+here is the logic:  If you have a tagged type T1 and its null extension T2,
+the default implementation of the Put_Image attributes for T1 and T2 will be
+identical, since they will each be displayed as a record aggregate, and they
+have the same number of components.  Similarly, if the parent of T1 (or some
+more remote ancestor) has a Put_Image attribute specified (let's call it T0),
+then the implicitly composed Put_Image attributes for T1 and T2 will again be
+identical, since they have the same set of additional components relative to
+T0.  So it makes sense that in general the implicitly composed Put_Image
+attribute for T2 should be the same as whatever T1'Put_Image produces. Another
+reason for null extensions to directly reuse the Put_Image of their parent is
+that a standard idiom for making a tagged type exported by a generic
+instantiation directly visible, is by using a null extension, so it would be
+annoying to instantiate a generic which provides a Put_Image, and then
+suddenly find a "(... with Null)" wrapper appearing around all of the 'Image
+results.  Finally, we have gone out of our way to make (essentially) all
+primitive operations of a type be inherited "as is" by a null extension,
+including functions with controlling results, which would normally require
+overriding.  So "inheriting" Put_Image (via implicit composition) as is,
+makes sense as well.
+...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 2, 2021  9:43 PM
+
+>>	!discussion
+>>	(1) It's unclear to the Editor whether this is really a principle that we
+>>	want to support. OTOH, he has consistently objected to treating null
+>>	extensions specially and has lost that argument consistently.
+
+>	As far as the proposal about null extensions identified as issue (1) above,
+> here is the logic:  If you have a tagged type T1 and its null extension T2, the
+> default implementation of the Put_Image attributes for T1 and T2 will be
+> identical, since they will each be displayed as a record aggregate, and they
+> have the same number of components.  Similarly, if the parent of T1 (or some
+> more remote ancestor) has a Put_Image attribute specified (let's call it T0), 
+> then the implicitly composed Put_Image attributes for T1 and T2 will again be
+> identical, since they have the same set of additional components relative to
+> T0.  So it makes sense that in general the implicitly composed Put_Image 
+> attribute for T2 should be the same as whatever T1'Put_Image produces.
+
+This seems like justifying a glitch by doubling down on the glitch: I see no
+reason that T1 and T2 necessarily have the same Image, by default or any other
+reason. Perhaps the advice makes that the case, but that would seem to be
+accidental rather than any sort of intentional result.
+
+> Another reason for null extensions to directly reuse the Put_Image of their 
+> parent is that a standard idiom for making a tagged type exported by a 
+> generic instantiation directly visible, is by using a null extension, so
+> it would be annoying to instantiate a generic which provides a Put_Image,
+> and then suddenly find a "(... with Null)" wrapper appearing around all of
+> the 'Image results.
+
+This "idiom" is evil, and needs to be replaced by something (anything!) else.
+One *never* wants to introduce a type unless one really needs it to be
+different in an apples-and-oranges sense. If the Image was to increase
+encouragement to avoid this idiom (and perhaps provide a replacement, as in
+deferred AI12-0229-1), that would seem to be a good thing!
+
+> Finally, we have gone out of our way to make (essentially) all primitive 
+> operations of a type be inherited "as is" by a null extension, including
+> functions with controlling results, which would normally require
+> overriding. So "inheriting" Put_Image (via implicit composition) as is, 
+> makes sense as well.
+
+This is also evil, at least for the likely uses that I have for null
+extensions. Most likely, a null extension is just a placeholder for a type
+that eventually will gain extension components (it's unlikely that one can
+usefully replace operations of a type without some additional/different data).
+In this case, getting a clean compiler for a null extension tells one nothing
+about the requirements on the type in the actual program; one has to declare
+dummy components in order to do that. Which brings up all of the problems of
+dummy components. I would not object to extending this capability to other
+extensions (those with extension components with appropriate defaults), as
+that would mitigate the problem -- but of course no extension to Image would
+make sense in that case. (AI12-0083-1, also deferred, proposed something on
+this line to make classic mix-in generics more general.)
+
+Anyway, as I stated at the outset, I've consistently lost this argument, so
+I'll go crawl back under my rock. :-)
+
+****************************************************************

Questions? Ask the ACAA Technical Agent