CVS difference for ais/ai-00229.txt

Differences between 1.7 and version 1.8
Log of other versions for file ais/ai-00229.txt

--- ais/ai-00229.txt	2001/06/05 00:03:27	1.7
+++ ais/ai-00229.txt	2001/07/14 00:01:48	1.8
@@ -706,3 +706,228 @@
 So, I guess I'm saying I don't understand your objection to "descendant".
 
 *************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 4, 2001 5:15 PM
+
+> Well, Pascal used it first. But I think it is necessary; we're only talking
+> about library units in that phrase.
+
+Well, I still don't agree with the usage.  Descendant is
+only defined for library units, so you should at least say
+something like, "... or, in the case the generic unit is a library unit,
+within the body of a descendant of that generic unit, then ...
+
+> > If the subprogram denoted by P is declared with a generic unit, and the
+> > expression P'Access occurs within the body of that generic unit or of
+> > a generic unit declared within the immediate scope of the subprogram.
+>
+> This doesn't cover children of generics, which is the problem.
+
+Hmmm....  I guess you are right, if the subprogram is declared within
+a package nested in the generic.  So how about:
+
+    If the subprogram denoted by P is declared within a generic unit,
+    and the expression P'Access occurs within the body of that generic
+    unit, or within the body of a generic unit declared within
+    the declarative region of the generic, then the ultimate ancestor
+    of P shall be declared within the generic unit.
+
+This avoids the problematic use of the term "descendant."
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 4, 2001 8:28 PM
+
+Sigh. This may be a case where I have to yield to "Tucker knows best" :-)
+
+I'd still be a bit concerned that this seems to imply something not there
+(that only uses DIRECTLY within a generic body are affected). But I'll live
+with this (with a suitable AARM note to say that the second phrase is really
+talking about children of this generic).
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 5, 2001 7:45 AM
+
+> The interesting question is whether there is any need to restrict S to the
+> generic body for subprograms declared in the body. I don't think there is
+> for generic sharing purposes (if there is a reason, it would also apply to
+> the new rule), and there can't be any accessibility problems. So I think it
+> is OK to allow S to be declared anywhere in the generic. Thus, we get the
+> following (which replaces the existing rule):
+
+Well, you are the only one interested in generic sharing at this point, so if
+you say it's fine, I suppose I can live with that.  However, during the meeting
+Tuck tried to merge the new rule with the existing one, and we came to the
+conclusion that it was not worth the effort.  I am a bit concerned with the
+notion that we are relaxing an existing rule just because nobody seems to
+remember why it was written that way.
+
+>     If the subprogram denoted by P is declared within a generic unit,
+>     and the expression P'Access occurs within the body of that generic
+>     unit, or within the body of a generic unit declared within
+>     the declarative region of the generic, then the ultimate ancestor
+>     of P shall be declared within the generic unit.
+
+With the above caveat, this wording looks good to me.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 5, 2001 4:11 PM
+
+> However, during the meeting
+> Tuck tried to merge the new rule with the existing one, and we came to the
+> conclusion that it was not worth the effort.
+
+True, but at the meeting, we only considered possible mergings where the
+(original) new rule was left in the same order. The other day, I realized
+that we needed to reorder the rule to merge them, and I'm certain we didn't
+consider that (at least out loud!) at the meeting.
+
+> I am a bit concerned with the notion that we are relaxing an existing rule
+> just because nobody seems to remember why it was written that way.
+
+I know this is one rule that I insisted on, and I'm 95% sure I know why the
+rule is the way it is. I just don't want to assume I know what was going on
+in Tuck's head at the time, so I don't want to write a certainty. Here's why
+the existing rule doesn't allow the access to be declared in the spec:
+
+(Skip over the following unless you care about generic sharing approaches)
+
+As you know, a subprogram declared in a shared generic includes a (hidden)
+parameter which passes the instance data to the subprogram. In order to be
+able to point at subprograms declared in a generic body, an access to
+subprogram type declared in a generic body needs the same (hidden)
+parameter.
+
+(That makes it clear why the original rule should have said subprogram
+declared in a generic, rather than just a subprogram declared in a generic
+body.)
+
+Anyway, an access to subprogram type declared in a generic specification may
+or may not have the hidden parameter. If it does have the hidden parameter,
+then any 'Access of a subprogram not declared in the generic needs a thunk
+to remove the hidden parameter on a call through the access value. 'Accesses
+from inside of the generic do not need a thunk. If it does not have the
+hidden parameter, then any 'Access of a subprogram not declared in the
+generic does not need a thunk, while any 'Access of a subprogram declared in
+the generic does need a thunk. This latter thunk is impossible to build in
+the generic body (because it is shared, and therefore there the only way to
+access the instance data is via a hidden parameter: but we just said we
+can't have any hidden parameter!). It can be built in the instance at
+instantiation time. (Note that access to subprogram types declared outside
+of the generic behave like the second case).
+
+The original rule was designed to allow both of these implementations of
+access to subprograms in the specs. There doesn't seem to be much reason to
+choose either implementation over the other -- the best choice would seem to
+depend on how the end user actually uses the type. And this seems rare
+enough not to lose sleep over.
+
+Anyway, Janus/Ada chooses the first implementation (always having the hidden
+parameter), because it is consistent with other subprograms (and access to
+subprogram types) declared in a generic specification or body and thus is
+what happens "naturally". If indeed I'm the only one who cares about this,
+then there is no reason to restrict this rule further and potentially
+inconvenience users. Moreover, if the more restrictive rule is adopted, it
+has to apply to subprograms in generic specifications as well. This seems
+like too much restriction:
+
+    generic
+    package Pack is
+        procedure Foo;
+        type Acc is access procedure;
+    private
+        V1 : Acc := Foo'Access; -- OK under any rule.
+    end Pack;
+
+    package body Pack is
+	  procedure Bar is ...
+        procedure Foo is ...
+
+	  V2 : Acc := Bar'Access; -- (2)
+        V3 : Acc := Foo'Access; -- (3)
+    end Pack;
+
+(2) is illegal by the existing rule. If Acc is represented without a hidden
+parameter, this needs to be the case for generic sharing implementation. (3)
+would be OK by the Leuven approved wording of the new rule. But that has the
+same problem for a generic sharing implementation as (2). Thus, if the
+Leuven rule stood, Acc would have to be represented with a hidden parameter.
+But if that is the case, there is no need for (2) to be illegal.
+
+Anyway, my point is that both (2) and (3) have to be illegal, or we've
+constrained the implementation of Acc in a sharing implementation. Thus,
+there is no reason for the two rules to be different: it adds nothing except
+complexity. And there is no accessibility reason that they have to be
+different. So they ought to be merged.
+
+The 5% uncertainty comes from the fact that Tuck at one point had in mind a
+bizarre model where the compiler would generate a thunk for every visible
+subprogram in a generic just in case it might be used in a 'Access in the
+body. This would allow (2) and (3) to have different legality, but I can't
+imagine the value of such a rule or implementation: it would generate a lot
+of unused code, adds very little value, and greatly complicates the rule.
+
+> >     If the subprogram denoted by P is declared within a generic unit,
+> >     and the expression P'Access occurs within the body of that generic
+> >     unit, or within the body of a generic unit declared within
+> >     the declarative region of the generic, then the ultimate ancestor
+> >     of P shall be declared within the generic unit.
+>
+> With the above caveat, this wording looks good to me.
+
+Hopefully, I've dispelled the caveat. I assume that you are writing up this
+AI, so I'll leave it to you to summarize the above in a handful of pithy
+sentences in the !discussion section.
+
+*************************************************************
+
+From: Gray, Michael
+Sent: Tuesday, June 12, 2001 3:15 AM
+
+I'm sorry if I'm being stupid, but I don't see how the wording "the expression
+P'Access occurs within the body of that generic unit, or within the body of a
+generic unit declared within the declarative region of the generic" covers the
+case of P'Access occurring within the body of a generic that takes an
+instantiation of the generic (that declares P) as a package parameter.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, June 12, 2001 11:18 AM
+
+I made a typo in my wording, as pointed out by Steve Baird.
+What it should say is:
+
+    If the subprogram denoted by P is declared within a generic unit,
+    and the expression P'Access occurs within the body of that generic
+    unit, or within the body of a generic unit declared within
+    the declarative region of the generic, then the ultimate ancestor
+    of S shall be declared within the generic unit.
+
+I believe this handles the problem, because if P is
+inside a formal package, then it is declared (at least
+implicitly) within the enclosing generic unit, because that
+includes the formal part of the generic.  We require that S
+also be declared within the generic unit, so there is no
+danger of the access value outliving the generic.
+
+I think... ;-)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 12, 2001  5:07 PM
+
+Humm, this is letter for letter identical with the previous version. So I don't
+see any typo here. Unless you made the same typo a second time.
+
+Your explaination seems like a stretch that ought to be mentioned in the AARM,
+as it is less than obvious. But it seems OK to me.
+
+*************************************************************

Questions? Ask the ACAA Technical Agent