CVS difference for ai12s/ai12-0005-1.txt
--- ai12s/ai12-0005-1.txt 2019/06/11 04:13:53 1.29
+++ ai12s/ai12-0005-1.txt 2019/10/11 23:49:31 1.30
@@ -1450,7 +1450,197 @@
***************************************************************
-Editor's note (May 28, 2019): All of the items above this
+From: Pascal Pignard
+Sent: Wednesday, October 9, 2019 11:56 PM
+
+[From private mail.]
+
+I've read the AARM 202x draft 22 (text version).
+
+Section 12.3 Generic Instantiation, I've found:
+- Paragraph 15:
+15.h type T1 is tagged record ... end record;
+15.i generic
+ type Formal is new T1;
+ package G is
+ type Derived_From_Formal is new Formal with record ... end record;
+ procedure Foo(X : in Derived_From_Formal); -- Does not override anything.
+ end G;
+15.j type T2 is new T1 with record ... end record;
+ procedure Foo(X : in T2);
+15.k package Inst is new G(Formal => T2);
+
+== As T1 is tagged, Formal needs "with private", as:
+type Formal is new T1 with private;
+
+Is it correct?
+
+- Paragraph 22:
+22.e generic
+ type T1 is private;
+ -- A predefined "=" operator is implicitly declared here:
+ -- function "="(Left, Right : T1) return Boolean;
+ -- Call this "="(1).
+ package G is
+ subtype S1 is T1; -- So we can get our hands on the type from
+ -- outside an instance.
+ type T2 is new T1;
+ -- An inherited "=" operator is implicitly declared here:
+ -- function "="(Left, Right : T2) return Boolean;
+ -- Call this "="(2).
+
+22.f T1_Obj : T1 := ...;
+ Bool_1 : Boolean := T1_Obj = T1_Obj;
+
+22.g T2_Obj : T2 := ...;
+ Bool_2 : Boolean := T2_Obj = T2_Obj;
+ end G;
+
+== As T1 is a private formal type, so unknown, and therefore T2 unknown as
+well (derived from T1), what initial value could be given for T1_Obj and
+T2_Obj? Should be added a formal function? as:
+with function Init return T1;
+So:
+T1_Obj : T1 := Init;
+T2_Obj : T2 := T2 (Init);
+Thus:
+22.h package P is
+ type My_Int is new Integer;
+ -- A predefined "=" operator is implicitly declared here:
+ -- function "="(Left, Right : My_Int) return Boolean;
+ -- Call this "="(3).
+ function "="(X, Y : My_Int) return Boolean;
+ -- Call this "="(4).
+ -- "="(3) is hidden from all visibility by "="(4).
+ -- Nonetheless, "="(3) can "reemerge" in certain circumstances.
+ function Init return My_Int; -- == Added ==
+ end P;
+ use P;
+ ...
+ package I is new G(T1 => My_Int, Init => Init);
+ -- "="(5) is declared in I (see below). -- == Changed ==
+ use I;
+
+Is it correct?
+
+***************************************************************
+
+From: Pascal Pignard
+Sent: Wednesday, October 9, 2019 11:56 PM
+
+[From private mail.]
+
+I've read the AARM 202x draft 22 (text version).
+
+Section 12.6 Formal Subprograms, I've found:
+8.k/2 generic
+ type NT(<>) is new T with private;
+ -- Presume that T has the following primitive operation:
+ -- with procedure Bar (Obj : in T);
+ package Gr ...
+
+The comment:
+ -- with procedure Bar (Obj : in T); would be better :
+ -- procedure Bar (Obj : in T); wouldn't it?
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 10, 2019 7:53 PM
+
+[Sent to Tucker Taft.]
+
+Both of these are original Ada 95 examples; I found both in the October 1994
+draft AARM as well as the current draft AARM.
+
+I'm pretty sure the first comment is correct, as the second sentence of
+12.5.1(5/3) clearly applies. It's rather amazing that no one noticed this
+obvious mistake in the last 25 years.
+
+For the second comment, I think that adding a formal subprogram would hide the
+operative parts of the example. Since it is incomplete already, I propose
+adding "..." to the formal part and to the instance in the example to show that
+there are other formal parameters without burdening the reader with the details.
+
+Do you agree with both of these?
+
+Assuming so, these are both AARM examples, so I propose to put this thread into
+ AI12-0005-1 and then make the corrections (we do not follow a formal process
+for fixing the AARM unless there is a question that needs ARG input).
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 10, 2019 8:45 PM
+
+They both look like legitimate gripes to me. The first is clearly a bug. The
+second is simply complaining about the fact that there is no legitimate
+replacement for the ellipsis, which is interesting, but doesn't affect the
+fundamental point of the example, so is clearly less important (though more
+impressive as far as being noticed at all!).
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, October 11, 2019 4:41 PM
+
+...
+> == As T1 is tagged, Formal needs "with private", as:
+> type Formal is new T1 with private;
+
+Yes, this is wrong. This is an original Ada 95 example, so this mistake has
+been in the AARM since at least October 1994 (I verified that in a draft from
+that time). Amazing that no one has reported it.
+
+...
+> == As T1 is a private formal type, so unknown, and therefore
+> T2 unknown as well (derived from T1), what initial value
+> could be given for T1_Obj and T2_Obj?
+> Should be added a formal function?
+
+This is also an original Ada 95 example. Tucker Taft found it amazing that
+you even saw this situation, so you should pat yourself on the back for that.
+
+However, correcting this as you suggest would somewhat hide the point of the
+example. Such a formal function is unrelated to the point and could only
+confuse a reader (and of course it makes the example longer). A better
+solution [given that the example already uses ellipses (...) in a number of
+places] is to place ellipses in the formal parameter list and in the
+instantiation to show that there are additional formal parameters without
+mentioning what they are.
+
+P.S. Note that this is an instance of what Steve Baird calls "heat vision"
+(think Superman). When one reads old text, it sometimes explodes into flames.
+Best to only read existing text if one has a need to understand it for some
+reason, lest your entire AARM turn to ashes. ;-)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, October 11, 2019 4:42 PM
+
+I don't find this important at all, but I suppose you are right. Again, this
+is an example from Ada 2005, so it has been around for 12+ years and I don't
+think anyone has been confused. It's common to think of primitive operations
+of formal type much like implicit formal parameters - so the only reason to
+change this is that the parameter is the wrong type for such a formal
+parameter.
+
+In any case, we're mostly interested in finding problems in *new* text (/4
+and /5 paragraphs), not in examples that have been around forever. It takes
+time and energy to make these changes that probably would be better spent on
+things that are really wrong and/or brand-new (such as the stray text you
+noted in Chapter 4).
+
+Note that I don't mean that you should skip reporting problems that you happen
+to notice, but more that you should try to avoid even reading for review old
+text because any such reading inevitably leads to complaints.
+(That's a sad fact about any document as large as the AARM; the same thing
+happens with the Janus/Ada documentation and the Claw documentation.)
+
+***************************************************************
+
+Editor's note (October 11, 2019): All of the items above this
marker have been included in the working version of the AARM.
****************************************************************
Questions? Ask the ACAA Technical Agent