!standard 4.1.3 (13) 05-02-12 AI95-00407/03 !class amendment 05-02-07 !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 4.1.3(9.2/2) 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 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. 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. Remove 4.1.3(15.1/2) (it has to do with calls, not names). Change 6.3.1(10.1/2): 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 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 --!corrigendum !ACATS test !appendix *************************************************************