CVS difference for 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