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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0042-1.txt

--- ai05s/ai05-0042-1.txt	2007/10/26 01:37:57	1.2
+++ ai05s/ai05-0042-1.txt	2007/12/13 04:39:36	1.3
@@ -1,6 +1,7 @@
-!standard 3.9.3(6/2)                                             07-10-25    AI05-0042-1/01
-!standard 12.3(18)
+!standard 9.1(9.2/2)                                           07-11-28    AI05-0042-1/02
+!standard 9.4(11.1/2)
 !class binding interpretation 07-03-27
+!status ARG Approved  9-0-0  06-11-11
 !status work item 07-03-27
 !status received 07-01-22
 !priority Medium
@@ -10,7 +11,7 @@
 !summary
 
 A subprogram that is implemented by an entry or by a protected subprogram
-is effectively overridden by an implict subprogram which calls the
+is effectively overridden by an implicit subprogram which calls the
 entry or protected subprogram.
 
 !question
@@ -39,7 +40,7 @@
 
 Presumably this code should be legal, but there is no doubt that it
 violates 3.9.3(6/2), since the operations P1 and P2 inherited by Prot are
-not overridden.
+not overridden. Should this example be legal? (Yes.)
 
 Similarly, 12.3(18) describes how overriding happens in an instance, with
 interesting differences between the visible part and the private part.
@@ -51,38 +52,99 @@
 
 !wording
 
-Add after 9.1(9.2/2):
+Modify the last sentenct of 9.1(9.2/2):
 
-A subprogram implemented by a task entry is also overridden by an implicit, 
-nonabstract subprogram having a subtype conformant profile.  [At execution
-time, the effect of this implicit subprogram is to call the task entry.]
+If the first parameter of a primitive
+inherited subprogram is of the task type or an access parameter designating
+the task type, and there is an entry_declaration for a single entry
+with the same identifier within the task declaration, whose profile is
+type conformant with the prefixed view profile of the inherited subprogram,
+the inherited subprogram is said to be implemented by the conforming
+task entry {using an implicitly declared non-abstract subprogram which
+has the same profile as the inherited subprogram and that overrides it}.
 
-AARM: This rule is needed so that a subprogram implemented by an entry is
+AARM Reason: The part about the implicitly declared subprogram is needed so
+that a subprogram implemented by an entry is
 considered to be overridden for the purpose of the other rules of the
-language.  Without it, it would for instance be illegal for an abstract
+language. Without it, it would for instance be illegal for an abstract
 subprogram to be implemented by an entry, because the abstract subprogram
-would not be overridden.  The rules in 9.1(9.6/2-9.8/2) and 9.4(11.5/2-11.7/2) 
+would not be overridden. The rules in 9.1(9.6/2-9.8/2) and 9.4(11.5/2-11.7/2) 
 ensure that there is no conflict between the implicit overriding subprogram 
 and a user-defined overriding subprogram.
 
-Add after 9.4(11.1/2):
+Modify the last sentence of 9.4(11.1/2):
 
-A subprogram implemented by a protected subprogram or entry is also overridden
-by an implicit, nonabstract subprogram having a subtype conformant profile.  
-[At execution time, the effect of this implicit subprogram is to call the
-protected subprogram or entry.]
+If the first parameter of a primitive
+inherited subprogram is of the protected type or an access parameter designating
+the protected type, and there is a protected_operation_declaration for
+a protected subprogram or single entry with the same identifier within the
+protected declaration, whose profile is type conformant with the prefixed view
+profile of the inherited subprogram, the inherited subprogram is said to be
+implemented by the conforming protected subprogram or entry {using
+an implicitly declared non-abstract subprogram which has the same profile
+as the inherited subprogram and that overrides it}.
 
 !discussion
 
 One possible fix would be to change "overridden" by "overridden or implemented by"
-everywhere.  But there are 24 occurrences of "overridden" in the RM, and the
-occurrences of "overriding" would have to be checked too.  That's unappealing.
+everywhere. But there are 24 occurrences of "overridden" in the RM, and the
+occurrences of "overriding" would have to be checked too. That's unappealing.
 It seems more straightforward to reify the model that we have had in mind all
 along anyway, namely that there is an implicit override that acts as a wrapper
 to call the protected subprogram or entry.
 
---!corrigendum 10.1.2(20/2)
+!corrigendum 9.1(9.2/2)
 
+@drepl
+For a task declaration with an @fa<interface_list>, the task type inherits
+user-defined primitive subprograms from each progenitor type (see 3.9.4),
+in the same way that a derived type inherits user-defined primitive subprograms
+from its progenitor types (see 3.4). If the first parameter of a primitive
+inherited subprogram is of the task type or an access parameter designating
+the task type, and there is an @fa<entry_declaration> for a single entry
+with the same identifier within the task declaration, whose profile is
+type conformant with the prefixed view profile of the inherited subprogram,
+the inherited subprogram is said to be @i<implemented> by the conforming task entry.
+@dby
+For a task declaration with an @fa<interface_list>, the task type inherits
+user-defined primitive subprograms from each progenitor type (see 3.9.4),
+in the same way that a derived type inherits user-defined primitive subprograms
+from its progenitor types (see 3.4). If the first parameter of a primitive
+inherited subprogram is of the task type or an access parameter designating
+the task type, and there is an @fa<entry_declaration> for a single entry
+with the same identifier within the task declaration, whose profile is
+type conformant with the prefixed view profile of the inherited subprogram,
+the inherited subprogram is said to be @i<implemented> by the conforming
+task entry using an implicitly declared non-abstract subprogram which
+has the same profile as the inherited subprogram and that overrides it.
+
+
+!corrigendum 9.4(11.1/2)
+
+@drepl
+For a protected declaration with an @fa<interface_list>, the protected type
+inherits user-defined primitive subprograms from each progenitor type (see 3.9.4),
+in the same way that a derived type inherits user-defined primitive subprograms
+from its progenitor types (see 3.4). If the first parameter of a primitive
+inherited subprogram is of the protected type or an access parameter designating
+the protected type, and there is a @fa<protected_operation_declaration> for
+a protected subprogram or single entry with the same identifier within the
+protected declaration, whose profile is type conformant with the prefixed view
+profile of the inherited subprogram, the inherited subprogram is said to be
+@i<implemented> by the conforming protected subprogram or entry.
+@dby
+For a protected declaration with an @fa<interface_list>, the protected type
+inherits user-defined primitive subprograms from each progenitor type (see 3.9.4),
+in the same way that a derived type inherits user-defined primitive subprograms
+from its progenitor types (see 3.4). If the first parameter of a primitive
+inherited subprogram is of the protected type or an access parameter designating
+the protected type, and there is a @fa<protected_operation_declaration> for
+a protected subprogram or single entry with the same identifier within the
+protected declaration, whose profile is type conformant with the prefixed view
+profile of the inherited subprogram, the inherited subprogram is said to be
+@i<implemented> by the conforming protected subprogram or entry using
+an implicitly declared non-abstract subprogram which has the same profile
+as the inherited subprogram and that overrides it.
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent