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

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

--- ai05s/ai05-0019-1.txt	2006/11/13 23:47:09	1.3
+++ ai05s/ai05-0019-1.txt	2006/12/16 03:13:18	1.4
@@ -568,3 +568,120 @@
 appear before the type is frozen."
 
 ****************************************************************
+
+From: Dan Eilers
+Date: Monday, November 13, 2006  7:52 PM
+
+> I'm not sure if it is worth it (not having seen how CLAW has problems
+> with this new rule... ;-)
+
+The problem is with type Root_Control_Type in Claw.ads.
+
+Adam has come up with an example where rearranging the code
+is not feasible:
+
+   package P is
+        type T1 is tagged private;
+        type T2 is tagged private;
+        procedure Primitive (X : T1'Class; Y : T2);
+    private
+        type T2 is tagged null record;
+        type T2_Acc is access all T2;
+        Object : aliased T2; -- Freeze T2 here.
+        type T1 is tagged record
+           F1 : T2_Acc := Object'Access;
+        end record;
+    end P;
+
+
+Pascal wrote:
+> Since the problem is relatively marginal, we should  fix it by a small
+> tweaking of the rules, and drop AI 341.  I believe that something like the
+> following would work:
+>
+> "A representation_item for a primitive subprogram of a tagged type shall
+> appear before the type is frozen."
+
+This sounds good.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, November 13, 2006  9:30 PM
+
+> I hate to say I told you so, but I told you so.  I was the lone "against"
+> vote when this AI was discussed in Palma, because I didn't buy the
+> argument that "you just move the pragma around".  Messing with the
+> 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
+> forcing them to do that in Ada 95 is intolerable.
+
+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
+
+> I am all in favor of maintaining the invariant that dispatching tables may
+> be laid out when the type is frozen, but the problem described by the AI
+> was a relatively obscure wart, and we fixed it by doing open-heart
+> 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
+> (some) compilers make many decisions at the freezing point, any change can
+> 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
+> effect.  I am not aware of problems in our regression tests, but that must
+> be because the change has not percolated far enough yet: I am sure that
+> Claw is one of our tests.  At any rate, I am *not* going to apply this
+> 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 
+happens, or is this also IBM restricted information? :-)
+
+****************************************************************
+
+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. 
+> More details from Javier later
+
+Well, let's not ignore the fact that you might be lucky.  I found one
+incompatibility in our implementation of the containers yesterday: the
+full declaration for Empty_List freezes List, which freezes Cursor
+(because of the numerous subprograms that take both a List and a Cursor),
+and Cursor was not completely defined.  In this instance the fix was just
+to move up the full declaration for Cursor, but as Adam's example
+demonstrates, things can get ugly in other cases.
+
+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 
+> happens, or is this also IBM restricted information? :-)
+
+I will, but that won't happen until I return from the ARG meeting.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent