Version 1.9 of ais/ai-00397.txt

Unformatted version of ais/ai-00397.txt version 1.9
Other versions for file ais/ai-00397.txt

!standard 6.3.1(24) 05-09-20 AI95-00397/08
!standard 8.3.1(1)
!standard 9.1(9.1)
!standard 9.4(11)
!standard 9.5.2(2)
!standard 9.5.2(10)
!standard 9.5.2(13)
!standard 10.1.1(8)
!class amendment 05-01-25
!status Amendment 200Y 05-03-14
!status ARG Approved 10-0-0 05-02-13
!status work item 05-01-25
!status received 05-01-25
!priority High
!difficulty Easy
!subject Conformance and overriding for entries and protected operations

!summary

(See proposal.)

!problem

6.3.1(24/1) talks about subtype conformance of an entry and a subprogram, but an entry and a subprogram never have the same convention. Furthermore, it would seem that we would want the overriding indicators to be usable for entries and protected subprograms, even though they don't override anything (they implement the parent subprogram).

Finally, if a prefixed view call is made to an operation of a tagged task or protected type, the call could be ambiguous if there is both primitive operations and protected operations or task entries that have the same prefixed view profile.

!proposal

Defined the term prefixed view profile to reduce the verbiage about "omitting the first parameter" and also to resolve the problem of convention matching. Replicated the wording from 8.3 about overriding indicators, with the simplification that entries and protected operations are not primitive operations.

Also, fix the "implemented by" rules to be rechecked in the private part of generic instances (certainly, we want these rules to be enforced everywhere).

Finally, add legality rules to prohibit primitive operations with matching prefixed view profiles.

!wording

Replace the paragraph inserted by AI95-00345 after 6.3.1(24) by:

The prefixed view profile of a subprogram is the profile obtained by omitting the first parameter of that subprogram. There is no prefixed view profile for a parameterless subprogram. For the purposes of defining subtype and mode conformance, the convention of a prefixed view profile is considered to match that of either an entry or a protected operation.

AARM Note: The weird rule about conventions is pretty much required for synchronized interfaces to make any sense. There will be wrappers all over the place anyway. Of course, this doesn't imply that entries have the same convention as protected operations.

Modify the first legality paragraph in the 8.3.1 clause added by AI-218-3 as follows:

If a subprogram_declaration {other than a protected subprogram}, abstract_subprogram, ...

Add a Note to 8.3.1:

Rules for overriding_indicators of task and protected entries and of protected subprograms are found in 9.5.2 and 9.4, respectively.

Replace the second paragraph inserted by AI95-00345 after 9.1(9.1/1) by:

For a task_type_declaration, if the first parameter of a primitive inherited subprogram is of the task type or an access parameter designating the task type, and there is an entry_declaration for a single entry with the same identifier within the task_type_declaration, whose profile is type conformant with the prefixed view profile of inherited subprogram, the inherited subprogram is said to be implemented by the conforming task entry.

Add after the third paragraph inserted by AI95-00345 after 9.1(9.1/2):

The prefixed view profile of an explicitly declared primitive subprogram of a tagged task type shall not be type conformant with any entry of the task type, if the first parameter of the subprogram is of the task type or is an access parameter designating the task type.

Replace the seventh paragraph inserted by AI95-00345 after 9.1(9.1/1) (the second bullet) by:

o the inherited subprogram is implemented by a single entry of the task type; in which case its prefixed view profile shall be subtype conformant with that of the task entry.

Replace the eighth paragraph inserted by AI95-00345 after 9.1(9.1/1) (the second bullet) by:

If neither applies, the inherited subprogram shall be a null procedure. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.

Replace the paragraph inserted by AI95-00345 after 9.4(11) by:

For a protected_type_declaration, if the first parameter of a primitive inherited subprogram is of the protected type or an access parameter designating the protected type, and there is a protected_operation_declaration for a protected subprogram or single entry with the same identifier within the protected_type_declaration, whose profile is type conformant with the prefixed view profile of the inherited subprogram, the inherited subprogram is said to be implemented by the conforming protected subprogram or entry.

Add after the third paragraph inserted by AI95-00345 after 9.4(11):

The prefixed view profile of an explicitly declared primitive subprogram of a tagged protected type shall not be type conformant with any protected operation of the protected type, if the first parameter of the subprogram is of the protected type or is an access parameter designating the protected type.

Replace the sixth paragraph inserted by AI95-00345 after 9.4(11) (the second bullet) by:

o the inherited subprogram is implemented by a protected subprogram or single entry of the protected type, in which case its prefixed view profile shall be subtype conformant with that of the protected subprogram or entry.

Replace the seventh paragraph inserted by AI95-00345 after 9.4(11) by:

Add after the last paragraph inserted by AI95-00345 after 9.4(11):

If a protected subprogram declaration has an overriding_indicator, then at the point of declaration:

o if the overriding_indicator is overriding, then the subprogram shall

implement an inherited subprogram;

o if the overriding_indicator is not overriding, then the subprogram shall

not implement any inherited subprogram.

In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.

Change 9.5.2(2) to read:

entry_declaration ::= [overriding_indicator] entry defining_identifier [(discrete_subtype_definition)] parameter_profile;

Add after 9.5.2(10):

An overriding_indicator is not allowed in an entry_declaration that includes a discrete_subtype_definition.

Add after 9.5.2(13):

If an entry_declaration has an overriding_indicator, then at the point of declaration:

o if the overriding_indicator is overriding, then the entry shall implement

an inherited subprogram, at the point of the declaration;

o if the overriding_indicator is not overriding, then the entry shall not

implement any inherited subprogram.

In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.

AARM Note: An entry family never implements anything, so only not overriding can be given on the declaration of a family.

Added after 10.1.1(8):

An overriding_indicator is not allowed in a subprogram_declaration, generic_instantiation, or subprogram_renaming_declaration that declares a library unit.

AARM Note: A library unit can never override anything.

!discussion

The wording for overriding indicators applied to entries and protected subprograms was put this the definition of entries and protected subprograms, respectively, because it depends on the technical term "implemented" which is defined there. Putting it in 8.3 would have created a giant forward reference.

!example

Here is a simple readers and writers interface:

type RW is limited interface; procedure Write (Obj : out RW; X : Integer) is abstract; procedure Read (Obj : RW; X : out Integer) is abstract;

This interface may be implemented by a protected object. In order to allow several readers to proceed in parallel, the Read subprogram is implemented by a non-protected procedure that calls a protected function. The Write subprogram is directly implemented by a protected procedure:

protected type Prot_RW is new RW with overriding procedure Write (X : Integer); not overriding function Read return Integer; private V : Integer; end Prot_RW;

overriding procedure Read (Obj : Prot_RW; X : out Integer);

