CVS difference for ais/ai-00228.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00228.txt

--- ais/ai-00228.txt	2000/04/11 19:36:34	1.1
+++ ais/ai-00228.txt	2000/04/14 01:45:08	1.2
@@ -338,3 +338,78 @@
 
 *************************************************************
 
+From: Pascal Leroy
+Sent: Tuesday, April 11, 2000 3:30 PM
+
+> No, I don't actually see any relationship with AI 211; I don't agree with
+> any of this. The properties of G come from the "designated subprogram" of A,
+> which certainly is not a "must be renamed" entity. So G is always legal, and
+> certainly does not require any overriding. That is true for any renaming, I
+> don't know why you think that it ought to be different for this case.
+
+So you are telling me that the following ought to be legal:
+
+     X : A := F'Access;
+     function G return E renames X.all;
+     function F return E;
+
+but obviously AI 211 says that the following is illegal:
+
+     function G return E renames F;
+     function F return E;
+
+so much for consistent language design!  If your program is rejected because
+of AI 211, just add an extra access-to-subprogram variable, it makes it
+legal (and so much more readable).
+
+> Well, I don't agree that F'Access references the "must-be-overridden"
+> subprogram. Certainly a call to F references the concrete routine (put this
+> before the declaration of F2 in the example, assume a default initialized
+> object of it in the body of Extensions):
+>
+>     type Rec is record
+>        Comp : E := F; -- Must reference the concrete routine,
+>                       -- not the "must-be-overridden" one.
+>     end record;
+>
+> So why should 'Access be different?
+
+I don't care about dynamic semantics, I am talking name resolution and
+legality rules.  In the above expression, the name F designates the
+subprogram that will be overridden; it happens that at execution you call
+the overriding one, but in this language we try to precisely define the
+meaning of a name as opposed to what happens at execution.
+
+If you say that the name F in F'Access references the overriding subprogram,
+you are introducing a case where a name references an entity which has not
+been declared yet.  This is something entirely new, and it's going to break
+more that one compiler (for no good reason).
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 11, 2000 6:44 PM
+
+> I don't care about dynamic semantics, I am talking name resolution and
+> legality rules.
+
+But it is only the dynamic semantics that matters. There is no name resolution
+or legality problem here.
+
+> In the above expression, the name F designates the
+> subprogram that will be overridden; it happens that at execution you call
+> the overriding one, but in this language we try to precisely define the
+> meaning of a name as opposed to what happens at execution.
+> If you say that the name F in F'Access references the overriding subprogram,
+> you are introducing a case where a name references an entity which has not
+> been declared yet.  This is something entirely new, and it's going to break
+> more that one compiler (for no good reason).
+
+That is not what I meant at all. I said that F'Access returns the overriding
+subprogram -- I suppose that is the dynamic semantics. F is the
+must-be-overridden subprogram - that is the name resolution. That is precisely
+the meaning of a call to F (as I demonstrated earlier) -- why should F'Access
+not be usable when a call is?
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent