Version 1.4 of ai05s/ai05-0291-1.txt

Unformatted version of ai05s/ai05-0291-1.txt version 1.4
Other versions for file ai05s/ai05-0291-1.txt

!standard 9.4(11.9/2)          12-03-15 AI05-0291-1/03
!standard 9.5(2)
!standard 9.5(3)
!standard 9.5(4)
!standard 9.5(5)
!standard 9.5(6)
!standard 9.5(7.1/2)
!standard 9.7.2(3.3/2)
!class binding interpretation 12-02-15
!status Amendment 2012 12-02-15
!status ARG Approved 7-0-3 12-02-26
!status work item 12-02-15
!status received 12-02-01
!priority Low
!difficulty Easy
!subject Target object needs to include synchronized interfaces
!summary
Inherited functions that are implemented by protected functions must have a first parameter with mode in.
"Target Object" is redefined to include prefixed views of primitives of limited interfaces. We also define target object for "normal" calls to primitives of limited interfaces.
!question
9.5.4(6/3) and various other rules talk about the "Target Object". This is defined in 9.5(2-6), but this wording does not take into account calls via synchronized interfaces (which are either prefixed views or regular calls). Should this be fixed? (Yes.)
9.4(11.9/2) requires particular parameter modes for inherited subprograms implemented by protected procedures and entries. Now that functions can have in out parameters, do we need a corresponding rule for protected functions? (Yes.)
!recommendation
(See summary.)
!wording
Add to the end of 9.4(11.9/2):
If an inherited subprogram is implemented by a protected function, then the first parameter of the inherited subprogram shall be of mode in, but not an access-to-variable parameter.
[Note: anonymous access parameters are considered of mode in, so we have to disallow access-to-variable rather than allow access-to-constant.]
Replace 9.5(2/3) with:
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 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 renames (a renames is not an entry or protected subprogram). End AARM To Be Honest.
[Note: We use "limited" rather than "synchronized" here, so this wording identifies a target object for all possible entry and protected calls. Else we have a wording hole. Requeues, timed_entry_calls, and conditional_entry_calls all have legality rules to prevent allowing too much.]
Modify 9.5(3):
* 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 {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):
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).
AARM Ramification: This rule does not apply to calls that are not to a prefixed view. Specifically a "normal" call to a primitive operation of a limited interface is not covered by this rule. In that case, the normal parameter passing mode checks will prevent passing a constant protected object.
Delete 9.7.2(3.3/2) [This rule and its AARM note are now given above.]
!discussion
Note that paragraphs 9.5.4(7.1-9) talk about target tasks and target protected objects. These are fine, even for requeues on synchronized interfaces, as these are Dynamic Semantic rules. For these, only the underlying entity matters (no views are taken into account), and the underlying target object has to be a task or protected object - no other sort of concrete object is possible for an entry. The fact that the object also has a synchronized interface is irrelevant for this use.
Note that this wording also is needed to define that calls on primitives of interfaces are external calls (so that protected calls start a protected action), and the target object needs to be defined (so the PO occurs on the 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.
The meaning of "denotes" in the "Target Object" wording is confusing. 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 matter to Legality Rules.) But in this case, we're interested in the "entity" (especially as the Legality Rules mainly refer to the syntactic form of the Target Object, not the semantic details); in particular, we need to look through renames here. While it would have been preferable to clarify the wording, that didn't seem possible. So a To Be Honest AARM note was added instead.
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 going to try to fix this Standard in this area, it is just too hard.
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.
We now require primitive functions that are implemented by protected functions to have an in parameter (or access-to-constant parameter). This is essentially the same rule that we have for protected procedures, in reverse. However, this causes a small incompatibility: "access T" is no longer allowed as the type of such a parameter. The parameter needs to be declared as "access constant T".
!corrigendum 9.4(11.9/2)
Replace the paragraph:
If an inherited subprogram is implemented by a protected procedure or an entry, then the first parameter of the inherited subprogram shall be of mode out or in out, or an access-to-variable parameter.
by:
If an inherited subprogram is implemented by a protected procedure or an entry, then the first parameter of the inherited subprogram shall be of mode out or in out, or an access-to-variable parameter. If an inherited subprogram is implemented by a protected function, then the first parameter of the inherited subprogram shall be of mode in, but not an access-to-variable parameter.
!corrigendum 9.5(2)
Replace the paragraph:
Any call on an entry or on a protected subprogram identifies a target object for the operation, which is either a task (for an entry call) or a protected object (for an entry call or a protected subprogram call). The target object is considered an implicit parameter to the operation, and is determined by the operation name (or prefix) used in the call on the operation, as follows:
by:
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:
!corrigendum 9.5(3)
Replace the paragraph:
by:
!corrigendum 9.5(4)
Replace the paragraph:
by:
!corrigendum 9.5(5)
Replace the paragraph:
by:
!corrigendum 9.5(6)
Insert after the paragraph:
the new paragraph:
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.
!corrigendum 9.5(7.1/2)
Replace the paragraph:
The view of the target protected object associated with a call of a protected procedure or entry shall be a variable.
by:
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).
!corrigendum 9.7.2(3.3/2)
Delete the paragraph:
If a procedure_call_statement is used for a procedure_or_entry_call, and the procedure is implemented by an entry, then the procedure_name, or procedure_prefix and possibly the first parameter of the procedure_call_statement, determine the target object of the call and the entry to be called.
!ACATS Test
No ACATS test should be needed (presuming that requeue, timed entry call, and conditional entry call tests check calls through synchronized interfaces).
!ASIS
No change needed.
!appendix

