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

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

--- ai05s/ai05-0291-1.txt	2012/02/19 04:54:06	1.2
+++ ai05s/ai05-0291-1.txt	2012/03/16 06:16:10	1.3
@@ -1,7 +1,9 @@
-!standard  9.4(11.9/2)                              12-02-15    AI05-0291-1/01
+!standard  9.4(11.9/2)                              12-02-25    AI05-0291-1/02
 !standard  9.5(2)
+!standard  9.5(3)
 !standard  9.5(4)
 !standard  9.5(6)
+!standard  9.5(7.1/2)
 !class binding interpretation 12-02-15
 !status Amendment 2012 12-02-15
 !status work item 12-02-15
@@ -15,8 +17,8 @@
 first parameter with mode *in*.
 
 "Target Object" is redefined to include prefixed views of primitives of
-synchronized interfaces. It is also clarified as to what precisely is being
-denoted.
+limited interfaces. We also define target object for "normal" calls to
+primitives of limited interfaces.
 
 !question
 
@@ -45,18 +47,14 @@
 [Note: anonymous access parameters are considered of mode *in*, so we have
 disallow access-to-variable rather than allow access-to-constant.]
 
-Modify 9.4(2/3):
+Replace 9.5(2/3) with:
 
-   Any name that denotes an entry or a protected subprogram identifies a
-   target object, which is either a task (for an entry) or a protected
-   object (for an entry or a protected subprogram). The target object
-   identified by the operation name (or prefix) used in a call on an
-   entry or a protected subprogram is considered an implicit parameter to
-   the call. {In addition, a primitive subprogram of a limited interface
-   can be implemented by an entry or a protected subprogram, and a name
-   denoting such a subprogram also identifies a target object.}
+  When a name or prefix denotes an entry, protected subprogram, or a
+  prefixed view of a primitive subprogram of a limited interface whose
+  first parameter is a controlling parameter, the name or prefix
+  determines a *target object*, as follows:
 
-   AARM To Be Honest: This wording uses "denotes" to mean "denotes a view
+   AARM To Be Honest: Thie wording above uses "denotes" to mean "denotes a view
    of an entity" (when the term is used in Legality Rules), and
    "denotes an entity" (when the term is used in Dynamic Semantics rules).
    It does not mean "view of a declaration", as that would not include
@@ -68,43 +66,49 @@
    Else we have a wording hole. Requeue, timed_entry calls, and
    conditional_entry_calls all have legality rules to prevent allowing too
    much.]
+   
+Modify 9.5(3):
 
-   {When the name denotes an entry, protected subprogram, or a prefixed
-   view of a primitive subprogram of a limited interface whose first parameter
-   is a controlling parameter, t}[T]he target object is determined as follows:
+* If it is a direct_name or expanded name that denotes the declaration
+  (or body) of the operation, then the target object is implicitly
+  specified to be the current instance of the task or protected unit
+  immediately enclosing the operation; [such] a call {using such a name}
+  is defined to be an internal call;
 
 Modify 9.5(4):
 
 * If it is a selected_component that is not an expanded name, then the target
-  object is explicitly specified to be the [task or protected] object denoted by
-  the prefix of the name; such a call is defined to be an external call;
-
-[Reason for deletion: This definition is used in legality rules, as well
-as in "might-be-entry" call, and thus cannot presume to "assume" the actual
-object is any particular kind. And that's not needed for either use, so
-the text is just dropped.]
+  object is explicitly specified to be the [task or protected] object
+  denoted by the prefix of the name; [such] a call {using such a name} is
+  defined to be an external call;
+
+[Reason for deletion of "task or protected": This definition is used in
+legality rules, as well as in "might-be-entry" call, and thus cannot
+presume to "assume" the actual object is any particular kind. And that's
+not needed for either use, so the text is just dropped.]
+
+Modify 9.5(5):
+* If the name or prefix is a dereference (implicit or explicit) of an
+  access-to-protected-subprogram value, then the target object is
+  determined by the prefix of the Access attribute_reference that
+  produced the access value originally[, and the] {; a} call {using such
+  a name} is defined to be an external call;
 
 Add after 9.5(6):
 
