CVS difference for ai05s/ai05-0090-1.txt
--- ai05s/ai05-0090-1.txt 2008/03/07 06:15:20 1.3
+++ ai05s/ai05-0090-1.txt 2008/06/14 05:56:15 1.4
@@ -1,6 +1,8 @@
-!standard 4.1.3(8-9.2/2) 08-02-04 AI05-0090-1/01
+!standard 4.1.3(8-9.2/2) 08-06-13 AI05-0090-1/02
!standard 9.1(9.2/3)
+!standard 9.1(9.5/2)
!standard 9.4(11.1/3)
+!standard 9.4(11.4/2)
!class binding interpretation 08-02-04
!status work item 08-02-04
!status received 08-02-04
@@ -12,9 +14,9 @@
!summary
A selected_component whose selector_name can denote the (implicit) overriding
-of an inherited primitive of a synchronized type as well as an entry or
-protected subprogram of that type that implements the inherited primitive
-is not ambiguous, and resolves to the entry (or protected subprogram).
+of an inherited primitive of a synchronized type, as well as denote an entry
+(or protected subprogram) that implements the inherited primitive, is not
+ambiguous, and resolves to the entry (or protected subprogram).
!question
@@ -29,12 +31,17 @@
task type Task_Type is new Synch_Interface with
entry Prim;
entry Other_Prim;
+ entry Yet_Another_Op;
end Task_Type;
+ package Nested_Pkg is
+ procedure Yet_Another_Op (Tsk : in out Task_Type);
+ end Nested_Pkg;
+
-- Implicit declaration of overriding primitive (as per AI05-0042):
-- procedure Prim (S : in out Task_Type);
- procedure Other_Prim (Tsk : in out Task_Type);
+ procedure Other_Prim (Tsk : in out Task_Type); -- Legal? (No.)
end Synch_Pkg;
@@ -42,22 +49,29 @@
T : Synch_Pkg.Task_Type;
+use Synch_Pkg.Nested_Pkg;
+
...
+
+T.Prim; -- (1) Ambiguous? (No.)
+
+T.Other_Prim; -- (2) Ambiguous? (The procedure declaration is illegal.)
-T.Prim; -- (1) Ambiguous? (No.)
+T.Yet_Another_Op; -- (2) Ambiguous? (Yes.)
-T.Other_Prim; -- (2) Ambiguous? (Yes.)
The call to Prim at (1) using prefixed notation appears to be ambiguous,
because the selector could denote either the entry Prim, or the implicitly
declared overriding of the primitive inherited from Synch_Interface (which
-is defined to exist by AI05-0042). This is clearly not what is intended.
+is defined to exist by AI05-0042). This is clearly not what is intended.
Also, there can be subprograms with prefixed views that are homographic
-with an entry of the task type, such as Other_Prim at (1), but that means
-that calls using prefixed notation are ambiguous, because the call could
-be either to the subprogram or to the entry (by 4.1.3 paragraphs 8-9.2/2).
-Are such calls intended to be ambiguous? (Yes.)
+with an entry of the task type, such as procedures Yet_Another_Op and
+Other_Prim, but that means that calls using prefixed notation are
+ambiguous, because the call could be either to the subprogram or to the
+entry (by 4.1.3 paragraphs 8-9.2/2). Are such calls intended to be
+ambiguous? (Yes, but in the case of Other_Prim the procedure declaration
+is already illegal by 9.1(9.5/2).)
!recommendation
@@ -65,94 +79,118 @@
!wording
-[Note: This AI has not been discussed yet, so it's probably premature to
-draft any wording, but here's a suggestion of how this might be fixed.]
+Add in 4.1.3(9.2/2), following the sentence that starts "The designator
+of the subprogram shall not be the same...":
-To address the issue of preventing the ambiguity between the implicit
-overriding declared for an inherited interface operation and an entry
-or protected subprogram that implements it, one possibility would be
-to introduce some kind of preference rule, presumably in 4.1.3. Another
-approach would be to say that one or the other declarations is hidden
-from all visibility at the point of a selector_name (excluding the
-expanded name case).
-
-Here's possible wording based on the latter, the intent of which is
-to make the implicitly declared overriding subprogram hidden in the
-context of the selector of a selected name that has a prefix of the
-synchronized type:
-
-In 8.3, add an additional bullet after paragraph 20.1/2:
-
- The declaration of an implicit subprogram that overrides a subprogram
- inherited by a task or protected type from a synchronized interface and
- implemented by an entry or protected subprogram (as defined 9.1(9.2/3)
- and 9.4(11.1/3)) is hidden from all visibility at the point of a
- selector_name in a selected_component whose prefix resolves to an
- object or value of the type.
-
-[Or perhaps the preference should really be the other way around, with
-with the entry or protected subprogram being hidden from all visibility in
-a prefixed call:
-
- The declaration of an entry or protected subprogram that implements
- a subprogram inherited from a progenitor type is hidden from all
- visibility at the point of a selector_name in a selected_component
- whose prefix resolves to an object or value of the parent task or
- protected type.
-]
+The subprogram shall not be an implicitly declared primitive operation
+of type T that overrides an inherited subprogram implemented by an entry
+or protected subprogram visible at the point of the selected component.
+
+Add this AARM paragraph following 4.1.3(9.2/2):
+
+AARM Discussion: The part of the rule that excludes a primitive overriding
+subprogram as a selector applies only to the wrapper subprogram that is
+implicitly declared to override a subprogram inherited from a synchronized
+interface that is implemented by an operation of a task or protected type
+(see 9.1 and 9.4, as amended by AI05-0042). We don't want
+calls that use a prefixed view to be ambiguous between the wrapper
+subprogram and the implementing entry or protected operation. Note that
+it is illegal to declare an explicit primitive that has a prefixed view
+that is homographic with one of the type's operations. [Editor's musing:
+Probably should mention that it is possible for a class-wide operation
+to be ambiguous with such a prefix call, and in that case the prefix form
+cannot be used. So I'd suggest something like: "type's operations{, so
+in normal cases it isn't possible to have an ambiguity in a prefix call.
+However, a class-wide operation of an ancestor type and declared in the
+same declarative list with the ancestor type is also considered, and that
+can make a call ambiguous.]
+
+Replace 9.1(9.5/2):
+
+The prefixed view profile of an explicitly declared primitive subprogram
+of a tagged task type shall not be type conformant with any entry of the
+task type, if the first parameter of the subprogram is of the task type
+or is an access parameter designating the task type.
+
+with the following:
+
+The prefixed view profile of an explicitly declared primitive subprogram
+of a tagged task type shall not be type conformant with any entry of the
+task type, if the subprogram has the same defining_identifier as the entry
+and the first parameter of the subprogram is of the task type or is
+an access parameter designating the task type.
+
+
+Replace 9.4(11.4/2):
+
+The prefixed view profile of an explicitly declared primitive subprogram
+of a tagged protected type shall not be type conformant with any protected
+operation of the protected type, if the first parameter of the subprogram
+is of the protected type or is an access parameter designating the protected
+type.
+
+with the following:
+
+The prefixed view profile of an explicitly declared primitive subprogram
+of a tagged protected type shall not be type conformant with any protected
+operation of the protected type, if the subprogram has the same
+defining_identifier or defining_operator_symbol as the protected operation
+and the first parameter of the subprogram is of the protected type or is
+an access parameter designating the protected type.
!discussion
-The ambiguity in the case of the call at (2), to a synchronized operation
+The ambiguity in the case of the call at (3), to a synchronized operation
declared within a task or protected type that is a homograph of the prefixed
-view of an explicit subprogram seems unavoidable. We could try to define
-some preference rule similar to that for components that conflict
-with prefixed views, as is done in 4.1.3(9.2/2), to select the entry
-or protected subprogram interpretation, but that seems like a bad idea.
+view of an explicit subprogram, seems unavoidable. We could try to define
+some preference rule similar to that for components that conflict with
+prefixed views, as is done in 4.1.3(9.2/2), to select the entry or protected
+subprogram interpretation, but that seems like a bad idea.
For one thing, unlike a component, such operations are overloadable.
Giving preference to either the synchronized operation or the subprogram
with the homographic prefixed view could too easily result in confusion
-as to which operation was being named. 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). So it seems better
-to leave the language as it is, with the potential for ambiguities, but
-ones that can generally be avoided either by changing names, using normal
-function call notation rather than a prefixed view for calls to the implicit
-overriding subprogram, or by using named notation on calls to distinguish
-which operation is wanted. Thus, the answer to this part of the question
-is really just a confirmation.
-
-The first part of the question (concerning the call at (1)) involves
-a similar case, but one where we definitely want the call to resolve
-to one of the two available interpretations, since otherwise prefixed
-notation can't be used at all.
+as to which operation was being named. So it's best to leave the language
+as it is, with the potential for ambiguities, but ones that can generally
+be avoided either using normal function call notation rather than a
+prefixed view, or by using named notation on calls.
+
+In the case of the entry and primitive procedure named Other_Prim in the
+question, the declaration of the procedure is illegal by the existing rule
+in 9.1(9.5/2), which disallows explicitly declared primitives that have a
+prefixed view that is homographic with an entry of the type. (A similar rule
+exists in 9.4(11.4/2), covering the case of protected operations.) One
+oversight that was noted, though, is that those rules need to mention that
+the conflicting subprogram must have the same defining_identifier (or
+defining_operator_symbol) as the entry or protected subprogram, so those
+paragraphs are corrected to reflect that.
+
+The first part of the question (concerning the call at (1)) involves a
+similar case, but one where we definitely want the call to resolve to one
+of the two available interpretations, since otherwise prefixed notation
+can't be used at all.
The situation is that of a subprogram inherited from a synchronized
interface that is implemented by an entry or protected subprogram.
By AI05-0042, such an inherited subprogram is defined to be overridden
by an implicit subprogram (see the last sentence of 9.1(9.2/3) and
9.4(11.1/3)). The problem is that a call to the implicitly declared
-overriding subprogram using prefixed notation will be ambiguous, because
-it could also be interpreted as a call to the entry or protected
-subprogram that implements the inherited subprogram. In some cases
+overriding subprogram using prefixed notation will be ambiguous,
+because it could also be interpreted as a call to the entry or protected
+subprogram that implements the inherited subprogram. In some cases
such a call could be disambiguated using named associations for the
-parameters, but having to futz with parameter names to disambiguate
-calls would only be an ugly workaround and an inconvenience for users.
+parameters, but having to use parameter names to disambiguate calls
+would only be an ugly workaround and an inconvenience for users.
-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
+Clearly a change is needed to effectively give preference to one of
+the two operations. This is accomplished by choosing the the entry
+(or protected subprogram), and removing the interpretation of the
+implicit overriding operation at the point of a selector_name in
+a prefixed context. It makes sense to resolve in favor of 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). 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.
+the former is explicit in the program text. This preference rule,
+added to 4.1.3(9.2/2), is similar to the rule in that same paragraph
+for preferring a component over a subprogram with the same name.
-
--!corrigendum 4.1.3(8-9.2/2)
@@ -477,5 +515,97 @@
to the components of a record type when the prefix of the
selected component is record_type'Class. No dispatching is
involved.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 14, 2008 12:37 AM
+
+...
+> Consider the following example:
+>
+> package Synch_Pkg is
+>
+> type Synch_Interface is synchronized interface;
+>
+> procedure Prim (S : in out Synch_Interface) is abstract;
+>
+> task type Task_Type is new Synch_Interface with
+> entry Prim;
+> entry Other_Prim;
+> entry Yet_Another_Op;
+> end Task_Type;
+>
+> package Nested_Pkg is
+> procedure Yet_Another_Op (Tsk : in out Task_Type);
+> end Nested_Pkg;
+>
+> -- Implicit declaration of overriding primitive (as per AI05-0042):
+> -- procedure Prim (S : in out Task_Type);
+>
+> procedure Other_Prim (Tsk : in out Task_Type); -- Legal? (No.)
+>
+> end Synch_Pkg;
+>
+> ...
+>
+> T : Synch_Pkg.Task_Type;
+>
+> use Synch_Pkg.Nested_Pkg;
+...
+
+> T.Yet_Another_Op; -- (2) Ambiguous? (Yes.)
+
+I don't understand this. The operation in the nested package is not eligible
+to be a prefixed view, as it is not "declared *immediately* within the
+declarative region where an ancestor of T is declared". The use clause is
+irrelevant, that would make the operation directly visible as:
+ Yet_Another_Op(T);
+but that's not relevant here.
+
+I think the only way to get an ambiguity is with a class-wide operation (which
+could be in an ancestor package):
+
+ procedure Yet_Another_Op (Obj : in out Synch_Interface'Class);
+
+Thus, the example of the question would probably be better written as:
+
+package Synch_Pkg is
+
+ type Synch_Interface is synchronized interface;
+
+ procedure Prim (S : in out Synch_Interface) is abstract;
+
+ procedure Yet_Another_Op (Obj : in out Synch_Inteface'Class);
+
+end Synch_Pkg;
+
+with Synch_Pkg;
+package Task_Pkg is
+ task type Task_Type is new Synch_Pkg.Synch_Interface with
+ entry Prim;
+ entry Other_Prim;
+ entry Yet_Another_Op;
+ end Task_Type;
+
+ -- Implicit declaration of overriding primitive (as per AI05-0042):
+ -- procedure Prim (S : in out Task_Type);
+
+ procedure Other_Prim (Tsk : in out Task_Type); -- Legal? (No.)
+
+end Task_Pkg;
+
+...
+
+T : Task_Pkg.Task_Type;
+
+...
+
+T.Prim; -- (1) Ambiguous? (No.)
+
+T.Other_Prim; -- (2) Ambiguous? (Not possible; the procedure
+declaration is illegal.)
+
+T.Yet_Another_Op; -- (2) Ambiguous? (Yes.)
****************************************************************
Questions? Ask the ACAA Technical Agent