CVS difference for ai05s/ai05-0030-2.txt

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

--- ai05s/ai05-0030-2.txt	2008/01/08 04:00:51	1.2
+++ ai05s/ai05-0030-2.txt	2008/03/07 06:15:18	1.3
@@ -1,5 +1,12 @@
-!standard  9.5.4(3)                                08-01-07    AI05-0030-2/02
+!standard  9.5(9)                                  08-02-25    AI05-0030-2/03
+!standard  9.5.4(2)
+!standard  9.5.4(3)
+!standard  9.5.4(5)
+!standard  9.5.4(6)
+!standard  9.5.4(7)
+!standard  9.5.4(12)
 !class Binding Interpretation 06-10-13
+!status ARG Approved  6-0-2  08-02-09
 !status work item 06-10-13
 !status received 06-10-13
 !priority Medium
@@ -9,7 +16,8 @@
 !summary
 
 Requeue is permitted to a synchronized, task, or protected interface if
-an appropriate pragma is provided. 
+it is known that the operation is an entry. A new pragma is provided to
+accomplish this.
 
 !problem
 
@@ -36,25 +44,24 @@
                         Legality Rules
 
 The *procedure_*local_name of a pragma Implemented shall denote a 
-dispatching operation of a synchronized interface. 
-The dispatching operation shall not be a function.
+primitive procedure of a synchronized tagged type.
 
-AARM Ramification: The *procedure_*local_name can denote more than one such operation
-if there are several overloaded routines. *None* of the operations can be a
-non-dispatching operation or a function.
+AARM Ramification: The *procedure_*local_name can denote more than one such
+procedure if there are several overloaded routines. No functions can be
+denoted, even if one or more procedures are also denoted.
 
 A pragma Implemented with implementation_kind By_Protected shall not be 
-applied to a dispatching operation of a task interface.
+applied to a primitive procedure of a task interface.
 
-An operation for which the implementation_kind is specified as By_Entry 
-shall be implemented by an entry. An operation for which the 
+A procedure for which the implementation_kind is specified as By_Entry 
+shall be implemented by an entry. A procedure for which the 
 implementation_kind is specified as By_Protected_Procedure shall be 
 implemented by a protected procedure.
 
-If a dispatching operation overrides an inherited operation to which a
+If a primitive procedure overrides an inherited operation to which a
 pragma Implemented applies then any pragma Implemented applied to the
-overriding operation shall be the same or the inherited implementation_kind
-shall be By_Any.
+overriding operation shall have the same implementation_kind
+or the inherited implementation_kind shall be By_Any.
 
 In addition to the places where Legality Rules normally apply (see 12.3), these rules
 apply also in the private part of an instance of a generic unit.
@@ -68,55 +75,55 @@
 
                               NOTE
 
-18 The implementation_kind By_Protected_Procedure declares that the operation
+18 The implementation_kind By_Protected_Procedure implies that the operation
 will not block.
 
 
-Change 9.5.4(2-3) to
+Replace 9.5.4(2-3):
 
    requeue_statement ::= requeue *procedure_or_entry_*name [with abort];
 
           Name Resolution Rules
 
-The *procedure_or_entry_*name of a requeue_statement shall resolve to
-denote a procedure or an entry (the target procedure or entry). In the
-case of an entry, the entry shall have a profile that has no parameters,
-or that is type conformant (see 6.3.1) with the profile of the innermost
-enclosing entry_body or accept_statement. In the case of a procedure,
-the name shall denote a rename of an entry whose profile satisfies the
-above requirement, or shall denote a prefixed view of a primitive 
-subprogram of a synchronized interface where the profile of the prefixed 
-view satisfies the above requirement, the first parameter of the 
-unprefixed view of the primitive subprogram shall be a controlling 
-parameter, and the pragma Implemented with implementation_kind By_Entry 
-shall apply to the primitive subprogram.
-
-
-Change 9.5.4(5) to
-
-If the target procedure (view) or entry has parameters, then its 
-profile shall be subtype conformant with the profile of the innermost 
-enclosing callable construct.
+The *procedure_or_entry_*name of a requeue_statement shall resolve to denote
+a procedure or an entry (the requeue target) that either has no parameters,
+or that has a profile that is type conformant (see 6.3.1) with the profile
+of the innermost enclosing entry_body or accept_statement.
 
-Modify 9.5.4(7) as follows
+Replace 9.5.4(5):
 
