CVS difference for ais/ai-00345.txt

Differences between 1.9 and version 1.10
Log of other versions for file ais/ai-00345.txt

--- ais/ai-00345.txt	2004/02/04 00:51:13	1.9
+++ ais/ai-00345.txt	2004/02/06 05:01:48	1.10
@@ -46,7 +46,7 @@
 !wording
 
 NOTE: This presumes AI-251 ("normal" interface types) and AI-252
-("object.operation" notation).  We will identify where we are referring to
+("object.operation" notation). We will identify where we are referring to
 AI-251 or AI-252 wording.
 
 Modify 3.4(4):
@@ -3036,6 +3036,693 @@
 descriptors, entry index, etc., could be passed separately.
 The "primary" parameters don't change upon requeue, whereas
 the auxiliary parameters typically do.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Tuesday, January 27, 2004  9:28 AM
+
+>I presume most other vendors have solved this somehow.
+>I don't think we should bless a restricted requeue (despite
+>Robert Eachus' comment).
+>
+>
+I didn't say we should bless them.  But from Randy's description the
+problem isn't with all requeues, just with calls to requeue where the
+original task declaration is not visible and there are defaulted or
+hidden parameters.  If I understand correctly, the workaround is to add
+an "unnecessary" with clause.  (In fact Randy might want to investigate
+whether he can add a dependence on the unit containing task declaration
+instead of just giving up.)   But if the reality is that in most cases
+such an extra dependence is not necessary, I prefer the solution of
+"forcing" the user to add it when necessary instead of adding it in lots
+of unnecessary cases.
+
+But in any case, I have trouble visualizing a program that would run
+into the problem.  So I certainly think that Randy's approach of waiting
+until a customer runs into it makes sense.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, January 27, 2004  4:14 AM
+
+> Comments, flames, etc., are encouraged.
+
+This version looks much better than the previous one for all the reasons
+that Randy mentions (and I would add: much less syntax invention and
+therefore less opportunities to quarrel about the syntax).
+
+One thing that I don't like at all is the notion of integrating entry
+families into the mix.  It complicates the language description, it
+complicates the implementation, and entry families are sufficiently
+marginal that you can write the wrapper yourselves if you absolutely
+need to.
+
+Wearing my implementer's hat for a minute, the views of subprograms
+introduced by AI 252 (where the first parameter is omitted) are quite
+complicated for us to represent.  Actually, I know how to represent
+them, but I don't know how to do this efficiently from the standpoint of
+the compilation process.  Adding yet another view to the mix, where the
+first two parameters are omitted, is going to make my life considerably
+more complicated for little user benefit.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 27, 2004  7:35 AM
+
+> ...
+> One thing that I don't like at all is the notion of integrating entry
+> families into the mix.  It complicates the language description, it
+> complicates the implementation, and entry families are sufficiently
+> marginal that you can write the wrapper yourselves if you absolutely
+> need to.
+
+Yes, I agree that entry families don't fit cleanly into
+the picture.  I thought I ought to try to work them out,
+but all along the way I felt like this might not be
+worth the effort.  Your point about creating a wrapper
+is a good one.  To preserve the ability to use selective
+entry calls, I suppose it might even be possible to
+"wrap" the entry family with a "regular" entry, so long as
+you were willing to have the entry index also appear as an
+additional (dummy) parameter to the entry family, and didn't
+mind it coming last in the wrapper, as follows:
+
+    entry Family(for Prio in Priority_Type)(X : Integer; Y : out Integer;
+      Dummy_Prio : Priority_Type := Default_Prio) when Prio > Min_Prio is
+    begin
+        ...
+    end Family;
+
+    entry Family_Wrapper(X : Integer; Y : out Integer;
+      Prio: Priority_Type) when True is
+    begin
+	requeue Family(Prio) with abort;
+    end Family_Wrapper;
+
+If we go this route, it might deserve a note in the RM to
+identify this (somewhat non-obvious ;-) approach to the user.
+
+Interestingly, while thinking about handling entry families,
+I had concluded it would probably be easier for the implementation
+if the family index was the last parameter rather than the second parameter
+in the "equivalent" primitive subprogram, but I didn't have
+the nerve to suggest that...
+
+I suppose we could make the above user-written wrapper a bit more elegant by
+relaxing the rules for requeue, so that rather than an all or none
+match of parameters, you could requeue on any new entry that had no
+more parameters than the original entry, and whose profile
+conformed with the original entry for as many parameters
+as the new entry had.  (This relaxation would be essentially free
+in our implementation, but of course it might be painful
+for others.)
+
+> Wearing my implementer's hat for a minute, the views of subprograms
+> introduced by AI 252 (where the first parameter is omitted) are quite
+> complicated for us to represent.  Actually, I know how to represent
+> them, but I don't know how to do this efficiently from the standpoint of
+> the compilation process.  Adding yet another view to the mix, where the
+> first two parameters are omitted, is going to make my life considerably
+> more complicated for little user benefit.
+
+I hear you...
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, January 27, 2004  12:38 PM
+
+Tuck wrote:
+> Interestingly, while thinking about handling entry families,
+> I had concluded it would probably be easier for the implementation
+> if the family index was the last parameter rather than the second parameter
+> in the "equivalent" primitive subprogram, but I didn't have
+> the nerve to suggest that...
+
+Good instinct not to suggest it ;-)  I agree with Pascal that the
+business of matching for entry families is too much to stomach.
+
+> I suppose we could make the above user-written wrapper a bit more elegant by
+> relaxing the rules for requeue, so that rather than an all or none
+> match of parameters, you could requeue on any new entry that had no
+> more parameters than the original entry, and whose profile
+> conformed with the original entry for as many parameters
+> as the new entry had.  (This relaxation would be essentially free
+> in our implementation, but of course it might be painful
+> for others.)
+
+That also sounds to me like too much extra language complexity
+for not enough benefit.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2004  4:02 PM
+
+Interesting. I don't really care either way, but I don't see any particular
+difference between wrapping entries and entry families (other than that the
+latter is new, while you already have to do the former). Indeed, for
+protected entry calls, we already pass the family value as the second
+parameter, so this would map exactly to what we already do. (Which I doubt
+would make any actual difference in the implementation of the wrapper.)
+
+I don't believe Tucker is proposing anything other than how you could call
+them thru an interface -- he's not proposing to allow such calls directly.
+So, once the wrapper is generated, there is no further cost - the actual
+calls are "normal" procedure calls.
+
+All-in-all, I think Pascal's concern is off-base; unlike AI-252 views, this
+special view of an entry family exists in only one place: matching of
+interface routines to entities privitive on the type. So I don't see any
+need for them to muck up the rest of the compiler.
+
+There may be other good reasons to not bother (the extra language wording is
+an obvious one), but I don't think implementation issues are signficantly
+different than that for other entries.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 27, 2004  4:16 PM
+
+I have suggested yet another (small ;-) change to the
+syntax of "normal" interfaces.  In the example
+I constructed, it was too weird when one interface
+was derived from another to have the first ancestor
+interface name immediately follow the word "interface."
+For lack of a better idea, I have inserted the word "and":
+
+     type Queue is
+       limited interface and Protected_Interface;
+
+
+I would still rather see the word "new" appear for interfaces
+derived from other ancestors, but this is perhaps an alternative
+which reads reasonably well.  For the record, I would still prefer:
+
+     type Queue is new Protected_Interface [and ...];
+or
+     interface Queue [is new Protected_Interface [and ...]];
+
+The second form emphasizes that these beasts are fundamentally
+*interfaces*, and their use as types (e.g. of objects) is
+very restricted.  (Yeah, yeah, I know I am fighting an up-hill
+battle. ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2004  5:24 PM
+
+Tucker said:
+...
+> I would still rather see the word "new" appear for interfaces
+> derived from other ancestors, but this is perhaps an alternative
+> which reads reasonably well.
+
+I still think that saying that interfaces are derived types, for any reason
+(even brevity of RM wording) is a mistake. The only property that they share
+with derived types is the inheritance of operations, and even that isn't
+quite the same (because you can get homographs from several interfaces, and
+those must not disappear as homographs normally do).
+
+Each interface is fundamentally a new type, potentially with operations
+inherited from a number of other interfaces. For this, I much prefer the old
+"implements" terminology, because it makes clear what is happening. These
+guys don't have "ancestors". They don't "derive" anything. They are a new
+type that can in some circumstances be used in place of some other type.
+That's it.
+
+Anything that makes one interface more important than another (or look that
+way) is fundamentally wrong.
+
+> For the record, I would still prefer:
+>
+>      type Queue is new Protected_Interface [and ...];
+
+How do you tell a new interface from a new concrete type derived from an
+interface? They both have the same syntax if the above is adopted.
+
+I had wanted something like:
+    type Concrete_Type is tagged and Some_Interface ...
+for new concrete types, but we decided (especially because of generic
+contract issues) that derived types had to always make concrete types, and
+thus the above is not needed.
+
+Nothing has changed about that, so give it up, OK??
+
+> or
+>      interface Queue [is new Protected_Interface [and ...]];
+>
+> The second form emphasizes that these beasts are fundamentally
+> *interfaces*, and their use as types (e.g. of objects) is
+> very restricted.  (Yeah, yeah, I know I am fighting an up-hill
+> battle. ;-)
+
+All I'll say here is "yuck". Especially as this form would require that the
+interfaces are program units (everything declared this way is currently a
+program unit). That means that operations would have to be declared in the
+scope of the interface, much like protected types.
+(OK, I couldn't resist saying more. It's still "yuck".)
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, January 28, 2004  4:24 AM
+
+Randy protested:
+
+> All-in-all, I think Pascal's concern is off-base; unlike
+> AI-252 views, this special view of an entry family exists in
+> only one place: matching of interface routines to entities
+> privitive on the type. So I don't see any need for them to
+> muck up the rest of the compiler.
+
+Beware of giving advice about other people's implementation!
+
+My understanding is that, as part of the grand unification between OO
+and real-time, we are trying to do the reverse of AI 252, i.e. make it
+possible to call an entry using a procedure-like syntax. Let me take an
+example (I hope I am getting the syntax right):
+
+	type Itf is interface;
+	procedure E (I : Itf; B : Boolean; X : Integer);
+
+	task type Tsk is new Itf with
+	    entry E (Boolean) (X : Integer);
+	end Tsk;
+
+	T : Tsk;
+
+Now obviously you can write a call using the Ada 83+95 syntax:
+
+	T.E (False) (3);
+
+But I believe that (assuming the proper visibility) you are also able to
+write:
+
+	E (T, False, 3); -- Legal?  I think so.
+
+Now it's not only a matter of matching for overriding purposes.  In our
+implementation we need a piece of Diana that describes the subprogram
+that is invoked by this call.  This subprogram has the profile:
+
+	procedure E (I : T; B : Boolean; X : Integer);
+
+but it is actually a view of the entry T.E.  Consequently, it must be
+tied to T.E in some way, to indicate that it's just going to execute the
+same code, with proper parameter massaging.
+
+This in and of itself is not easy.  I don't want to think of what
+happens when Tsk is passed to a generic as an actual for a formal type
+which is derived from Itf.  We already go through numerous hoops to tie
+the subprograms of the formal type to those of the actual type, and AI
+252 is going to make things worse.  I'd rather not add insult to injury
+by putting entry families into the mix.
+
+> There may be other good reasons to not bother (the extra
+> language wording is an obvious one), but I don't think
+> implementation issues are signficantly different than that
+> for other entries.
+
+Not only does this complicate the wording, but it is also very
+arbitrary.  That the first parameter becomes the prefix, as in AI 252,
+seems rather natural.  That the entry index becomes the 2nd parameter is
+not at all intuitive to me.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, January 28, 2004  4:27 AM
+
+Tucker tried to sneak in a syntax change:
+
+> NOTE: I have suggested yet another (small ;-) change to the
+> syntax of "normal" interfaces.  In the example I constructed,
+> it was too weird when one interface was derived from another
+> to have the first ancestor interface name immediately follow
+> the word "interface." For lack of a better idea, I have
+> inserted the word "and":
+>
+>      type Queue is
+>        limited interface and Protected_Interface;
+>
+> I would still rather see the word "new" appear for interfaces
+
+I realize that you have never been very satisfied with the syntax for
+interfaces, but beware that, by periodically reopening this issue, you
+are likely to cause lengthy discussions about the syntax that lead
+nowhere, and could well kill the whole proposal.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 28, 2004  9:25 AM
+
+> But I believe that (assuming the proper visibility) you are also able to
+> write:
+>
+>         E (T, False, 3); -- Legal?  I think so.
+
+I talked about this, but didn't include it in the proposal.  In the
+Version 3/4 AI-345 proposal, you could only do this via a dispatching
+call through an interface.  You wouldn't be able to do it directly.
+In version 5, the idea of implementing primitives via entry families
+was dropped.
+
+Note that the idea of directly calling entries using "infix"
+notation has not appeared in any of the versions of AI-345.  It doesn't
+seem to add sufficient benefit to justify the wording changes,
+and in any case, it seems relatively separable from the current
+proposal about implementing interfaces.
+
+> ...
+> Not only does this complicate the wording, but it is also very
+> arbitrary.  That the first parameter becomes the prefix, as in AI 252,
+> seems rather natural.  That the entry index becomes the 2nd parameter is
+> not at all intuitive to me.
+
+Yes, I agree making it the second parameter did feel a bit arbitrary.
+As I noted, in our implementation, it would be easier to handle if
+it were the last parameter.  But despite Randy's view, I think it
+makes sense to drop the idea of entry families implementing primitives.
+Let's focus on what is actually written in version 5 of AI-345, and
+see what people think of that.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 28, 2004  12:34 PM
+
+> Randy protested:
+>
+> > All-in-all, I think Pascal's concern is off-base; unlike
+> > AI-252 views, this special view of an entry family exists in
+> > only one place: matching of interface routines to entities
+> > privitive on the type. So I don't see any need for them to
+> > muck up the rest of the compiler.
+>
+> Beware of giving advice about other people's implementation!
+
+I totally agree. But...
+
+> My understanding is that, as part of the grand unification between OO
+> and real-time, we are trying to do the reverse of AI 252, i.e. make it
+> possible to call an entry using a procedure-like syntax.
+
+...now you're discussing the implementation difficulty of a feature that is
+not in the proposal, and (as Tucker mentioned) is not necessary in any way
+for the proposal.
+
+Using the implementation difficulty of something that isn't even proposed to
+object to something that is proposed should not be considered a valid
+approach!!
+
+While I don't see getting families integrated into this model as critical, I
+do think it would be valuable if possible. That's especially true for
+protected entry bodies, where the family index is really just an extra
+parameter to the entry that can be used in the barrier. I've used them that
+way on several occassions, and I certainly would not consider them "rare".
+(Task families on the other hand, are hardly ever used.) Mapping protected
+entry bodies with a family index to a subprogram with two extra parameters
+seems exactly natural - that's really what they are, and all of the extra
+'()'s and '.'s just get in the way of understanding what is going on.
+
+I cannot imagine why anyone would think (implementation issues aside) that
+the entry family of a protected entry would be anything other than the
+second parameter. The call (Pascal's example using protected entries)
+
+	P.E (False) (3);
+
+certainly makes sense to map to:
+
+	E (P, False, 3);
+
+when P is an interface'class. I don't see any logic behind mapping it to
+anything else:
+      E (P, 3, False);
+reorders the parameters from their original order.
+
+I'm a bit dismayed that Tucker decided to redo the AI to remove the family
+stuff at the first sign of discomfort; in order to properly discuss these
+issues, they need to be in the proposal. Otherwise, they either do not come
+up at all, or we have a very muddled discussion with no concrete idea what
+it is that we're talking about.
+
+I'm especially concerned that we haven't heard from the real-time community
+on this proposal at all. This is supposed to be for them (at least in part),
+and it would make sense to find out what they think rather than killing off
+things at the first sign of trouble...
+
+(I have not posted "version 5" because it is unnecessary to do so; it only
+deletes stuff without  much justification, which in this case is trivial to
+do. We're not going to adopt this AI in March anyway, so I don't see any
+reason to rush here. We can make the trivial change of deleting the family
+stuff if that is the decision at the meeting.)
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, January 28, 2004  1:14 PM
+
+Randy wrote:
+> All-in-all, I think Pascal's concern is off-base; unlike AI-252 views, this
+> special view of an entry family exists in only one place: matching of
+> interface routines to entities privitive on the type. So I don't see any
+> need for them to muck up the rest of the compiler.
+>
+> There may be other good reasons to not bother (the extra language wording is
+> an obvious one), but I don't think implementation issues are signficantly
+> different than that for other entries.
+
+My concern is mainly with the additional rule complexity for insufficient
+benefit.  Implementation isn't so much of a concern, though this does seem
+to complicate resolution as well.  It would be useful to know the perspective
+of real-time users about how important this capability is.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, January 29, 2004  3:38 AM
+
+Tuck clarified:
+
+> >         E (T, False, 3); -- Legal?  I think so.
+>
+> I talked about this, but didn't include it in the proposal.
+> In the Version 3/4 AI-345 proposal, you could only do this
+> via a dispatching
+> call through an interface.  You wouldn't be able to do it directly...
+>
+> Note that the idea of directly calling entries using "infix"
+> notation has not appeared in any of the versions of AI-345.
+> It doesn't seem to add sufficient benefit to justify the
+> wording changes, and in any case, it seems relatively
+> separable from the current proposal about implementing interfaces.
+
+I am happy to discuss this issue separately, but I think it is required
+for consistency with the rest of the proposal.  Consider an example
+without entry families:
+
+	type Itf is limited interface;
+	procedure E (I : Itf; X : Integer);
+
+	task type Tsk is new Itf with
+	    entry E (X : Integer);
+	end Tsk;
+
+	T : Tsk;
+
+I would find it curious that the following dispatching call be legal:
+
+	E (Itf'Class (T), 3);
+
+but not the following non-dispatching call:
+
+	E (T, 3);
+
+After all, in Ada we try to favor static binding whenever possible, so
+it would be strange to force dynamic binding in this particular
+situation.
+
+Furthermore, I believe that the implementation complexity is mostly
+there anyway because of, lo and behold, generics.  Augment the previous
+example with:
+
+	generic
+	    type Formal is new Itf with private;
+	procedure P (X : Formal);
+
+	procedure P (X : Formal) is
+	begin
+	    E (X, 3);
+	end P;
+
+	procedure I is P (Tsk);
+
+In order to generate the code for the body of instantiation I you need
+some mechanism to tie the (subprogram) call on E to the entry Tsk.E
+(including parameter massaging, internal representation in the symbol
+table/Diana tree/whatever, etc.).  So the only implementation complexity
+that is saved by not allowing infix calls to entries is the one related
+to name resolution (because you don't redo name resolution in generic
+instantiations).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 29, 2004  1:09 PM
+
+> I am happy to discuss this issue separately, but I think it is required
+> for consistency with the rest of the proposal.  ...
+
+You make good points.  I don't think it is essential, but I agree
+it makes sense to have the "language design principle" that
+what you can do using dynamic binding you should be able
+to do with a statically bound call, with essentially the same syntax.
+
+This will actually simplify the AI-345 wording a bit in some places,
+while probably requiring a bit more wording elsewhere.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 29, 2004  1:48 PM
+
+> This will actually simplify the AI-345 wording a bit in some places,
+> while probably requiring a bit more wording elsewhere.
+
+Oops, I got myself confused.  The above principle does *not*
+require that we make *all* entries callable using "infix"
+notation (by "infix" I really mean putting the task or
+protected object inside the parenthese, rather than out
+front).  The way AI-345 is written, the task or protected
+type inherits a primitive subprogram from the interface,
+and then at that point it is implicitly *implemented* by an
+entry that conforms to it.  It can still be overridden explicitly by
+a "normal" primitive subprogram.  And entries that *don't*
+conform to some primitive inherited from the interface don't
+"magically" become visible in the scope enclosing the
+task/protected type.
+
+[One partial analogy I can think of is the "=" operator for type
+extensions, which is implicitly implemented to call the parent "="
+and the predefined "=" on the components of the extension part,
+but which can be overridden if desired.]
+
+So really all that we need to allow is for these inherited
+primitive subprograms (that happen to be implemented by
+an entry or protected subprogram) to be called in the
+"usual" way, i.e. all parameters inside the parentheses.
+Which they will be unless we go out of our way to make it illegal.
+We *don't* need to make other entries or protected subprograms
+callable in this way, and I'm not convinced it is worth the
+visibility fiddling that would be required to do so.
+
+As far as the effect on AI-345, no change is needed to
+allow inherited primitives to be called in the "usual" way,
+presuming it is clear that they aren't "abstract" once
+they have been implemented by an entry or protected subprogram.
+I think the only change would be to the wording after 9.7.2(3)
+for the "procedure_or_entry_call" construct which should also
+allow the procedure to be a primitive of a task or protected type
+so long as it is implemented by an entry.
+
+So I guess I am back to agreeing with Randy that the real issue
+remains generating wrappers for inherited primitives that are
+"implemented" by entries or proteced subprograms.  There
+should be no additional compiler front end work, I don't think,
+because the inherited primitives are presumably already in the
+symbol table due to the usual type derivation rules.  If we want
+to allow primitives to be implemented with an entry family, then
+that wouldn't suddenly *add* all entry family names to the enclosing
+scope.  It would simply mean that an inherited primitive, which
+is already in the enclosing scope, now has an implicit body which
+calls a member of the entry family.
+
+On the other hand, if we wanted to allow *all* entries and
+protected subprograms to be called in "infix" notation,
+that would be a different matter, and I don't think I would
+recommend that, and in that case, the entry family situation
+would be harder to stomach.
+
+Ultimately, I don't think the decision on entry families
+is that important, since you can write your own wrappers,
+which could be a single entry "wrapper" if need be.  Again, we
+could use some guidance from the real-time folks here...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 29, 2004  1:59 PM
+
+Pascal said:
+
+> > Note that the idea of directly calling entries using "infix"
+> > notation has not appeared in any of the versions of AI-345.
+> > It doesn't seem to add sufficient benefit to justify the
+> > wording changes, and in any case, it seems relatively
+> > separable from the current proposal about implementing interfaces.
+>
+> I am happy to discuss this issue separately, but I think it is required
+> for consistency with the rest of the proposal.
+...
+> After all, in Ada we try to favor static binding whenever possible, so
+> it would be strange to force dynamic binding in this particular
+> situation.
+
+Fair enough, but it wasn't what was proposed.
+
+> Furthermore, I believe that the implementation complexity is mostly
+> there anyway because of, lo and behold, generics.  Augment the previous
+> example with:
+>
+> 	generic
+> 	    type Formal is new Itf with private;
+> 	procedure P (X : Formal);
+>
+> 	procedure P (X : Formal) is
+> 	begin
+> 	    E (X, 3);
+> 	end P;
+>
+> 	procedure I is P (Tsk);
+>
+> In order to generate the code for the body of instantiation I you need
+> some mechanism to tie the (subprogram) call on E to the entry Tsk.E
+> (including parameter massaging, internal representation in the symbol
+> table/Diana tree/whatever, etc.).  So the only implementation complexity
+> that is saved by not allowing infix calls to entries is the one related
+> to name resolution (because you don't redo name resolution in generic
+> instantiations).
+
+I don't see this. Any call thru an interface is (logically at least)
+equivalent to a dispatching call. The compiler can do the lookup at
+compile-time, but it's still (logically) dispatching. That means that what
+this calls is the wrapper procedure; it's not a direct call to the entry.
+Certainly the needed wrapper exists, and you know where to find it. You're
+always welcome to work harder if you want, but I don't see any reason to
+treat this call any different than any other subprogram call.
+
+(Not to mention that there is no such thing as a statically bound call in a
+generic sharing implementation. All calls are dynamically dispatching, the
+only difference is where the tag comes from [it comes from the actual type
+if the call would be statically bound]. And that implementation always works
+for any compiler - if it's too hard to statically bind the call - and I
+think that it is in this case - dispatch through the tag, being careful to
+use the right tag.)
+
+Ultimately, all of these questions boil down to how much work we're going to
+make the user do so we (implementers) don't have to. The main reason that
+I'm in favor of including support for entry families is that the work-around
+(as described by Tucker) requires an extra entry and a dummy parameter on
+the original entry -- and that hardly is going to increase readability and
+correctness of Ada programs! What I don't know is whether protected entry
+families are used as much in practice as they appear to be in theory. If
+they are, we ought to support them properly here.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent