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

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

--- ai12s/ai12-0384-1.txt	2020/06/11 01:21:12	1.1
+++ ai12s/ai12-0384-1.txt	2020/06/11 04:23:38	1.2
@@ -1,4 +1,4 @@
-!standard 4.10(0)                                20-06-10  AI12-0384-1/01
+!standard 4.10(0)                                20-06-10  AI12-0384-1/02
 !class Amendment 20-06-10
 !status work item 20-06-10
 !status received 20-06-10
@@ -115,10 +115,33 @@
   where the Wide_Wide_String value written out to the [stream]{text
   buffer} is defined as follows:
 
+Modify AARM 4.10(13.a/5):
+
+  In general, the default implementation of T'Put_Image for a 
+  composite type will involve some sequence of calls to 
+  [Wide_Wide_String'Write]{Put and its Wide and Wide_Wide variants}
+  and calls to the Put_Image procedures of component types and, in the case of 
+  an array type, index types. The [Wide_Wide_String'Write]{Put} calls may pass in 
+  either literal values (e.g., "(", ")", "'(", " => ", or ", "), or other 
+  things (such as component names for record values, task_id images for tasks, 
+  or the Wide_Wide_Expanded_Name of the tag in the class-wide case). 
+
+Modify 4.10(16/5):
+  For a class-wide type, the default implementation of T'Put_Image generates
+  an image based on qualified expression syntax. 
+  [Wide_Wide_String'Write]{Wide_Wide_Put} is called with 
+  Wide_Wide_Expanded_Name of Arg'Tag. Then S'Put_Image is called,
+  where S is the specific type identified by Arg'Tag.
+
+
 Add after 4.10 (23/5):
 
-  For a private type or a private extension T, the default
-  implementation of T'Put_Image is the same as that for its full type.
+  Redundant[T'Put_Image is the same for all views of T, including any partial 
+  views.]
+
+  AARM Proof: A type-related operation aspect is the same for views of a type, 
+  see 13.1.
+
   
 Modify 4.10 (28/5):
 
@@ -382,23 +405,30 @@
 
 !discussion
 
-See !problem and !proposal
+See !problem and !proposal.
 
-We have clarified that private types have the same default
+We have added a reminder that private types have the same 
 implementation of Put_Image as their full type. Another choice would be
 to say that Put_Image is not defined on a private type unless explicitly
 provided, though that would clearly make composability more of a pain,
-analogous to what happens with 'Write on limited types.  Clearly any
+analogous to what happens with 'Write on limited types. Clearly any
 implementor of a private type should specify Put_Image if they are
-concerned about the loss of information hiding.  For compatibility
-reasons we can't really change what Put_Image does on the full type, and
-making the run-time semantics of Put_Image depend on where you invoke it
-seems like a generally bad idea.  So I think we are stuck with either
-hiding it completely, or having it do the same thing as on the full
-type.  Actually, one option is to hide 'Image, but not hide 'Put_Image,
-on a private type.  That would mean that composability is not interrupted,
-but a "casual" use of 'Image would not be possible without an explicit
-declaration of Put_Image in the visible part of the package.
+concerned about the loss of information hiding. For compatibility
+reasons we can't really change what Put_Image does on the full type, 
+and making the run-time semantics of Put_Image depend on where you invoke it
+seems like a generally bad idea (as well as requiring defining a new kind
+of aspect with it's own set of rules).
+
+One could imagine other rules, such as hiding 'Image, but not hide 'Put_Image,
+on a private type. But given that the motivating purpose of the expansion of 
+'Image is to ease debugging/logging (see the !problem of AI12-0020-1), 
+restrictions on the use of 'Image would just get in the way of the intended
+use. Additionally, there is nothing in the default 'Image that can't be
+learned from reading the specification of the private type, so any hiding
+is dubious anyway.
+
+Users with critically information leakage concerns can always define their
+own Put_Image to block such leakage.
 
 !ASIS
 
@@ -415,7 +445,228 @@
 
 !appendix
 
+From: Tucker Taft
+Sent: Sunday, April 26, 2020  9:07 AM
+
+I am in the process of putting together an AI that includes a set of proposed 
+"fix-ups" for AI12-0020-1 (Put_Image) and AI12-0340-1 (Put_Image should use 
+Text_Buffers) resulting from Bob Duff's implementation efforts.  Along the 
+way, I noticed at least one AARM note in the new 4.10 section that is talking
+about Wide_Wide_String'Write, along with one normative paragraph:
+
+13.a/5: 
+Discussion: In general, the default implementation of T'Put_Image for a 
+composite type will involve some sequence of calls to Wide_Wide_String'Write 
+and calls to the Put_Image procedures of component types and, in the case of 
+an array type, index types. The Wide_Wide_String'Write calls may pass in 
+either literal values (e.g., "(", ")", "'(", " => ", or ", "), or other 
+things (such as component names for record values, task_id images for tasks, 
+or the Wide_Wide_Expanded_Name of the tag in the class-wide case). 
+
+16/5:
+For a class-wide type, the default implementation of T'Put_Image generates an 
+image based on qualified expression syntax. Wide_Wide_String'Write is called 
+with Wide_Wide_Expanded_Name of Arg'Tag. Then S'Put_Image is called, where S 
+is the specific type identified by Arg'Tag.
+
+I'll try to remember to include these in my AI, but they are clearly unrelated 
+to the lessons learned from Bob's implementation work, so might be better in 
+some sort of "editorial fix-up" AI.
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Wednesday, June 10, 2020  6:02 PM
+
+A thought on this unposted AI (it will be posted soon, but I wanted this on the 
+record): 
+
+... 
+> !discussion
+> 
+> See !problem and !proposal
+> 
+> We have clarified that private types have the same default 
+> implementation of Put_Image as their full type. Another choice would 
+> be to say that Put_Image is not defined on a private type unless 
+> explicitly provided, though that would clearly make composability more 
+> of a pain, analogous to what happens with 'Write on limited types.  
+> Clearly any implementor of a private type should specify Put_Image if 
+> they are concerned about the loss of information hiding.  For 
+> compatibility reasons we can't really change what Put_Image does on 
+> the full type, and making the run-time semantics of Put_Image depend 
+> on where you invoke it seems like a generally bad idea.  So I think we 
+> are stuck with either hiding it completely, or having it do the same 
+> thing as on the full type.  Actually, one option is to hide 'Image, 
+> but not hide 'Put_Image, on a private type.  That would mean that 
+> composability is not interrupted, but a "casual" use of 'Image would 
+> not be possible without an explicit declaration of Put_Image in the 
+> visible part of the package.
+
+The latter part of this discussion seems silly to me. The primary goal was to 
+provide 'Image for all types to ease debugging/logging, and secondarily 
+user-defined 'Image to allow the use of more appropriate images for types like 
+Big_Integer and Vector. The goal was *not* to provide 'Image for all types 
+except private types! Moreover, for debugging one generally wants most or all 
+of the private data - information hiding is not a goal when debugging. Even 
+for the containers, we want the result to show the complete contents of the 
+container (just suppressing some of the control information). Finally, any 
+sort of hiding rule would greatly complicate the definition of Image. (We had
+to use such a thing for streaming as no useful default streaming is available
+for some types, such as tasks, no such problem exists for Image.)
+
+The default of the Image of the full type seems to be the natural and correct 
+implementation to meet these primary goals. Remember that a private type in 
+Ada is private in name only -- it's sitting right there in the source where 
+anyone can inspect it. Hiding details of a type cannot be done with private 
+types alone, so there's little reason to get too concerned about it.
+
+User-defined Put_Image can be used for the rare case where exposing the 
+internals of a type is a problem. 
+
+Note that the same analysis applies to incomplete types; I think we get to 
+ignore that as an incomplete type cannot be the prefix of an attribute nor can 
+an object with an incomplete type be the prefix of anything (including an 
+attribute).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 10, 2020  7:22 PM
+
+> The latter part of this discussion seems silly to me. ...
+
+Be that as it may, it seems worth exposing the issue, and attempting to 
+enumerate the alternatives...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 10, 2020  9:02 PM
+
+> ... 
+> > !discussion
+> > 
+> > See !problem and !proposal
+> > 
+> > We have clarified that private types have the same default 
+> > implementation of Put_Image as their full type.
+
+Furthermore, the AI has the following wording:
+
+Add after 4.10 (23/5):
+  For a private type or a private extension T, the default
+  implementation of T'Put_Image is the same as that for its full type.
+
+This literally goes without saying. Put_Image is defined to be a type-related 
+operational attribute/aspect by 4.10(2/5), and 13.1(11/3) says "Operational 
+and representation aspects are the same for all views of a type".
+(Tucker has pointed out privately that 13.1(11/3) and several other rules 
+really should only apply to type-related aspects, but even fixing that makes
+no change here.)
+
+Ergo, it is impossible for a private type to have a different Put_Image than 
+its full type. That has nothing to do with the default implementation or any 
+other qualification. If we wanted a difference (and I don't think we do), we 
+would need to change Put_Image to some other kind of attribute/aspect.
+
+If we're going to say anything at all here, it should be marked redundant and 
+much more general:
+
+   Redundant[For a private type or a private extension T, T'Put_Image 
+   is the same as that for its full type.]
+
+   AARM Proof: A type-related operation aspect is the same for views of a 
+   type, see 13.1.
+
+or maybe more simply:
+
+   Redundant[T'Put_Image is the same for all views of T, including any 
+   partial views.]
+
+with the same proof.
+
+The !discussion might mention that changing the basic model of type-related 
+aspects is unwise, giving some of the reasons discussed.
+
+In any case, the model here was copying the model of stream attributes, which 
+never bother saying anything about partial views. Not really sure why 
+Put_Image should be different.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June 10, 2020  9:27 PM
+
+> Ergo, it is impossible for a private type to have a different 
+> Put_Image than its full type. That has nothing to do with the default 
+> implementation or any other qualification. If we wanted a difference 
+> (and I don't think we do), we would need to change Put_Image to some other
+> kind of attribute/aspect.
+
+I don't entirely agree.  It is perfectly possible for a full view to have an 
+attribute, and the partial view to not have the attribute defined.  For example
+'Val is defined for a full view if it is an integer or an enumeration type, but
+not for the partial view.  So I agree they couldn't be different without 
+breaking various other Ada principles, but we could say that Put_Image is not 
+defined on the partial view, while it is defined on the full view.
+
+> ...
+> In any case, the model here was copying the model of stream 
+> attributes, which never bother saying anything about partial views. 
+> Not really sure why Put_Image should be different.
+
+It feels somewhat different, because we know that the binary representation of 
+data is the same independent of the view, but properties that are defined at a 
+higher level can certainly be different for a partial view and a full view.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 10, 2020  6:02 PM
+
+...
+> > Ergo, it is impossible for a private type to have a different 
+> > Put_Image than its full type. That has nothing to do with the default 
+> > implementation or any other qualification. If we wanted a difference 
+> > (and I don't think we do), we would need to change 
+> Put_Image to some other kind of attribute/aspect.
+> 
+> I don't entirely agree.  It is perfectly possible for a full 
+> view to have an attribute, and the partial view to not have 
+> the attribute defined.  For example 'Val is defined for a 
+> full view if it is an integer or an enumeration type, but not 
+> for the partial view.  So I agree they couldn't be different 
+> without breaking various other Ada principles, but we could 
+> say that Put_Image is not defined on the partial view, while 
+> it is defined on the full view.
+
+I don't think that exact model works (there was *some* reason that we invented 
+the entire concept of "availability"), but you are right that some sort of 
+similar model could be made to work. But that model would have to hide Image 
+and/or Put_Image of any type with a private component in the current view, 
+since the composition model would let any such type access the full 
+representation of the private type.
+
+The bigger problem is that the entire justification for defining universal 
+'Image is to support debugging (see the !problem for AI12-0020-1), and the 
+notion that no one wants to debug private types is ludicrous. Those who write 
+everything as ADTs would be helped hardly at all, as virtually all of their 
+types contain some private components. That way seems to lead to nowhere.
+
+> > ...
+> > In any case, the model here was copying the model of stream 
+> > attributes, which never bother saying anything about partial views. 
+> > Not really sure why Put_Image should be different.
+> 
+> It feels somewhat different, because we know that the binary 
+> representation of data is the same independent of the view, 
+> but properties that are defined at a higher level can 
+> certainly be different for a partial view and a full view.
+
+True, but that means abandoning the stream attribute model for some sort of 
+view-specific model. And then how composition is supposed to work seems 
+problematic. Sounds like a can of worms heading nowhere.
+
+****************************************************************
 

Questions? Ask the ACAA Technical Agent