-Any call that might be on an entry or protected subprogram and that is
-not included above is an external call. For a call other than via a prefixed
-view on a primitive subprogram of a limited interface whose first parameter is a
-controlling parameter, the first parameter of the call is the target object of
-the call. For a call on a subprogram rename, the name of the renamed item and
-possibly the first parameter determine the target object of the call. For a call
-on a generic formal subprogram, the name of the actual callable entity and
-possibly the first parameter determine the target object of the call.
-
-AARM Discussion: The above says "possibly the first parameter", because Ada
-allows entries and protected subprograms to be renamed and passed as formal
-subprograms. In those cases, the target object can be (but is not required to be
-in the case of subprograms) implicit in the name of the routine; otherwise the
-object is an explicit parameter to the call.
-
-[Note: This rule only applies to entry and protected calls; it never applies
-to renames. We need the definition of "external call" for Legality Rules,
-but the definition of "target object" is only used in Dynamic Semantics
-rules so we can talk about the actual for formal subprograms.]
+A call on an entry or a protected subprogram either uses a name or
+prefix that determines a target object implicitly, as above, or is a
+call on (a non-prefixed view of) a primitive subprogram of a limited
+interface whose first parameter is a controlling parameter, in which
+case the target object is identified explicitly by the first parameter.
+This latter case is an external call.
+
+Replace 9.5(7.1/3) [Legality Rule]:
+
+If a name or prefix determines a target object, and the name denotes a
+protected entry or procedure, then the target object shall be a
+variable, unless the prefix is for an attribute_reference to the Count
+attribute (see 9.9).
 
 Delete 9.7.2(3.3/2) [This rule and its AARM note are now given above.]
 
@@ -125,7 +129,10 @@
 right object). We only did that for timed and conditional entry calls in
 Ada 2005; it needs to be done for "normal" calls as well.
 
+Once this is done, we no longer need the old definition for timed and conditional
+entry calls, so it is removed.
 
+
 We have to clarify the meaning of "denotes" in the "Target Object" wording.
 This is Static Semantics, and it is used in Legality Rules, so by usual
 definition, "denotes" here means "denotes a view of a declaration". (Views
@@ -138,9 +145,27 @@
 
 The Standard is often sloppy about this (one of the worst instances is
 8.6(17/3), which manages to use "denotes" as implicitly denoting a declaration
-AND an entity in the same sentence! But we're not trying to fix all such cases
-here, just the one we're working on).
+AND an entity in the same sentence)! But we're not trying to fix all such cases
+here, just the one we're working on.
+
 
+We simplified the Legality Rule that uses target object in 9.5(7.1/3). This rule
+is not needed for "normal" calls, as those have an explicit "in out" or "out"
+parameter to which the target object is passed, and passing a constant to those
+sorts of parameters has been banned since the beginning of Ada time. By eliminating
+that case from this rule, we can greatly simplify 9.5(6.1/3) [the paragraph inserted
+after 9.5(6)] because it is only needed in Dynamic Semantics rules (and thus renames
+and formal subprograms become irrelevant).
+
+Specifically, if a subprogram renames is a renames of a prefixed view, then the
+bullets 9.5(3-6) apply to identify the target objects. Otherwise, (the renames is
+of the name of an entity, with no prefixed view), the call is a "normal" call,
+and "denotes the entity" does the right thing (so long as it is only used in Dynamic
+Semantics rules, as is true currently). The same holds for formal subprograms.
+
+[Randy: Humm. We don't have a bullet like 9.5(6) for formal subprograms. Should we not
+have one??]
+
 !corrigendum 9.4(11.9/2)
 
 @drepl
@@ -876,3 +901,4 @@
 lot of words...
 
 ****************************************************************
+

Questions? Ask the ACAA Technical Agent