From: Randy Brukardt
Sent: Wednesday, February 1, 2012  11:45 PM

Jean-Pierre wrote in his review:

> 9.5.4(6/3)
> This paragraph uses the term "target object", but I don't think it is
> defined.  (the "requeue target" is defined in 9.5.4(3/3), but it is
> the procedure or entry)

He later noted that the definition is in 9.5(2/3), but that is doesn't "address
the case of a procedure from a synchronized interface".

My initial reaction is that of course it does, because it is talking about the
underlying entry or protected subprogram, not some statically denoted one. If it
didn't, then the "target object" of a renames of an entry as a procedure would
not be covered, and this wording dates back to Ada 95. It's an important part of
the definition of an entry call -- there are 20 occurrences in Chapter 9.

However, I see that we revised the wording to handle problems with renames and
in access-to-subprogram values where the object is a constant. The revision uses
"denotes", which is defined in 8.6 to be the declaration associated with the
name. The problem of course is that a renaming declaration is a declaration
(duh), and here are we mean the underlying entity is an entry or protected
subprogram -- we don't care what the form of the renaming is. So the first
sentence of 9/5(2/3) is False for a renaming of an entry, and the fact that we
then give that a definition later (in 9.5(6)) is irrelevant.

This says that the synchronized interface cases don't work, either, because
there too the declaration involved is an ordinary subprogram. (And while the
subprogram can be declared to be a protected subprogram or an entry, such a
declaration is not required, so we have to have to handle any possible primitive
of a synchronized interface.)

I hadn't noticed 9.5(6) until just now, so there is clearly a second problem
-- we need a bullet covering synchronized interfaces here. But that seems
impossible:

* If the name or prefix denotes a primitive operation of a synchronized
  interface, the target object is ???

as the target object is the first parameter of the associated call, and we're
not necessarily talking about a call here. (This is used in requeues, for
instance, and we also have to handle cases where the primitive is renamed and
then called.)

And I don't see any sensible rewording of the first sentence, either. We have to
somehow get rid of the word "denotes". But I can't do it. The best I can come up
with is "ultimately denotes":

"Any name that ultimately denotes an entry or a protected subprogram identifies
a target object..."

To Be Honest: "ultimately denotes" means the underlying declaration is an entry
or protected subprogram, ignoring any renames or "implemented by"s.

None of this feels remotely right to me. I'd hoped to avoid stuffing the meeting
agenda with this sort of wording change, but I'm at a loss here.

----

Unrelated aside:

9.4(11.9/2) requires routines implementing protected procedures or entries to
have "in out" or "out" parameters. Do we need a rule making "in out" or "out"
illegal for a protected function? Or do we care (because the protected function
can't modify the object, so it doesn't matter whether or not it is allowed?). Or
am I just losing my mind?

****************************************************************

From: Randy Brukardt
Sent: Thursday, February  2, 2012  12:02 AM

...
> I hadn't noticed 9.5(6) until just now, so there is clearly a second problem
> -- we need a bullet covering synchronized interfaces here.
> But that seems impossible:
>
> * If the name or prefix denotes a primitive operation of a
> synchronized interface, the target object is ???
>
> as the target object is the first parameter of the associated call,
> and we're not necessarily talking about a call here.
> (This is used in requeues, for instance, and we also have to handle
> cases where the primitive is renamed and then called.)

I was (and remain) confused here. If we were just talking about a prefixed view,
this could be easily handled:

* If the name or prefix denotes the prefixed view of a primitive operation of a
  synchronized interface, the target object is the prefix of the prefixed view.

Since we have the needed definitions in 4.1.3.

But if this is in the form of an "ordinary" call, we have trouble.

However, we don't need to worry about the renaming and access-to-subprogram bugs
in that case, because Ada doesn't have currying other than via the prefixed
view, and you can't requeue on a procedure other than a prefixed view. So maybe
we need a totally separate paragraph to cover that case; it only needs to cover
(ordinary) calls. Something like:

In addition, in a call on a primitive operation of a synchronized interface
other than a call on a prefixed view, the target object is the actual first
parameter of the call.

This is clunky, but at least it might work.

Thoughts?

****************************************************************

From: Tucker Taft
Sent: Thursday, February  2, 2012  10:36 AM

...
> However, I see that we revised the wording to handle problems with
> renames and in access-to-subprogram values where the object is a
> constant. The revision uses "denotes", which is defined in 8.6 to be
> the declaration associated with the name. The problem of course is
> that a renaming declaration is a declaration (duh), and here are we
> mean the underlying entity is an entry or protected subprogram -- we
> don't care what the form of the renaming is. So the first sentence of
> 9/5(2/3) is False for a renaming of an entry, and the fact that we
> then give that a definition later (in
> 9.5(6)) is irrelevant. ...

I think there may be some fixes needed here, but the word "denotes" is used to
talk about denoting *entities* as well as *declarations.*  For example, here is
the first paragraph of 4.1 Names:

   Names can denote declared entities, whether
   declared explicitly or implicitly (see 3.1).
   Names can also denote objects or subprograms
   designated by access values; the results of
   type_conversions or function_calls; subcomponents
   and slices of objects and values; protected
   subprograms, single entries, entry families,
   and entries in families of entries. Finally,
   names can denote attributes of any of the foregoing.

I'll try to respond to your other issues soon.

****************************************************************

From: Tucker Taft
Sent: Thursday, February  2, 2012  10:38 AM

One more comment about "denotes."  It definitely "sees through" renamings.  Here
is the last sentence of 8.5(3)):

   A name that denotes the renaming_declaration
   denotes (a new view of) the renamed entity.

So yes, names denote declarations, but they also denote the "ultimate" entity,
as you called it.

****************************************************************

From: Bob Duff
Sent: Thursday, February  2, 2012  10:46 AM

> I think there may be some fixes needed here, but the word "denotes" is
> used to talk about denoting *entities* as well as *declarations.*  For
> example, here is the first paragraph of 4.1 Names:

Right.  Also relevant:

3.1(8): "...the name is said to
denote the declaration, the view, and the associated entity (see 8.6)."

8.6(16-19):

16  [Each occurrence of] a usage name denotes the declaration determined by its
    interpretation. It also denotes the view declared by its denoted
    declaration, except ...
...
19  A usage name that denotes a view also denotes the entity of that view.

So if X renames Y, an occurrence of X denotes the renaming declaration, and the
view X, and the entity Y.

So if you want to "go through renames", you can talk about "the entity denoted
by...".

****************************************************************

From: Tucker Taft
Sent: Thursday, February  2, 2012  11:10 AM

> However, I see that we revised the wording to handle problems with
> renames and in access-to-subprogram values where the object is a
> constant. The revision uses "denotes", which is defined in 8.6 to be
> the declaration associated with the name. The problem of course is
> that a renaming declaration is a declaration (duh), and here are we
> mean the underlying entity is an entry or protected subprogram -- we
> don't care what the form of the renaming is. So the first sentence of
> 9/5(2/3) is False for a renaming of an entry, and the fact that we
> then give that a definition later (in
> 9.5(6)) is irrelevant.

As indicated in an earlier response, the above paragraph is somewhat confused...

>
> This says that the synchronized interface cases don't work, either,
> because there too the declaration involved is an ordinary subprogram.
> (And while the subprogram can be declared to be a protected subprogram
> or an entry, such a declaration is not required, so we have to have to
> handle any possible primitive of a synchronized interface.)

You can only requeue on a subprogram implemented as an entry.
And you can only call primitives of synchronized interfaces when the first
parameter is a controlling parameter.

9.7.2(3.3) defines target object for a selective entry call:

   If a procedure_call_statement is used for a
   procedure_or_entry_call, and the procedure is
   implemented by an entry, then the procedure_name,
   or procedure_prefix and possibly the first
   parameter of the procedure_call_statement,
   determine the target object of the call and
   the entry to be called.

Perhaps this should be somehow merged into 9.5(2-6).
We at least need to allow for the possibility that the target object can be
specified by the first parameter in a call on a primitive of a synchronized
interface.

Perhaps we revise 9.5(2-4) as follows:

   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. {A primitive subprogram of a synchronized interface can be
   implemented by an entry or a protected subprogram.  In a call on such
   a primitive subprogram, the target object is the task or protected
   object identified by the first parameter, or in the case of a prefixed
   view of such a primitive subprogram, by the prefix of the prefixed
   view.

   When the name denotes an entry, protected subprogram, or a prefixed
   view of a primitive of a synchronized interface, 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 is defined to be an
     internal call;

   * 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;

> I hadn't noticed 9.5(6) until just now, so there is clearly a second
> problem
> -- we need a bullet covering synchronized interfaces here. But that
> seems
> impossible:
>
> * If the name or prefix denotes a primitive operation of a
> synchronized interface, the target object is ???

In a requeue, it would only be allowed if the name denoted a prefixed-view of
such a primitive operation.

> as the target object is the first parameter of the associated call,
> and we're not necessarily talking about a call here. (This is used in
> requeues, for instance, and we also have to handle cases where the
> primitive is renamed and then called.)

As indicated above, in a requeue you would have to use a prefixed view.

> And I don't see any sensible rewording of the first sentence, either.
> We have to somehow get rid of the word "denotes". But I can't do it.
> The best I can come up with is "ultimately denotes":

As mentioned in my earlier replies, "denotes" is fine.

> "Any name that ultimately denotes an entry or a protected subprogram
> identifies a target object..."
>
> To Be Honest: "ultimately denotes" means the underlying declaration is
> an entry or protected subprogram, ignoring any renames or "implemented by"s.
>
> None of this feels remotely right to me. I'd hoped to avoid stuffing
> the meeting agenda with this sort of wording change, but I'm at a loss here.

The above wording might solve at least some of the problems.

>
> ----
>
> Unrelated aside:
>
> 9.4(11.9/2) requires routines implementing protected procedures or
> entries to have "in out" or "out" parameters. Do we need a rule making
> "in out" or "out" illegal for a protected function? Or do we care
> (because the protected function can't modify the object, so it doesn't
> matter whether or not it is allowed?). Or am I just losing my mind?

I would agree we should require a function implementing a protected function to
have its first parameter be of mode "in."

****************************************************************

From: Tucker Taft
Sent: Thursday, February  2, 2012  11:11 AM

> However, we don't need to worry about the renaming and
> access-to-subprogram bugs in that case, because Ada doesn't have
> currying other than via the prefixed view, and you can't requeue on a
> procedure other than a prefixed view. So maybe we need a totally
> separate paragraph to cover that case; it only needs to cover (ordinary) calls. Something like:
>
> In addition, in a call on a primitive operation of a synchronized
> interface other than a call on a prefixed view, the target object is
> the actual first parameter of the call.
>
> This is clunky, but at least it might work.

I do think we need to require a prefixed view when requeuing on a primitive of a
synchronized interface. See my earlier response for more details.

****************************************************************

From: Steve Baird
Sent: Thursday, February  2, 2012  11:38 AM

> ... the word "denotes" is used to talk about denoting *entities* as
> well as *declarations.*

I agree with Tuck, but this has been a source of confusion.

A while ago Bob pointed out to me (in private communication) that one has to
keep this point in mind in order to decipher the "current instance" rule of
8.6(17/2):

    If a usage name appears within the declarative region of a
    generic_declaration (but not within its generic_formal_part) and it
    denotes that same generic_declaration, then it denotes the current
    instance of the generic unit (rather than the generic unit itself).

I incorrectly thought this wording was wrong:
    "If it denotes this, then it denotes that" eems like a liar's
    paradox thing - if it denotes this, then it denotes that, so
    it no longer denotes this, which means it doesn't denote that
    after all and goes back to denoting this, ...

Bob pointed out that the first "denotes" refers to denoting a declaration while
the second refers to denoting an entity.

I think it would be worth the extra verbiage if the RM were to make the
declaration/entity distinction more explicit in some of the places where the
term "denotes" is used.

Perhaps the current wording isn't wrong, but I think Randy would agree with me
that it is confusing.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February  2, 2012  1:58 PM

...
> I do think we need to require a prefixed view when requeuing on a
> primitive of a synchronized interface.
> See my earlier response for more details.

There is such a requirement already. It's just making sense out of the target
object rules such that they work for both prefixed views (easy) and infix calls
(not so easy).

And the "denotes" confusion needs to be straightened out. I agree with Steve
that more clarity would help, it's not always obvious if we're talking about a
declaration or an entity (we call both of them "subprograms" most of the time),
and it clearly matters in the case of renaming. This is similar (except worse)
to the confusion about whether we're talking about an entity or a view of an
entity. (A view of an entity roughly corresponding to a declaration.)

The definition of "target object" is mostly a dynamic concept (meaning we want
to talk about entities, not views or declarations), but it is given in the
static semantics section and includes the concept of internal or external calls
(which control some legality rules, so do implicitly use "views"). Generally
"static semantics" depends on declarations and views, and really needs to
clearly state when that is not true. Else we will head to madness (if we're not
already there :-).

****************************************************************

From: Randy Brukardt
Sent: Thursday, February  2, 2012  2:02 PM

...
> The definition of "target object" is mostly a dynamic concept (meaning
> we want to talk about entities, not views or declarations), but it is
> given in the static semantics section and includes the concept of
> internal or external calls (which control some legality rules, so do
> implicitly use "views"). Generally "static semantics" depends on
> declarations and views, and really needs to clearly state when that is
> not true. Else we will head to madness (if we're not already there
> :-).

Actually, target object is also used in Legality Rules, (9.5(7.1/3)), so clearly
views need to matter in its definition. But they also need *not* to matter in
its definition (so we punch through renames, because a rename is surely a view).
This needs to be crystal clear; I'm confused even thinking about it. :-)

****************************************************************

From: Bob Duff
Sent: Thursday, February  2, 2012  3:40 PM

> And the "denotes" confusion needs to be straightened out.

Hmm.  I haven't followed this whole conversation, but I think doing major
surgery on the definition of "denotes" is asking for trouble.

> ...to madness (if we're not already there :-).

;-)

****************************************************************

From: Randy Brukardt
Sent: Thursday, February  2, 2012   4:06 PM

> Hmm.  I haven't followed this whole conversation, but I think doing
> major surgery on the definition of "denotes"
> is asking for trouble.

