CVS difference for ais/ai-00397.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00397.txt

--- ais/ai-00397.txt	2005/01/28 02:10:51	1.2
+++ ais/ai-00397.txt	2005/04/05 22:05:15	1.3
@@ -1,18 +1,17 @@
-!standard 6.3.1(24.1/2)                                05-01-25  AI95-00397/01
-!standard 9.1(9.3/2)
-!standard 9.1(9.8/2)
-!standard 9.4(11.1/2)
-!standard 9.4(11.6/2)
-!standard 9.4(11.8/2)
+!standard 6.3.1(24)                                    05-03-15  AI95-00397/02
+!standard 9.1(9.1)
+!standard 9.4(11)
 !standard 9.5.2(2)
+!standard 9.5.2(10)
 !standard 9.5.2(13)
 !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 rules and overriding indicators for entries and protected
-operations
+!subject Conformance and overriding for entries and protected operations
 
 !summary
 
@@ -28,24 +27,21 @@
 
 !proposal
 
-Defined the term *prefix 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 we don't have to require that the entry/protected operation
-be a primitive operation. I put this with the definition of entries and
-protected subprograms, because it depends on "implemented" which is defined
-there. Putting it in 8.3 would have created a giant forward reference.
+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.
 
 !wording
 
-Replace 6.3.1(24.1/2) by:
+Replace the paragraph inserted by AI95-00345 after 6.3.1(24) by:
 
-The *prefix profile* of a subprogram is the profile obtained by omitting the
-first parameter of that subprogram. The prefix profile of a parameterless
-subprogram is not conformant with any entry or protected subprogram. For the
-purposes of defining subtype and mode conformance, the convention of a prefix
-profile is considered to match that of either an entry or a protected
-operation.
+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
@@ -53,42 +49,44 @@
 convention as protected operations.
 
 
-Replace 9.1(9.3/2) by:
+Replace the third 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 he task type,
+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
-prefix profile of inherited subprogram, the inherited subprogram is said to be
-implemented by the conforming task entry.
+prefixed view profile of inherited subprogram, the inherited subprogram is
+said to be *implemented* by the conforming task entry.
 
 
-Replace 9.1(9.8/2) by:
+Replace the eighth 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 prefix profile shall be subtype conformant with that of the
-task entry.
+in which case its prefixed view profile shall be subtype conformant with that
+of the task entry.
 
 
-Replace 9.4(11.1/2) by:
+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 prefix
-profile of the inherited subprogram, the inherited subprogram is said to be
-implemented by the conforming protected subprogram or entry.
+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.
 
 
-Replace 9.4(11.6/2) by:
+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 prefix profile shall be subtype
-conformant with that of the protected subprogram or entry.
+entry of the protected type, in which case its prefixed view profile shall be
+subtype conformant with that of the protected subprogram or entry.
 
 
-Add after 9.4(11.8/2):
+Add after the last paragraph inserted by AI95-00345 after 9.4(11):
 
 If a protected subprogram declaration has an overriding_indicator, then:
 
@@ -105,7 +103,11 @@
    [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:
@@ -122,11 +124,175 @@
 
 !discussion
 
-(See proposal.)
+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)
+
+@dinsa
+Two @fa<discrete_subtype_definition>s are @i<fully conformant> if they are
+both @fa<subtype_indication>s or are both @fa<range>s, the @fa<subtype_mark>s
+(if any) denote the same subtype, and the corresponding @fa<simple_expression>s
+of the @fa<range>s (if any) fully conform.
+@dinst
+The @i<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.
+
+!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.>
+
+If neither applies, the inherited subprogram shall be a null procedure.
+
+!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 neither applies, the inherited subprogram is a null procedure.
+
+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:
+
+@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the subprogram shall
+implement an inherited subprogram, at the point of the declaration;>
+
+@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the subprogram shall
+not implement any inherited subprogram (at any point).>
+
+!corrigendum 9.5.2(2)
+
+@drepl
+@xcode<@fa<entry_declaration ::=
+   @b<entry> defining_identifier [(discrete_subtype_definition)] parameter_profile;>>
+@dby
+@xcode<@fa<entry_declaration ::=
+   [overriding_indicator]
+   @b<entry> defining_identifier [(discrete_subtype_definition)] parameter_profile;>>
+
+!corrigendum 9.5.2(10)
+
+@dinsa
+An @fa<entry_declaration> is allowed only in a protected or task declaration.
+@dinst
+An @fa<overriding_indicator> is not allowed in an @fa<entry_declaration> that includes
+a @fa<discrete_subtype_definition>.
+
+!corrigendum 9.5.2(13)
+
+@dinsa
+An @fa<entry_declaration> in a task declaration shall not contain a specification for an access parameter (see 3.10).
+@dinss
+If an @fa<entry_declaration> has an @fa<overriding_indicator>, then:
+
+@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the entry shall implement
+an inherited subprogram, at the point of the declaration;>
 
---!corrigendum
+@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the operation shall not
+implement any inherited subprogram (at any point).>
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent