CVS difference for ai05s/ai05-0019-1.txt

Differences between 1.11 and version 1.12
Log of other versions for file ai05s/ai05-0019-1.txt

--- ai05s/ai05-0019-1.txt	2008/12/22 07:39:47	1.11
+++ ai05s/ai05-0019-1.txt	2011/02/12 08:08:55	1.12
@@ -137,7 +137,7 @@
 
 
 Another problem that came up in the discussion is this: 13.3(6) says that a subprogram
-used in an attribute_definition_clause must have convention Ada. This is nasty 
+used in an attribute_definition_clause must have convention Ada. This is nasty
 because the subprogram may only be frozen *after* the type to which the
 attribute_definition_clause is applied:
 
@@ -186,7 +186,7 @@
 The @i<freezing> of an entity occurs at one or more places (@i<freezing points>) in
 the program text where the representation for the entity has to be fully determined.
 Each entity is frozen from its first freezing point to the end of the program text
-(given the ordering of compilation units defined in 10.1.4). 
+(given the ordering of compilation units defined in 10.1.4).
 @dinst
 This clause also defines a place in the program text where the profile of each declared
 callable entity becomes @i<frozen>. A use of a callable entity causes freezing of its
@@ -326,7 +326,7 @@
 to do just that, which depends on the above rule, so that's how we
 ran into a bunch of incompatibilities (CLAW is by the way one of the
 programs that bumps into this :-))
-> 
+>
 > If not, I presume this rule applies to Ada 95, since the AI is classified as a
 > binding interpretation.  Right?
 
@@ -510,7 +510,7 @@
 > type and freezing points of the primitives.  A little sad, but hardly worth
 > this incompatibility.
 
-More than a little sad, means throwing away a months work and missing 
+More than a little sad, means throwing away a months work and missing
 the release on the static dispatch tables, oh well :-(
 
 ****************************************************************
@@ -532,7 +532,7 @@
 a derivative of it, so clearly by then the formal parameter will have
 been frozen.  I don't think dispatching makes it any harder at the
 point of the call.
-> 
+>
 > We should certainly check this idea out more carefully, because freezing
 > unrelated class-wide types that happen to be used as parameters in primitive
 > operations is unpleasant. (I don't relish trying to restructure Claw -- it
@@ -617,17 +617,17 @@
 From: Edmond Schonberg
 Date: Friday, November 10, 2006  5:49 PM
 
-The concerns that Bob first voiced come from the implementation of  
-the AI-341 rule in GNAT (part of a move to build static dispatch  
-table). We found two dozen tests in our regression suite that were  
-now rejected. We are checking that those rejections are correct, i.e.  
-that our implementation is not crying wolf unnecessarily. Most of the  
-cases I have seen involve a class-wide parameter, so it is very  
-likely that Tucker's relaxed rule will fix those. However, it is  
-really a pity to give up the possibility of building static dispatch  
-tables, and for that the subprograms have to be frozen. We will  
-report in a few days on whether the cases that are properly rejected  
-are hard to fix, or require just moving some declaration further  
+The concerns that Bob first voiced come from the implementation of
+the AI-341 rule in GNAT (part of a move to build static dispatch
+table). We found two dozen tests in our regression suite that were
+now rejected. We are checking that those rejections are correct, i.e.
+that our implementation is not crying wolf unnecessarily. Most of the
+cases I have seen involve a class-wide parameter, so it is very
+likely that Tucker's relaxed rule will fix those. However, it is
+really a pity to give up the possibility of building static dispatch
+tables, and for that the subprograms have to be frozen. We will
+report in a few days on whether the cases that are properly rejected
+are hard to fix, or require just moving some declaration further
 down, in which case we can tell users to adapt.
 
 ****************************************************************
@@ -781,7 +781,7 @@
 > freezing rules made me extremely uncomfortable, but unfortunately this AI
 > was only discussed at this one meeting, so I didn't have time to look for
 > a compelling example that would have killed the proposal.
-> 
+>
 > Now one thing that I didn't realize is that, being a binding
 > interpretation, it applies to Ada 95.  It would have been bad enough to
 > ask customers to restructure their code when migrating to Ada 2005, but
@@ -800,7 +800,7 @@
 > surgery.  And now that open-heart surgery failed we are going to do a
 > heart-lung transplant by completely changing the way that tagged types get
 > frozen.
-> 
+>
 > Changing the freezing rules should only be done with the utmost care.  One
 > reason is that it's really hard to work out all their consequences.
 > Another reason is that they are really hard to implement, and that since
@@ -808,7 +808,7 @@
 > be very destabilizing for implementations.  Finally, these rules are
 > rather incomprehensible to users, so it's actively harmful to make them
 > more complicated than they already are.
-> 
+>
 > Incidentally, I implemented this AI fairly recently (for Ada 2005 only),
 > and was very surprised to see that it led to incompatibilities in our own
 > code.  Only a very small number of the Amendment changes have had that
@@ -818,7 +818,7 @@
 > change to Ada 95, regardless of what the ARG decides: I don't particular
 > want to p*ss off customers.
 
-It would be nice if you would pass on this kind of surprise when it 
+It would be nice if you would pass on this kind of surprise when it
 happens, or is this also IBM restricted information? :-)
 
 ****************************************************************
@@ -826,12 +826,12 @@
 From: Pascal Leroy
 Date: Tuesday, November 14, 2006  1:48 AM
 
-> Before we move too fast on this, let's complete our study of 
-> whether introducing the relaxation of the rule that was 
-> suggested preserves the behavior we want without introducing 
-> too much incompatibility. First looks in our test suite 
-> indicate that all (yes, 100%) of the compatibility issues 
-> disappear with this relaxation, so this may be the answer. 
+> Before we move too fast on this, let's complete our study of
+> whether introducing the relaxation of the rule that was
+> suggested preserves the behavior we want without introducing
+> too much incompatibility. First looks in our test suite
+> indicate that all (yes, 100%) of the compatibility issues
+> disappear with this relaxation, so this may be the answer.
 > More details from Javier later
 
 Well, let's not ignore the fact that you might be lucky.  I found one
@@ -844,7 +844,7 @@
 
 Since Cursor is untagged, the relaxation proposed by Tuck wouldn't help.
 
-> It would be nice if you would pass on this kind of surprise when it 
+> It would be nice if you would pass on this kind of surprise when it
 > happens, or is this also IBM restricted information? :-)
 
 I will, but that won't happen until I return from the ARG meeting.
@@ -883,13 +883,13 @@
 
 Consider a program like your example from that AI (AI05-0017-1):
 
-	package Stt is 
-	    type T is tagged private; 
-	    function F return access T'Class; 
-	    function G (X : access T) return Integer; 
-	    I : Integer := G (F); 
+	package Stt is
+	    type T is tagged private;
+	    function F return access T'Class;
+	    function G (X : access T) return Integer;
+	    I : Integer := G (F);
 	private
-	    type T is tagged null record; 
+	    type T is tagged null record;
 	end Stt;
 
 Surely we want the call of G(F) to freeze F and more importantly, the result
@@ -910,6 +910,55 @@
 
 Hope you were not shaving with a blade. It's dangerous to think about freezing
 while shaving with a blade...could lose a nose or ear!
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Thursday, February 10, 2011  6:17 PM
+
+I'd just like some clarification about AI05-0019, to make sure my understanding
+is correct.
+
+The !summary of this AI says, "The types of tagged parameters are not frozen
+when the subprogram is frozen".  However, I've looked over the rule changes in
+the !wording section, and I can't find anything that treats tagged parameters
+and untagged parameters differently.  This is making a difference in a piece of
+code I'm looking at:
+
+   package Pack1 is
+      type T1 is tagged record ... end record;
+      type T2 is private;
+      procedure Proc1 (P1 : in out T1; P2 : in T2);
+   private
+      C : constant T1 := ...;
+      type T2 is ...;
+   end Pack1;
+
+GNAT rejects this, and the reason appears to be that the declaration of C
+freezes T1, which freezes Proc1 by 13.14(15.1).  My understanding is that prior
+to AI05-0019, this caused T2 to be frozen also, which would have led to the
+error.  But it appears to me that AI05-0019 makes this legal, despite the
+summary of the AI, since the rule changes seem to apply to this case just as
+much as in the examples shown in the AI.
+
+Is this correct, or am I missing some other rule that makes this illegal?  (Note
+that I'm not asking for anything to be changed; if the word "tagged" in the
+!summary of the AI is misleading, it doesn't matter since this language doesn't
+appear in the RM.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011  6:39 PM
+
+You are correct. We started out with a rule that only applied to tagged types,
+but that didn't work very well. Someone came up with the idea of separating the
+freezing of profiles from the freezing of subprograms, which works much better
+and is more consistent (it's best to have the rules for all types to be the
+same). Apparently, the summary never got changed.
+
+So I think your program is legal; I don't see any reason that anything there
+should freeze T2 until "end Pack1".
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent