Version 1.2 of ai05s/ai05-0215-1.txt
!standard 9.5(18/3) 10-10-25 AI05-0215-1/01
!standard 9.5.4(3/3)
!standard 9.5.4(5/3)
!standard 9.5.4(5.1/3)
!class binding interpretation 10-06-12
!status work item 10-06-12
!status received 10-03-26
!priority Low
!difficulty Easy
!qualifier Omission
!subject Errors in AI05-0030-2
!summary
*** TBD ***
!question
(1) I don't see any rule that says that you can't write two
Implemented pragmas for the same subprogram. (If the Standard
said that Implemented were a representation pragma, as it does
for No_Return, this would follow automatically; but it doesn't
say that anywhere.)
(2) The pragma doesn't make sense unless Implemented pragmas
explicitly specified for subprograms apply to inherited
subprograms. But there is no wording to that effect in the Standard.
3.9.2(10) says explicitly that the convention was inherited for
some inherited subprograms, so similar wording is needed
for Implemented (and No_Return as well).
(3) 9.5.4(3/3) says:
"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."
But this makes no sense for a procedure; the procedure has to have
a first parameter that is of a synchronized type. So there can't be
a procedure with no parameters here. Moreover, because of this
first parameter, the profile can't conform with the enclosing entry.
Probably it is the prefixed view profile that has to conform.
Similar problems arise in 9.5.4(5/3).
!recommendation
(See Summary.)
!wording
Modify 9.5(18/3) as follows:
A pragma Implemented {is a representation pragma, and} is [said to
apply to]{specifies the Implemented aspect of} the procedure denoted
by its procedure_local_name. {Inherited subprograms inherit the
Implemented aspect, if any, from the corresponding subprogram of the
parent or progenitor type.} If an overriding operation does not have
a [pragma] {directly specified} Implemented {aspect} then [any pragma
Implemented applying to] {Implemented aspect of} the inherited
operation [applies to] {is inherited by} the overriding operation.
Modify 9.5.4(3/3) as follows:
The procedure_or_entry_name of a requeue_statement shall resolve to
denote a procedure or an entry (the requeue target){. The profile of
the entry, or the profile or prefixed profile of the procedure, shall}
[that] either [has] {have} no parameters, or [that has a profile that
is] {be} type conformant (see 6.3.1) with the profile of the innermost
enclosing entry_body or accept_statement.
Modify 9.5.4(5/3) as follows:
If the requeue target has parameters, then its {(prefixed)} profile
shall be subtype conformant with the profile of the innermost
enclosing callable construct.
Modify 9.5.4(5.1/3) as follows:
If the target is a procedure, the name shall denote a rename of an
entry, or shall denote {a view or} 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 [an] {the} Implemented [pragma] {aspect shall be
specified} with implementation_kind By_Entry [shall apply to] {for}
the primitive subprogram.
!discussion
!ACATS Test
!appendix
!topic Missing rules in Implemented definition?
!reference 9.5(10-18)
!from Adam Beneschan 10-03-26
!discussion
(1) I don't see any rule that says that you can't write two
Implemented pragmas for the same subprogram. (If the RM said that
Implemented were a representation pragma, as it does for
No_Return, I think this would follow automatically; but I don't
think it says that anywhere.)
(2) The pragma doesn't make sense unless Implemented pragmas
explicitly specified for subprograms apply to inherited
subprograms. However, I haven't found anywhere in the RM that
says that pragmas that apply to subprograms automatically apply to
inherited subprograms. Nothing in 3.4 (which is the main place
subprogram inheritance is discussed) says anything about
subprograms inheriting anything other than the name and profile.
In 3.9.2(10), it appears that it was deemed necessary to say
explicitly that the convention was inherited for some inherited
subprograms. So I think that somewhere, either 9.5 should say
that if Implemented applies to a subprogram it applies to an
inherited subprogram (and 6.5.1 needs to say something similar
about No_Return), or there needs to be a more general statement
about what properties or characteristics are inherited by an
inherited subprogram.
****************************************************************
!topic Errors in AI05-0030-2
!reference 9.5.4
!from Adam Beneschan 10-03-30
!discussion
There appear to be some errors in the changes made for AI05-0030-2.
9.5.4(3/3): "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."
First of all, I note that in the online version
(www.adaic.org/standards/1zaarm/html/AA-9-5-4.html), the paragraph didn't
get updated correctly; it says "denote an entry" rather than "denote a
procedure or entry" which of course defeats the whole purpose. But this
error isn't worth changing since the whole paragraph is wrong anyway. If
the procedure_or_entry_name denotes a procedure, doesn't it have to denote
a procedure whose first parameter is a synchronized interface type (or access-to-)?
If that's the case, than it certainly can't resolve to a procedure with
no parameters.
Also, if it's a procedure, its profile can't be type conformant with that
of the enclosing entry; rather, isn't it the procedure's *prefixed view
profile* that has to be type conformant? So I think this just needs to
be redone. I'm not sure exactly how, since I don't know what you want to
put in a Name Resolution Rule.
9.5.4(5/3) has the same problem: "If the requeue target has parameters, then
its profile shall be subtype conformant with the profile of then innermost
enclosing callable construct"---again, if the requeue target is a procedure,
the prefixed view profile is what has to be subtype conformant. Also, if
the requeue target is a procedure with *one* parameter, then this rule
wouldn't apply---the one parameter is the controlling synchronized interface
parameter, but otherwise it should be treated like a parameterless entry.
So maybe this needs to be something like
If the requeue target is an entry that has parameters, then its
profile shall be subtype conformant with the profile of the
innermost enclosing callable construct. If the requeue target is
a prefixed view of primitive subprogram [procedure] of a
synchronized interface, and if the subprogram has more than one
parameter, then its prefixed view profile shall be subtype
conformant with the profile of the innermost enclosing callable
construct.
****************************************************************
Questions? Ask the ACAA Technical Agent