Version 1.7 of ais/ai-00407.txt

Unformatted version of ais/ai-00407.txt version 1.7
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


From: Pascal Leroy
Sent: Saturday, February 12, 2005  3:03 PM

Attached is my update of AI 407 following today's discussion.

[This is version /03 of the AI - ED]

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

From: Bob Duff
Sent: Saturday, February 12, 2005  4:28 PM

...
> The description of the Obj.Op notation in 4.1.3 is quite confused

What a tangled web we weave, when first we practise to deceive
people into thinking Ada is C++ or Java.  ;-)

> !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.

See below about the acc-to-var case.

> 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 4.1.3(9.2/2) to read:

The "/2" notation refers to the Ada 2005 version of the RM, right?  So
it seems confusing to write an AI that refers to "/2" paragraphs, since
they're going to change without getting a new version number.  It seems
like AIs ought to refer to other AIs, or to words in the "/1" version of
the RM.

In other words, if somebody looks at this AI after it has been
incorporated into the RM, will it still make sense, given that
it refers to words that have disappeared from the face of the Earth?

> 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 4.1.3(13.1/2) 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.

Is that correct?

    procedure P(X: access Integer);
    type A is access all Integer;
    Y: constant A := ...;
    Y.P; -- legal?

Is Y.P legal?  Is there an implicit dereference here?
If not, then Y is the prefix, and it's not aliased.

> Add after 4.1.3(13.1/2):
>
> 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.

Same question here.  Y is constant, but that's OK.

Maybe I'm confused...

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

From: Tucker Taft
Sent: Sunday, February 13, 2005  2:30 AM

...
> In other words, if somebody looks at this AI after it has been
> incorporated into the RM, will it still make sense, given that
> it refers to words that have disappeared from the face of the Earth?

Good point.  Unfortunately, these AIs are referring
to the RM under review, and it would be inefficient
to refer to the original RM wording.  We will somehow
need to preserve the state of the RM that the AI is
based on.

...
> Is that correct?
>
>     procedure P(X: access Integer);
>     type A is access all Integer;
>     Y: constant A := ...;
>     Y.P; -- legal?
>
> Is Y.P legal?  Is there an implicit dereference here?

An implicit dereference always occurs when you use
a prefix that is an access value, and then we turn
around and add the "'Access" back in if the first
parameter is an access parameter.

> If not, then Y is the prefix, and it's not aliased.

"Y.all" is the prefix (semantically).

...
> Same question here.  Y is constant, but that's OK.
>
> Maybe I'm confused...

You're confused.  See the definition of "prefix".

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

Questions? Ask the ACAA Technical Agent