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

--- ai05s/ai05-0110-1.txt	2010/12/15 00:10:57	1.7
+++ ai05s/ai05-0110-1.txt	2011/02/08 08:21:05	1.8
@@ -685,11 +685,60 @@
 ****************************************************************
 
 From: Steve Baird
-Date: Wednesday, July 28, 2010  7:37 PM
+Date: Wednesday, July 28, 2010  7:28 PM
 
-The following is my attempt to incorporate everyone's helpful feedback.
-Thanks all.
+[This message started with the wording shown in the next message; it's
+been removed here to avoid repetition. - Editor.]
 
+The idea is that we are not changing the language definition at all with respect
+to primitive subprograms. The new definition is intended to be equivalent to the
+old (just as it is equivalent with respect to another characteristic,
+components).
+
+Bob wrote:
+> But if you eliminate 12.5.1(21/3), then doesn't 7.3.1(6/3) need to say
+> "generic" somehow?
+
+I think the answer is "no", 7.3.1 says how to do it for a
+derived_type_definition. Then later, we say (in 12.5.1) "and it works the same
+way for formal derived types". In particular, note that the new wording in
+12.5.1 says "(see .. and 7.3.1)".
+
+I also don't see any need to add any wording about progenitors.
+It seems like that is handled in 3.4.
+
+Bob wrote:
+> My memory is somewhat hazy, but I think I intended "characteristic"
+> NOT to include primitive subprograms.
+
+That would make more sense to me. Characteristics other than primitive
+subprograms are not declared and there is no need to worry about the point at
+which they are declared. By including primitive subprograms we introduce that
+concern.
+
+It is appealing to argue that "if I know that A is derived from B and that B is
+an array type, then I should know that A is an array type". As Bob knows, this
+model is at least close to implementable (at least for Ada95) because Bob worked
+on converting the Rational compiler away from this incorrect model.
+
+On the other hand, I would concede that this model would introduce lots of
+corner cases that would need to be dealt with and that making a change along
+these lines at this point would be a terrible idea.
+
+****************************************************************
+
+From: Steve Baird
+Date: Monday, August 2, 2010  7:06 PM
+
+The following proposed wording was composed with input from Randy, Bob, and Tuck.
+This should not be taken to mean that they agree with it.
+
+The idea is that we are not changing the language definition at all with respect
+to primitive subprograms. The new definition is intended to be equivalent to the
+old (just as it should be equivalent with respect to another characteristic,
+components).
+
+
    !wording
 
    Replace 12.5.1(20/2)
@@ -731,41 +780,4 @@
 
 Comments?
 
-
-The idea is that we are not changing the language definition at all with respect
-to primitive subprograms. The new definition is intended to be equivalent to the
-old (just as it is equivalent with respect to another characteristic,
-components).
-
-Bob wrote:
-> But if you eliminate 12.5.1(21/3), then doesn't 7.3.1(6/3) need to say
-> "generic" somehow?
-
-I think the answer is "no", 7.3.1 says how to do it for a
-derived_type_definition. Then later, we say (in 12.5.1) "and it works the same
-way for formal derived types". In particular, note that the new wording in
-12.5.1 says "(see .. and 7.3.1)".
-
-I also don't see any need to add any wording about progenitors.
-It seems like that is handled in 3.4.
-
-Bob wrote:
-> My memory is somewhat hazy, but I think I intended "characteristic"
-> NOT to include primitive subprograms.
-
-That would make more sense to me. Characteristics other than primitive
-subprograms are not declared and there is no need to worry about the point at
-which they are declared. By including primitive subprograms we introduce that
-concern.
-
-It is appealing to argue that "if I know that A is derived from B and that B is
-an array type, then I should know that A is an array type". As Bob knows, this
-model is at least close to implementable (at least for Ada95) because Bob worked
-on converting the Rational compiler away from this incorrect model.
-
-On the other hand, I would concede that this model would introduce lots of
-corner cases that would need to be dealt with and that making a change along
-these lines at this point would be a terrible idea.
-
 ****************************************************************
-