!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) @dinsa @xbullet shall resolve to denote an object or value of some task or protected type (after any implicit dereference). The @fa shall resolve to denote an @fa or @fa occurring (implicitly or explicitly) within the visible part of that type. The @fa denotes the corresponding entry, entry family, or protected subprogram.> @dinst @xbullet (after any implicit dereference) shall resolve to denote an object or value of a specific tagged type @i or class-wide type @i'Class. The @fa shall resolve to denote a view of a subprogram declared immediately within the declarative region in which an ancestor of the type @i is declared. The first formal parameter of the subprogram shall be of type @i, or a class-wide type that covers @i, 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 @fa. The @fa denotes a view of this subprogram that omits the first formal parameter. This view is called a @i of the subprogram, and the @fa of the @fa (after any implicit dereference) is called the @i of the prefixed view.> !corrigendum 4.1.3(13) @dinsa If the @fa does not denote a package, then it shall be a @fa or an expanded name, and it shall resolve to denote a program unit (other than a package), the current instance of a type, a @fa, a @fa, or an @fa (in the case of an @fa or @fa, 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 @fa denotes more than one such enclosing callable construct, then the expanded name is ambiguous, independently of the @fa. @dinst @i<@s8> 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 @b or @b, 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) @dprepl @xcode>> @dby @xcode> Control.Seize --@ft<@i< an entry of a protected object (see 9.4)>>> !corrigendum 6.3.1(10) @drepl @xbullet.> @dby @xbullet;> @xbullet !corrigendum 6.4(10) @dinsa For the execution of a subprogram call, the @fa or @fa of the call is evaluated, and each @fa is evaluated (see 6.4.1). If a @fa is used, an implicit @fa is assumed for this rule. These evaluations are done in an arbitrary order. The @fa 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). @dinst If the @fa or @fa 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 @fa of the prefixed view (or the Access attribute of this @fa if the first formal parameter is an access parameter), and the remaining actual parameters given by the @fa, if any. !ACATS test !appendix *************************************************************