+If the requeue target has parameters, then its profile shall be subtype
+conformant with the profile of the innermost enclosing callable construct.
+
+If the target is a procedure, the name shall denote a rename of an entry,
+or shall denote a prefixed view of a primitive subprogram of a synchronized
+interface, where the first parameter of the unprefixed view of the primitive
+subprogram shall be a controlling parameter, and a pragma Implemented with
+implementation_kind By_Entry shall apply to the primitive subprogram.
+
+Modify 9.5.4(6) as follows:
+
+"...entry_declaration {for the entry_body}."
+
+Modify 9.5.4(7) as follows:
+
 The execution of a requeue_statement proceeds by first evaluating the
 [*entry_*name]{*procedure_or_entry_*name} ...
 
-Modify 9.5.4(12) as follows
+Modify 9.5.4(12) as follows:
 
-If the [new] {target procedure or }entry named in the requeue_statement has 
+If the [new entry]{requeue target} named in the requeue_statement has 
 parameters, then during the execution of an accept_statement 
 or entry_body corresponding to a new entry ...
 
 !discussion
 
-A previous version of this AI (0030-1) regarding this problem permitted 
+A previous alternative of this AI (0030-1) regarding this problem permitted 
 the requeue syntactically and then had to resolve what would happen if 
 the target turned out to be implemented by a procedure and not by an 
 entry. This introduced bounded errors and looked difficult to implement.
 
-Accordingly, this version takes a more syntactic view. We need to ensure 
+Accordingly, this version takes a more static view. We need to ensure 
 that the requeue will always turn out to be on an entry and not on a 
 procedure or protected procedure.
 
@@ -202,12 +209,170 @@
 See the paper 'Integrating OOP and Tasking - the missing requeue' by
 Wellings and Burns (IRTAW2007), previously circulated. Find it at
 http://www.ada-auth.org/ai-files/grab_bag/requeue.pdf.