I would agree with that. What matters is that we not be too flippant about
switching between the meanings (that is "denotes a declaration" vs. "denotes a
view" vs. "denotes an entity"), especially when we're talking about something
that is used both in legality rules and in dynamic semantics. (As in this case).
So it's about "major surgery" on uses of "denotes" that are clearly confusing,
not to try to change the definition (and no other word seems to fill the bill
anyway).

The problem I have in this specific case is that this must be "denotes a view"
(because it's used in legality rules and privacy must be respected), but it also
must be "denotes an entity" (because it's supposed to punch through renames to
see that it is renaming an entry or protected subprogram). Don't see how it can
be both at the same time. And even if we don't want it to refer to views (if we
somehow determine that privacy doesn't matter here - warning, thin ice), we have
to say that in Static Semantics, which by default is always talking about views.
(Via the "clear from context rule", now stated explicitly in 3.1(7.1/3)).

****************************************************************

From: Jean-Pierre Rosen
Sent: Monday, February  6, 2012   12:25 PM

I had set aside this discussion until I could find a moment to concentrate on
it... I have it now

> Perhaps we revise 9.5(2-4) as follows:
>
>   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).

I think the case of "implemented by entry" should be made explicit, I don't
think (unless I missed an important paragraph - this may happen even to ARG
members ;-) ) that "denotes an entry" covers a primitive operation of a
synchronized interface implemented by entry. Hmm.. the target object might be
needed for all operations of a synchronized interface. So:

Any name that denotes an entry, a protected subprogram {, or a primitive
operation of a synchronized interface}, identifies a target object, which is
either a task (for an entry) or a protected object (for an entry or a protected
subprogram).

****************************************************************

From: Tucker Taft
Sent: Monday, February  6, 2012  1:02 PM

> Any name that denotes an entry, a protected subprogram {, or a
> primitive operation of a synchronized interface}, identifies a target
> object, which is either a task (for an entry) or a protected object
> (for an entry or a protected subprogram).

But you took the quote above out of context.  The paragraph I proposed already
covers the case of a primitive operation of a synchronized interface, later in
the paragraph.  The sentence you are proposing above is clearly false, since a
name that denotes a primitive of a synchronized interface does *not* identify a
target object.  That is the whole problem.  You have to provide the target
object as the first parameter, or alternatively, create a prefixed view of the
primitive. So I don't think you can reduce this to a single sentence.  That is
why the paragraph I proposed has several sentences, trying to cover all the
bases.

****************************************************************

From: Randy Brukardt
Sent: Monday, February  6, 2012  2:19 PM

Right, this rule has to be written in terms of prefixed views and/or calls.

I had proposed a different rewrite of this section that essentially added the
prefixed view case to the "normal" case, and then added a separate sentence to
describe the semantics for "normal" calls to synchronized interface primitives.
I had done that because the main wording goes to great lengths to deal with
renames and 'access prefixes, while none of that is appropriate for "normal"
calls.

As seems to be happening with fairly significant regularity, Tucker never
commented on my version and instead proposed his own, so I don't know if there
was something wrong with my version or if he just never read it. I'm worried
that his version has problems in some of these funny corner cases, but I figured
I'd work through it when I created the AI text for this. (I wasn't expecting it
to pop up again before the meeting.)

And now J-P is trying to fix the wording without reading either Tucker's or my
wording proposals. We don't need 3 ways to fix the same thing unless someone
thinks there is something wrong with the current proposal. Which requires
understanding what is proposed and responding to it...

****************************************************************

From: Jean-Pierre Rosen
Sent: Monday, February  6, 2012  1:30 PM

Here are the issues from my comments that might need wider scrutinity (is that the correct english word?)

> Here are my comments/dispositions on Jean-Pierre's comments:

>> 9.5.4(7/3) says:
>>    "The execution of a requeue_statement proceeds by first evaluating
>>    the procedure_or_entry_name[, including the prefix identifying the
>>    target task or protected object.."
>>
>> This seems to exclude the case where the prefix is a synchronized
>> interface.  Shouldn't it say "target object" too?
>
> The "prefix" can't be a primitive subprogram of a synchronized
> interface; the "name" has to be a prefixed view of a primitive
> subprogram of a synchronized interface, and this is talking about the
> prefix of that prefixed view.
>
> Similarly, if this is directly an entry, it has to be a prefixed view
> of that entry (unless it is internal).
>
> So in both cases, there is a "prefix".

Yes, but it is not a prefix "identifying the target task or object", since it
identifies a synchronized interface. Once we sort out the problem with target
objects, I think it would be better to use that term here too.

>> Note that 9.5.4(8) and 9.5.4(9) talk about the target task and target
>> protected object, but here we want to talk about the task or PO that
>> implements the synchronized interface (which is not the case when
>> evaluating the prefix).
>> Clarification needed? Or just a "to be honnest"?
>
> Again, there is always a target object, and it is always given
> explicitly as a prefixed view unless this is a requeue on an internal
> entry. We're *not* talking about the task or PO that implements the
> synchronized interface, as that is a *type*, not an *object*. We are
> talking about an instance of that, but that's irrelevant, since it has to have
> a name.

You're probably right, but since you used the term "target object" in your
explanation, why not use it in the wording?

****************************************************************

From: Randy Brukardt
Sent: Monday, February  6, 2012  2:37 AM

> > So in both cases, there is a "prefix".
> Yes, but it is not a prefix "identifying the target task or object",
> since it identifies a synchronized interface. Once we sort out the
> problem with target objects, I think it would be better to use that
> term here too.

No, because that would be recursive. Here we're talking about evaluating the
prefix of the "syntactic" term, which is how we identify the "target object".

I would rather drop this "redundant" text than fix it (does anybody really think
that the prefix would *not* be evaluated), but I view it as insufficiently
broken.

> >> Note that 9.5.4(8) and 9.5.4(9) talk about the target task and
> >> target protected object, but here we want to talk about the task or
> >> PO that implements the synchronized interface (which is not the
> >> case when evaluating the prefix).
> >> Clarification needed? Or just a "to be honnest"?
> >
> > Again, there is always a target object, and it is always given
> > explicitly as a prefixed view unless this is a requeue on an
> > internal entry. We're *not* talking about the task or PO that
> > implements the synchronized interface, as that is a *type*, not an
> > *object*. We are talking about an instance of that, but that's
> > irrelevant, since it has to have a name.
> You're probably right, but since you used the term "target object" in
> your explanation, why not use it in the wording?

Because making unnecessary wording changes exhausts my budget. Especially when
unchanged text is involved. And because it would be wrong: 8 and 9 are talking
specifically about tasks and protected objects, so we have to talk about the
"target task". I suppose we could say something like "the task represented by
the target object", but would that really help anyone??

****************************************************************

From: Randy Brukardt
Sent: Wednesday, February 15, 2012  1:44 AM

I'm working on the AIs for the Houston agenda, and I noticed something I thought
I should improve:

I wrote a couple of weeks ago:

...
> > > So in both cases, there is a "prefix".
> > Yes, but it is not a prefix "identifying the target task or object",
> > since it identifies a synchronized interface. Once we sort out the
> > problem with target objects, I think it would be better to use that
> > term here too.
>
> No, because that would be recursive. Here we're talking about
> evaluating the prefix of the "syntactic" term, which is how we
> identify the "target object".

My answer here is correct, but isn't the best answer to J-P's question.

J-P said:
> Yes, but it is not a prefix "identifying the target task or
> {protected} object", since it identifies a synchronized interface.

But this is false, the prefix has to identify a task or protected object! That
because this is Dynamic Semantics and views are irrelevant: the only thing that
matters is the entity. And that entity is surely going to be a task object or a
protected object; those are the *only* concrete types that can be used as a
synchronized interface; there is no way to create an object of a synchronized
interface type that is *not* a task or protected object. Thus there is nothing
that needs to be changed here (or in paragraphs 8 or 9).

Unfortunately, I didn't realize this sooner, or I could have avoided wasting a
lot of words...

****************************************************************


Questions? Ask the ACAA Technical Agent