Version 1.6 of ais/ai-00407.txt

Unformatted version of ais/ai-00407.txt version 1.6
Other versions for file ais/ai-00407.txt

!standard 4.1.3(09) 05-05-18 AI95-00407/05
!standard 4.1.3(13)
!standard 4.1.3(17)
!standard 6.3.1(10)
!standard 6.4(10)
!class amendment 05-02-07
!status Amendment 200Y 05-03-01
!status ARG Approved 10-0-0 05-02-13
!status work item 05-02-07
!status received 05-02-07
!priority High
!difficulty Easy
!subject Terminology and semantics of prefixed views

!summary

(See proposal.)

!problem

The description of the Obj.Op notation in 4.1.3 is quite confused (and occasionally incorrect) because we do not have a technical term to designate this notation.

A rule must be added in 4.1.3 to make illegal to use this notation when the prefix is a constant and whose first parameter may be modified by the subprogram.

Some of the description in 4.1.3 has to do with calls, not names, and furthermore it's not exactly correct in the presence of renamings.

!proposal

We introduce prefixed view to denote the view of a subprogram denoted by the Obj.Op notation and use this technical term when appropriate.

We add a rule to disallow use of a prefixed view if the prefix is constant and the first parameter is of mode out, in out, or of an access-to-variable type. This rule should be a legality rule, not a name resolution rule, for consistency with what we do for normal calls.

Wording in added in 6.4(10) to explain the dynamic semantics of calls to prefixed views, including calls that go through renamings.

!wording

Change the last sentence of second paragraph added by AI95-00252 after 4.1.3(9) to read:

The selected_component denotes a view of this subprogram that omits the first formal parameter. This view is called a prefixed view of the subprogram, and the prefix of the selected_component (after any implicit dereference) is called the prefix of the prefixed view.

Change the paragraph added by AI95-00252 after 4.1.3(13) to read:

For a subprogram whose first parameter is an access parameter, the prefix of any prefixed view shall denote an aliased view of an object.

For a subprogram whose first parameter is of mode in out or out, or of an anonymous access-to-variable type, the prefix of any prefixed view shall denote a variable.

Remove the paragraph added by AI95-00252 after 4.1.3(15) (it has to do with calls, not names).

Change the example in 4.1.3(17) to: -- This depends on AI-433's examples

X.Append -- a prefixed view of a procedure (see 3.9.4) -- assuming X is an object of Queue'Class

Change the paragraph added by AI95-00252 after 6.3.1(10):

any prefixed view of a subprogram (see 4.1.3).

Add after 6.4(10):

If the name or prefix of a subprogram call denotes a prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the underlying subprogram, with the first actual parameter being provided by the prefix of the prefixed view (or the Access attribute of this prefix if the first formal parameter is an access parameter), and the remaining actual parameters given by the actual_parameter_part, if any.

AARM To Be Honest: The phrase "the underlying subprogram" should really say something like "the subprogram of which the prefixed view is a view". But that gets unwieldy, and the meaning is clear from context.

!discussion

(See proposal.)

!example

(See AI-252 for examples.)

!corrigendum 4.1.3(09)

Insert after the paragraph:

The prefix shall resolve to denote an object or value of some task or protected type (after any implicit dereference). The selector_name shall resolve to denote an entry_declaration or subprogram_declaration occurring (implicitly or explicitly) within the visible part of that type. The selected_component denotes the corresponding entry, entry family, or protected subprogram.

the new paragraph:

A view of a subprogram whose first formal parameter is of a tagged type or is an access parameter whose designated type is tagged:
The prefix (after any implicit dereference) shall resolve to denote an object or value of a specific tagged type T or class-wide type T'Class. The selector_name shall resolve to denote a view of a subprogram declared immediately within the declarative region in which an ancestor of the type T is declared. The first formal parameter of the subprogram shall be of type T, or a class-wide type that covers T, or an access parameter designating one of these types. The designator of the subprogram shall not be the same as that of a component of the tagged type visible at the point of the selected_component. The selected_component denotes a view of this subprogram that omits the first formal parameter. This view is called a prefixed view of the subprogram, and the prefix of the selected_component (after any implicit dereference) is called the prefix of the prefixed view.

!corrigendum 4.1.3(13)

Insert after the paragraph:

If the prefix does not denote a package, then it shall be a direct_name or an expanded name, and it shall resolve to denote a program unit (other than a package), the current instance of a type, a block_statement, a loop_statement, or an accept_statement (in the case of an accept_statement or entry_body, no family index is allowed); the expanded name shall occur within the declarative region of this construct. Further, if this construct is a callable construct and the prefix denotes more than one such enclosing callable construct, then the expanded name is ambiguous, independently of the selector_name.

the new paragraph:

Legality Rules

For a subprogram whose first parameter is an access parameter, the prefix of any prefixed view shall denote an aliased view of an object.

For a subprogram whose first parameter is of mode in out or out, or of an anonymous access-to-variable type, the prefix of any prefixed view shall denote a variable.

!comment corrigendum 4.1.3(15) - the changes in AI-00252 need to be removed.

!comment Handle that in AI-252.

!corrigendum 4.1.3(17)

Replace:

Control.Seize -- an entry of a protected object (see 9.4)

by:

Cashier.Append -- a prefixed view of a procedure (see 3.9.4) Control.Seize -- an entry of a protected object (see 9.4)

!corrigendum 6.3.1(10)

Replace the paragraph:

a subprogram declared immediately within a protected_body.

by:

a subprogram declared immediately within a protected_body;

any prefixed view of a subprogram (see 4.1.3).

!corrigendum 6.4(10)

Insert after the paragraph:

For the execution of a subprogram call, the name or prefix of the call is evaluated, and each parameter_association is evaluated (see 6.4.1). If a default_expression is used, an implicit parameter_association is assumed for this rule. These evaluations are done in an arbitrary order. The subprogram_body is then executed. Finally, if the subprogram completes normally, then after it is left, any necessary assigning back of formal to actual parameters occurs (see 6.4.1).

the new paragraph:

!ACATS test

!appendix


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

Questions? Ask the ACAA Technical Agent