(Credits: this example was shamelessly stolen from John Barnes' Rationale document.)

!corrigendum 6.3.1(24)

Insert after the paragraph:

Two discrete_subtype_definitions are fully conformant if they are both subtype_indications or are both ranges, the subtype_marks (if any) denote the same subtype, and the corresponding simple_expressions of the ranges (if any) fully conform.

the new paragraph:

!corrigendum 8.3.1(1)

!comment This is a dummy just to cause a conflict.

@dinsa @dinss If a @fa<subprogram_declaration> {other than a protected subprogram}, @fa<abstract_subprogram>, ...

!corrigendum 9.1(9.1/1)

!comment This includes the wording change from AI-401 (deleting a paragraph).

@dinsa For a task declaration without a @fa<task_definition>, a @fa<task_definition> without @fa<task_item>s is assumed. @dinss For a @fa<task_type_declaration>, if the first parameter of a primitive inherited subprogram is of the task type or an access parameter designating the task type, and there is an @fa<entry_declaration> for a single entry with the same identifier within the @fa<task_type_declaration>, whose profile is type conformant with the prefixed view profile of inherited subprogram, the inherited subprogram is said to be @i<implemented> by the conforming task entry.

@i<@s8<Legality Rules>>

A task declaration requires a completion, which shall be a @fa<task_body>, and every @fa<task_body> shall be the completion of some task declaration.

Each @fa<interface_subtype_mark> of an @fa<interface_list> appearing within a @fa<task_type_declaration> shall denote a limited interface type that is not a protected interface.

For each primitive subprogram inherited by the type declared by a @fa<task_type_declaration>, at most one of the following shall apply:

@xbullet<the inherited subprogram is overridden with a primitive subprogram of the task type, in which case the overriding subprogram shall be subtype conformant with the inherited subprogram and not abstract; or>

@xbullet<the inherited subprogram is implemented by a single entry of the task type; in which case its prefixed view profile shall be subtype conformant with that of the task entry.>

!corrigendum 9.4(11)

!comment This includes the wording change from AI-401 (deleting a paragraph).

@dinsa A @fa<protected_definition> defines a protected type and its first subtype. The list of @fa<protected_operation_declaration>s of a @fa<protected_definition>, together with the @fa<known_discriminant_part>, if any, is called the visible part of the protected unit. The optional list of @fa<protected_element_declaration>s after the reserved word @b<private> is called the private part of the protected unit. @dinss For a @fa<protected_type_declaration>, if the first parameter of a primitive inherited subprogram is of the protected type or an access parameter designating the protected type, and there is a @fa<protected_operation_declaration> for a protected subprogram or single entry with the same identifier within the @fa<protected_type_declaration>, whose profile is type conformant with the prefixed view profile of the inherited subprogram, the inherited subprogram is said to be @i<implemented> by the conforming protected subprogram or entry.

@i<@s8<Legality Rules>>

A protected declaration requires a completion, which shall be a @fa<protected_body>, and every @fa<protected_body> shall be the completion of some protected declaration.

Each @fa<interface_subtype_mark> of an @fa<interface_list> appearing within a @fa<protected_type_declaration> shall denote a limited interface type that is not a task interface.

For each primitive subprogram inherited by the type declared by a @fa<protected_type_declaration>, at most one of the following shall apply:

@xbullet<the inherited subprogram is overridden with a primitive subprogram of the protected type, in which case the overriding subprogram shall be subtype conformant with the inherited subprogram and not abstract; or>

@xbullet<the inherited subprogram is implemented by a protected subprogram or single entry of the protected type, in which case its prefixed view profile shall be subtype conformant with that of the protected subprogram or entry.>

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 @b<out> or @b<in out>, or an access-to-variable parameter.

If a protected subprogram declaration has an @fa<overriding_indicator>, then at the point of the declaration:

@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the subprogram shall implement an inherited subprogram;>

@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the subprogram shall not implement any inherited subprogram.>

In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.

!corrigendum 9.5.2(2)

Replace the paragraph:

entry_declaration ::= entry defining_identifier [(discrete_subtype_definition)] parameter_profile;

by:

entry_declaration ::= [overriding_indicator] entry defining_identifier [(discrete_subtype_definition)] parameter_profile;

!corrigendum 9.5.2(10)

Insert after the paragraph:

An entry_declaration is allowed only in a protected or task declaration.

the new paragraph:

An overriding_indicator is not allowed in an entry_declaration that includes a discrete_subtype_definition.

!corrigendum 9.5.2(13)

Insert after the paragraph:

An entry_declaration in a task declaration shall not contain a specification for an access parameter (see 3.10).

the new paragraphs:

If an entry_declaration has an overriding_indicator, then at the point of the declaration:

if the overriding_indicator is overriding, then the entry shall implement an inherited subprogram;

if the overriding_indicator is not overriding, then the entry shall not implement any inherited subprogram.

In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.

!corrigendum 10.1.1(8)

Insert after the paragraph:

parent_unit_name ::= name

the new paragraph:

An overriding_indicator is not allowed in a subprogram_declaration, generic_instantiation, or subprogram_renaming_declaration that declares a library unit.

!ACATS test

ACATS B-Test(s) should be created to check that overriding indicators are allowed and enforced here.

!appendix

From: Bob Duff
Sent: Monday, June 6, 2005  12:40 PM

I'm using draft 11.8 of the [A]ARM.

6.3.1(24.1/2):

24.1/2 {AI95-00345-01} {AI95-00397-01} {prefixed view profile} The prefixed
view profile of a subprogram is the profile obtained by omitting the first
parameter of that subprogram. There is no prefixed view profile for a
parameterless subprogram. For the purposes of defining subtype and mode
conformance, the convention of a prefixed view profile is considered to match
that of either an entry or a protected operation.

I find this wording confusing.  Does it mean that it can't match a
run-of-the-mill subprogram?  Would it be clearer to delete that last sentence,
and add something to the definition of subtype conformance?  Like,
"However, the associated calling conventions need not be the same in the case
of a prefixed view profile."  Or add "(unless one or both are prefixed view
profiles)"  before "the associated calling conventions are the same"
in:

17    {subtype conformance} {profile (subtype conformant)} Two profiles are
subtype conformant if they are mode-conformant, corresponding subtypes of the
profile statically match, and the associated calling conventions are the same.
The profile of a generic formal subprogram is not subtype-conformant with any
other profile. {statically matching (required) [partial]}

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

From: Tucker Taft
Sent: Monday, June 6, 2005  7:33 PM

I agree this wording should be improved.  I believe it
used to say that the prefixed-view profile was
considered to be of an intrinsic convention.  It was
changed to help simplify the rules for what it means
for a primitive to be "implemented by" a protected
operation or a task entry, but it seems harder to
understand as a result.

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

From: Randy Brukardt
Sent: Monday, June 6, 2005  9:11 PM

> I agree this wording should be improved.

Please suggest something!

> I believe it
> used to say that the prefixed-view profile was
> considered to be of an intrinsic convention.

No, you're confusing a "prefixed view" (which is a @fa<name>) and a
"prefixed view profile".

> It was
> changed to help simplify the rules for what it means
> for a primitive to be "implemented by" a protected
> operation or a task entry, but it seems harder to
> understand as a result.

No, it never existed before. It was *created* to do what you explain.

> Bob Duff wrote:
> > 6.3.1(24.1/2):
> >
> > 24.1/2 {AI95-00345-01} {AI95-00397-01} {prefixed view profile} The
prefixed
> > view profile of a subprogram is the profile obtained by omitting the
first
> > parameter of that subprogram. There is no prefixed view profile for a
> > parameterless subprogram. For the purposes of defining subtype and mode
> > conformance, the convention of a prefixed view profile is considered to
match
> > that of either an entry or a protected operation.
> >
> > I find this wording confusing.  Does it mean that it can't match a
> > run-of-the-mill subprogram?

Right, because this is only used for "implemented by" subprograms for tasks
and protected types with interfaces. I don't know of any uses for it
otherwise.

> Would it be clearer to delete that last sentence,
> > and add something to the definition of subtype conformance?  Like,
> > "However, the associated calling conventions need not be the same in the
> > case of a prefixed view profile."  Or add "(unless one or both are
> > prefixed view profiles)"  before "the associated calling conventions
> > are the same"

I don't know quite how that would work. Every subprogram has a prefixed view
profile, but we're only interested in them in a few cases. This difference
only applies when we're explicitly matching a prefixed view profile to
something, not any time that a prefixed view profile might be around (which
is almost always). It seems better to me to keep it localized. But feel free
to suggest something that has the right effect.

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

From: Bob Duff
Sent: Monday, June 6, 2005  9:17 PM

> I don't know quite how that would work. Every subprogram has a prefixed view
> profile, ...

unless it has zero parameters.

>...but we're only interested in them in a few cases. This difference
> only applies when we're explicitly matching a prefixed view profile to
> something, not any time that a prefixed view profile might be around (which
> is almost always). It seems better to me to keep it localized. But feel free
> to suggest something that has the right effect.

Sorry, I don't understand the issue well enough to propose any more
suggested wordings.  Maybe after I've read up through chapter 9?

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

From: Randy Brukardt
Sent: Monday, June 6, 2005  11:08 PM

Perhaps. Or maybe I'm just too close to understand the global implications
(that's why you're reviewing this, after all).

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

From: Pascal Leroy
Sent: Tuesday, June 7, 2005  3:38 AM

> I find this wording confusing.  Does it mean that it can't
> match a run-of-the-mill subprogram?

Yes.

>  Would it be clearer to
> delete that last sentence, and add something to the
> definition of subtype conformance?  Like,
> "However, the associated calling conventions need not be the
> same in the case of a prefixed view profile."

I'm not sure if it would be clearer, but it would be incorrect, because we
strictly want to restrict ourselves to entry and protected.

This is wording that has been very carefully crafted, and we went through
numerous iterations where the conformance rules for "implemented by"
subprograms were just plain wrong.  The wording may be confusing, but as
far as I know it is correct.  Feel free to propose improvements to the
English, but make sure you don't break anything.

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

From: Pascal Leroy
Sent: Tuesday, June 7, 2005  3:44 AM

> I agree this wording should be improved.  I believe it
> used to say that the prefixed-view profile was
> considered to be of an intrinsic convention.  It was
> changed to help simplify the rules for what it means
> for a primitive to be "implemented by" a protected
> operation or a task entry, but it seems harder to
> understand as a result.

You are confused my friend.  You are mixing "prefixed view" with "prefixed
view profile".  Anyway, if you think the wording should be improved,
propose something...

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

From: Pascal Leroy
Sent: Tuesday, June 7, 2005  4:02 AM

> > I don't know quite how that would work. Every subprogram has a
> > prefixed view profile, ...
>
> unless it has zero parameters.

And that's OK: since it has no prefixed view profile, surely this profile
doesn't conform to anything, and therefore cannot be "implemented by"
anything, which is just what we want.

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

Questions? Ask the ACAA Technical Agent