CVS difference for ais/ai-00145.txt

--- ais/ai-00145.txt	2001/12/06 01:22:01	1.8
+++ ais/ai-00145.txt	2005/06/16 23:47:07	1.9
@@ -823,3 +823,144 @@
 pleroy@rational.com                             +33.1.30.12.09.66 FAX
 
 ****************************************************************
+
+From: Bob Duff
+Sent: Monday, June  6, 2005 12:37 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+4.5.1(3):
+
+3     function "and"(Left, Right : T) return T
+      function "or" (Left, Right : T) return T
+      function "xor"(Left, Right : T) return T
+
+    3.a/2 This paragraph was deleted.To be honest: {AI95-00145-01}
+
+    3.b/2 Ramification: {AI95-00145-01} For these operators, we are talking
+          about the type itself, and not some subtype of it. Since it's
+          possible that the type itself cannot be named, we denote the type
+          with an italicized T. This applies to the italicized T in many other
+          predefined operators and attributes as well.{T (italicized)}
+
+    3.c/2 {AI95-00145-01} In many cases, there is a subtype with the correct
+          properties available. The italicized T means:
+
+The old version of 3.a says:
+
+    3.a   To be honest: For predefined operators, the parameter and result
+          subtypes shown as T are actually the unconstrained subtype of the
+          type.
+
+I don't understand this change.  In particular: "it's possible that the type
+itself cannot be named".  But types can never be named in Ada -- only subtypes
+can.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June  6, 2005  7:15 PM
+
+I agree, this new wording seems bogus.  The "type itself"
+doesn't mean anything.  Formal parameters always
+have a subtype.  I think the issue is that we
+are not necessarily talking about the *first* subtype,
+but rather perhaps some anonymous unconstrained
+subtype.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June  6, 2005  9:55 PM
+
+...
+> The old version of 3.a says:
+>
+>     3.a   To be honest: For predefined operators, the parameter and result
+>           subtypes shown as T are actually the unconstrained subtype of the
+>           type.
+>
+> I don't understand this change.
+
+"unconstrained subtype" is not correct; this could be a constrained type if
+it has no constraints. In any case, I was trying to summarize AI-145, which
+is trying to explain what these things mean. Since reviewers (including you,
+I think) seem to have been confused about the meanings of these things, I
+figured a more complete explanation was needed. The ARG decided that this
+didn't need a wording change, so "To be honest" seems the wrong heading.
+
+> In particular: "it's possible that the type itself cannot be named".
+> But types can never be named in Ada -- only subtypes can.
+
+True enough. It probably should say something to the effect that an
+appropriate subtype of the type cannot be named.
+
+But I guess the bigger problem is occurs if you insist that this means some
+sort of subtype (especially other than the first subtype). Subtypes don't
+appear out of thin air! I can justify in my mind that the predefined
+operators work on the type directly, but if they're supposed to work on some
+subtype, we'd need to clearly define that subtype. Especially if it is not
+the obvious one (the first subtype). Ergo, we do need a wording change to
+the Standard.
+
+That is, we should define "base subtype" or something like that to mean what
+is given in the bullets in 4.5.1(3.d-3.f). And then we should explicitly say
+that all of these operations have parameters and results of the appropriate
+base subtypes. (Both in Section 4 and 13 and anywhere else that this
+notation is used.)
+
+Tucker wrote:
+
+> I agree, this new wording seems bogus.  The "type itself"
+> doesn't mean anything.  Formal parameters always
+> have a subtype.  I think the issue is that we
+> are not necessarily talking about the *first* subtype,
+> but rather perhaps some anonymous unconstrained
+> subtype.
+
+I don't think we can base the language on "rather perhaps"! And we can't say
+that they *are* unconstrained (because that might not be true). And I can't
+justify this as a "ramification" if we are talking about some magical
+subtype never defined or described by the language. "type without any
+subtype" makes sense, but not "subtype from the following bulleted list"!
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June  7, 2005  4:20 PM
+
+> > In particular: "it's possible that the type itself cannot be named".
+> > But types can never be named in Ada -- only subtypes can.
+>
+> True enough. It probably should say something to the effect
+> that an appropriate subtype of the type cannot be named.
+
+Agreed.
+
+> But I guess the bigger problem is occurs if you insist that
+> this means some sort of subtype (especially other than the
+> first subtype). Subtypes don't appear out of thin air! I can
+> justify in my mind that the predefined operators work on the
+> type directly, but if they're supposed to work on some
+> subtype, we'd need to clearly define that subtype. Especially
+> if it is not the obvious one (the first subtype). Ergo, we do
+> need a wording change to the Standard.
+>
+> That is, we should define "base subtype" or something like
+> that to mean what is given in the bullets in 4.5.1(3.d-3.f).
+> And then we should explicitly say that all of these
+> operations have parameters and results of the appropriate
+> base subtypes. (Both in Section 4 and 13 and anywhere else
+> that this notation is used.)
+
+Please don't go there.  This is an extremely unimportant issue, and we
+decided when AI 145 was discussed that it was not necessary to change any
+wording.  There is no reason to revisit this decision now.  This is only
+an AARM note anyway, the purpose of which is to clarify the meaning of the
+italicized T for language lawyers and compiler writers.  No point in being
+overly pedantic.
+
+Btw, in this AARM note, you are writing "italized"; the correct spelling
+is "italicized".
+
+****************************************************************