CVS difference for ai12s/ai12-0193-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0193-1.txt

--- ai12s/ai12-0193-1.txt	2016/06/07 03:57:19	1.1
+++ ai12s/ai12-0193-1.txt	2016/10/06 01:23:13	1.2
@@ -41,77 +41,78 @@
 
 !wording
 
-Modify 9.5.2(24):
+replace 7.3.2(20/3)
 
-For the execution of an accept_statement, the entry_index, if any, is first
-evaluated and converted to the entry index subtype; this index value identifies
-which entry of the family is to be accepted. Further execution of the
-accept_statement is then blocked until a caller of the corresponding entry is
-selected (see 9.5.3), whereupon the handled_sequence_of_statements, if any, of
-the accept_statement is executed, with the formal parameters associated with
-the corresponding actual parameters of the selected entry call. Upon
-completion of the handled_sequence_of_statements, the accept_statement
-completes and is left. When an exception is propagated from the
-handled_sequence_of_statements of an accept_statement {or from a postcondition
-check}, the same exception is also raised by the execution of the corresponding
-entry_call_statement. 
+    The check is performed on each such part of type T.
 
-[Editor's notelet: I don't think the above is a good idea, but it's what
-everyone asked for in e-mail. See below for thoughts.]
+with
 
+    The check is performed on each such part of type T. In the case of
+    a call to a protected operation, the check is performed before the
+    end of the protected action. In the case of a call to a task entry,
+    the check is performed before the end of the rendezvous.
+
+
+Replace 9.5.2(24):
+
+    For the execution of an accept_statement, the entry_index, if any, is first
+    evaluated and converted to the entry index subtype; this index value
+    identifies which entry of the family is to be accepted. Further execution
+    of the accept_statement is then blocked until a caller of the corresponding
+    entry is selected (see 9.5.3), whereupon the handled_sequence_of_statements,
+    if any, of the accept_statement is executed, with the formal parameters
+    associated with the corresponding actual parameters of the selected entry
+    call. Upon completion of the handled_sequence_of_statements, the
+    accept_statement completes and is left. When an exception is propagated
+    from the handled_sequence_of_statements of an accept_statement, the same
+    exception is also raised by the execution of the corresponding
+    entry_call_statement. 
+
+with
+
+    For the execution of an accept_statement, the entry_index, if any, is first
+    evaluated and converted to the entry index subtype; this index value
+    identifies which entry of the family is to be accepted. Further execution
+    of the accept_statement is then blocked until a caller of the corresponding
+    entry is selected (see 9.5.3), whereupon the handled_sequence_of_statements,
+    if any, of the accept_statement is executed, with the formal parameters
+    associated with the corresponding actual parameters of the selected entry
+    call. Execution of the rendezvous consists of the execution
+    of the handled_sequence_of_statements, performance of any
+    type invariant or postcondition checks associated with the
+    entry, and finalization of any implicitly declared 'Old constants
+    as described in 6.1.1 and 7.3.2. After execution of the rendezvous,
+    the accept_statement completes and is left.
+    When an exception is propagated from the execution of a rendezvous,
+    the same exception is also raised by the execution of the
+    corresponding entry_call_statement.
+
+    AARM Ramification: Execution of the rendezvous does not include
+    any checks associated with parameter copy back or any
+    post-call subtype predicate check for a parameter which is
+    passed by reference. These checks are performed by
+    the caller after the execution of the rendezvous.
+
+[Editor's note: It's a little weird that the term "rendezvous", which is
+defined in the following paragraph, is used in this one. I didn't see a simple
+fix and I wasn't about to do all of Steve's homework for him.]
+
 !discussion
+
+9.5.4(24) is the entire definition of rendezvous. There doesn't seem to be any
+possibility in the above wording of anything happening after the
+handled_sequence_of_statements but before the accept statement is left. 
 
-[Editor's free association follows:]
+On the other hand, 6.1.1(35.1/4) as modified by AI12-0032 says:
 
-This is the entire definition of a "rendezvous". There doesn't seem to be any
-possibility in the above wording of anything happening
-after the handled_sequence_of_statements but before the accept statement is
-left. This wording doesn't seem to deal with copy-back parameters and checks,
-either.
-
-6.4(10/2) says that copy-back happens after the "subprogram is left", and
-as you can see from above, that ends the rendezvous. So it seems clear that
-any exceptions raised by copy-back are not part of the rendezvous (and don't
-get duplicated inside of the accept_statement).
-
-This seems to mean that any out parameter predicate checks, and the vast
-majority of type invariant checks, occur outside of the rendezvous. (They're
-associated with the parameter passing.) This also means that a type
-invariant cannot be modeled as an implicit postcondition, as it gets evaluated
-in a different place. Yikes! (We'd have to have wording to force these things
-inside of the rendezvous.)
-
-This makes it weird that postconditions are evaluated *inside* the rendezvous,
-as all other assertions are evaluated *outside* of the rendezvous (assuming that
-type invariant and predicate checks belong to parameter passing). Moreover,
-6.1.1(36/3) also states that the exception is raised at the point of the call,
-and can't be handled elsewhere.
-
-It's pretty clear to me that all of the wording of the Standard says that the
-exception is only raised at the point of the call, and nowhere else. It's hard
-(impossible??) to make a consistent set of changes that would have any other
-effect. One could patch up 9.5.2(24) as I did above, but calling out
-postcondition checks (as opposed to all assertions or some other larger set)
-seems like a "wart" at best. Changing postconditions into type invariants or
-vice-versa would change where Assertion_Error would be raised.
-
-Implementation-wise, the problem seems to be that type invariants are outside
-of the rendezvous, even though the main implementation strategy is to put them
-into the body. (This seems to be the main reason for having postconditions
-raise inside of the accept statement.)
-
-I can't even begin to think of how to get type invariants to occur within
-the rendezvous while the rest of parameter passing checks are outside.
-
-It's clear the consistent thing to do is to raise assertion errors only at the
-call site, period, as 6.1.1(36/3) implies. In that case, "before the end of
-the rendezvous" only seems to be talking about exclusion and nothing else. 
-But that's 100% opposed to the e-mailed opinions.
+    For a call to a task entry, the postcondition check is performed
+    before the end of the rendezvous;
 
-So at this point I give up and leave the entire ARG to discuss this. As it
-stands, I'm completely against this AI (even though I wrote it).
+It's clear that the intent in 6.1.1 is that postcondition checks are done as
+part of the rendezvous.
 
-[End of editor's free association.]
+We have to resolve this conflict somehow. The most sensible thing to do is
+to expand the definition of rendezvous to include these additional operations.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent