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