+
+!corrigendum 9.5(9)
+
+@dinsa
+Any call on a protected procedure or entry of a target protected object
+is defined to be an update to the object, as is a requeue on such an entry.
+@dinss
+@s8<@i<Syntax>>
+
+The form of a @fa<pragma> Implemented is as follows
+   @b<pragma> Implemented(@i<procedure_>@fa<local_name>, @fa<implementation_kind>);
+   @fa<implementation_kind> ::= By_Entry | By_Protected_Procedure | By_Any
+
+@s8<@i<Legality Rules>>
+
+The @i<procedure_>@fa<local_name> of a pragma Implemented shall denote a 
+primitive procedure of a synchronized tagged type.
+
+A @fa<pragma> Implemented with @fa<implementation_kind> By_Protected
+shall not be applied to a primitive procedure of a task interface.
+
+A procedure for which the @fa<implementation_kind> is specified as By_Entry 
+shall be implemented by an entry. A procedure for which the 
+@fa<implementation_kind> is specified as By_Protected_Procedure shall be 
+implemented by a protected procedure.
+
+If a primitive procedure overrides an inherited operation to which a
+@fa<pragma> Implemented applies then any @fa<pragma> Implemented applied to the
+overriding operation shall have the same @fa<implementation_kind>
+or the inherited @fa<implementation_kind> shall be By_Any.
+
+In addition to the places where Legality Rules normally apply (see 12.3),
+these rules apply also in the private part of an instance of a generic unit.
+
+@s8<@i<Static Semantics>>
+
+A @fa<pragma> Implemented is said to @i<apply> to the procedure denoted by its
+@i<procedure_>@fa<local_name>. If an overriding operation 
+does not have a @fa<pragma> Implemented then any @fa<pragma> Implemented applying to 
+the inherited operation applies to the overriding operation.
+
+NOTE
+@s9<18  The @fa<implementation_kind> By_Protected_Procedure implies that the
+operation will not block.>
+
+
+!corrigendum 9.5.4(2)
+
+@drepl
+@xcode<@fa<requeue_statement ::= >@ft<@b<requeue> entry_>@fa<name [>@ft<@b<with abort>>@fa<];>>
+@dby
+@xcode<@fa<requeue_statement ::= >@ft<@b<requeue> procedure_or_entry_>@fa<name [>@ft<@b<with abort>>@fa<];>>
+
+!corrigendum 9.5.4(3)
+
+@drepl
+The @i<entry_>@fa<name> of a @fa<requeue_statement> shall resolve
+to denote an entry (the @i<target entry>)
+that either has no parameters, or that has
+a profile that is type conformant (see 6.3.1) with
+the profile of the innermost enclosing @fa<entry_body> or
+@fa<accept_statement>.
+@dby
+The @i<procedure_or_entry_>@fa<name> of a @fa<requeue_statement> shall resolve to denote
+a procedure or an entry (the @i<requeue target>) that either has no parameters,
+or that has a profile that is type conformant (see 6.3.1) with the profile
+of the innermost enclosing @fa<entry_body> or @fa<accept_statement>.
+
+
+!corrigendum 9.5.4(5)
+
+@drepl
+If the target entry has parameters,
+then its profile shall be subtype conformant with
+the profile of the innermost enclosing callable construct.
+@dby
+If the requeue target has parameters, then its profile shall be subtype
+conformant with the profile of the innermost enclosing callable construct.
+
+If the target is a procedure, the name shall denote a rename of an entry,
+or shall denote a prefixed view of a primitive subprogram of a synchronized
+interface, where the first parameter of the unprefixed view of the primitive
+subprogram shall be a controlling parameter, and a pragma Implemented with
+@fa<implementation_kind> By_Entry shall apply to the primitive subprogram.
+
+!corrigendum 9.5.4(6)
+
+@drepl
+In a @fa<requeue_statement> of an @fa<accept_statement> of
+some task unit, either the target object shall be a part of a
+formal parameter of the @fa<accept_statement>,
+or the accessibility level of the target object
+shall not be equal to or statically deeper than any
+enclosing @fa<accept_statement> of the task unit.
+In a @fa<requeue_statement> of an @fa<entry_body>
+of some protected unit, either the target object shall be
+a part of a formal parameter of the @fa<entry_body>,
+or the accessibility level of the target object
+shall not be statically deeper than that
+of the @fa<entry_declaration>.
+@dby
+In a @fa<requeue_statement> of an @fa<accept_statement> of
+some task unit, either the target object shall be a part of a
+formal parameter of the @fa<accept_statement>,
+or the accessibility level of the target object
+shall not be equal to or statically deeper than any
+enclosing @fa<accept_statement> of the task unit.
+In a @fa<requeue_statement> of an @fa<entry_body>
+of some protected unit, either the target object shall be
+a part of a formal parameter of the @fa<entry_body>,
+or the accessibility level of the target object
+shall not be statically deeper than that
+of the @fa<entry_declaration> for the @fa<entry_body>.
+
+!corrigendum 9.5.4(7)
+
+@drepl
+The execution of a @fa<requeue_statement> proceeds by first evaluating the
+@i<entry_>@fa<name>, including the @fa<prefix>
+identifying the target task
+or protected object and the @fa<expression>
+identifying the entry
+within an entry family, if any.
+The @fa<entry_body> or @fa<accept_statement>
+enclosing the @fa<requeue_statement> is then
+completed, finalized, and left (see 7.6.1).
+@dby
+The execution of a @fa<requeue_statement> proceeds by first evaluating the
+@i<procedure_or_entry_>@fa<name>, including the @fa<prefix>
+identifying the target task
+or protected object and the @fa<expression>
+identifying the entry
+within an entry family, if any.
+The @fa<entry_body> or @fa<accept_statement>
+enclosing the @fa<requeue_statement> is then
+completed, finalized, and left (see 7.6.1).
+
+
+!corrigendum 9.5.4(12)
+
+@drepl
+If the new entry named in the @fa<requeue_statement>
+has formal parameters, then during the execution of the
+@fa<accept_statement> or @fa<entry_body> corresponding to the new entry,
+the formal parameters denote the same objects as
+did the corresponding formal parameters
+of the callable construct completed by the requeue.
+In any case, no parameters are specified in a
+@fa<requeue_statement>; any parameter passing is implicit.
+@dby
+If the requeue target named in the @fa<requeue_statement>
+has formal parameters, then during the execution of the
+@fa<accept_statement> or @fa<entry_body> corresponding to the new entry,
+the formal parameters denote the same objects as
+did the corresponding formal parameters
+of the callable construct completed by the requeue.
+In any case, no parameters are specified in a
+@fa<requeue_statement>; any parameter passing is implicit.
 
-!corrigendum
 
 !ACATS test
 
-Create an ACATS test to check that the above changes work.
+Create ACATS tests to check that the above changes work. B-Tests are
+needed for the legality rules and C-Tests for actual dispatching requeuing.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent