CVS difference for ai05s/ai05-0090-1.txt

--- ai05s/ai05-0090-1.txt	2008/02/05 04:17:06	1.1
+++ ai05s/ai05-0090-1.txt	2008/02/05 06:33:09	1.2
@@ -261,3 +261,70 @@
 
 ****************************************************************
 
+From: Edmond Schonberg
+Sent: Monday, February  4, 2008  10:27 PM
+
+> I think there are two confusions here.  First, the operation
+> Other_Prim called at (2) isn't a case of overriding, as there's
+> no inherited operation by that name in my example.  But second,
+> if it were an overriding, then there would be a violation of the
+> rules in 9.1(9.6/2-9.8/2), which disallow having both an overriding
+> primitive and an "implemented by" operation for an inherited  
+> subprogram.
+> So I don't think that the fix for (1) would have any effect on the
+> ambiguity of cases such as (2).
+
+Right, I misread the example, Other_Prim is well-named, and this is  
+definitely (unambiguously?) ambiguous.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February  4, 2008  8:21 PM
+
+> ... Another possibility would be
+> to try and make certain declarations illegal, but that isn't appealing
+> either, as it would introduce illegalities for no particularly good
+> reason (plus it wouldn't work for technical reasons).
+
+Can you explain these "technical reasons"?
+We make it illegal to have an entry or
+protected subprogram that is homographic with the
+prefixed view of an explicit overriding.  Why can't we
+do the same for an explicit non-overriding primitive?
+
+> ...
+> Clearly we need a change to effectively give preference to one of the
+> two operations.  The proposed fix is to prefer the interpretation of
+> the entry (or protected subprogram), and to consider the implicit
+> overriding operation effectively hidden at the point of a selector_name
+> in a prefixed call.  It seems somewhat more natural to prefer the entry
+> or protected subprogram over the implicit overriding subprogram since
+> the former is explicit in the program text (though formulating the
+> rule the other way could also be considered).
+
+I strongly prefer having the entry/protected subprogram
+visible via prefixed notation.  That is what you would
+get in the absence of the interface, and it seems weird
+that the formal parameter names, defaults, etc., would
+suddenly change just because the task type now implements
+an interface.  So I agree with your current solution, and
+would be opposed to the alternate you considered.
+
+> ...In terms of the rules,
+> this is implemented by making the implicit overriding subprogram
+> hidden from all visibility at the point of a selector_name in cases
+> that would otherwise be ambiguous.
+
+Do we really need to use the term "hidden from all visibility" here?
+I think all you need to do is have 4.1.3(9.2) include a rule
+that disallows referring to a primitive subprogram that is implemented
+by an entry or protected subprogram.  Remember that 4.1.3(9.2)
+is all considered "Name Resolution" so disallowing something is
+effectively creating an overload resolution rule.  Hiding from
+"all visibility" seems like overkill, and is probably exactly
+what we *don't* want to do, since we still want to be able to
+refer to the implicitly declared primitive using "unprefixed"
+subprogram call notation.
+
+****************************************************************