CVS difference for ais/ai-00117.txt

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

--- ais/ai-00117.txt	1998/09/30 00:17:19	1.1
+++ ais/ai-00117.txt	1999/03/04 20:41:37	1.2
@@ -1,4 +1,4 @@
-!standard 03.09.02 (10)                               97-03-19  AI95-00117/02
+!standard 03.09.02 (10)                               99-02-06  AI95-00117/03
 !class binding interpretation 96-04-04
 !status work item 96-04-04
 !status received 96-04-04
@@ -6,30 +6,24 @@
 !difficulty Hard
 !subject Calling Conventions
 
-!summary 96-11-18
+!summary 99-02-06
 
-????At the Vermont ARG meeting, it was suggested that:
+Unless specified otherwise in the RM, the default convention of any
+entity is Ada.
 
-    By default, the convention of a dispatching op should be same as the
-    type.
+An inherited or overriding subprogram of a type extension inherits the
+calling convention of the parent subprogram.
 
-    Type extensions should inherit their convention from the parent type.
+New operations of type extensions have the convention of their type
+unless a new convention is defined for the operation, if this is
+supported by an implementation.
 
-    The Discussion should mention that it's legitimate to reject
-    convention Ada on added subprograms.  Or on the extended type.
+The convention of the partial view of a private type or private
+extension is the convention of the full type.
 
-???However, I don't think this is viable -- see the Appendix.
-In any case, this AI has been only partly updated after the Vermont
-meeting, pending discussion of these points.
-
-----------------
-
-An inherited or overriding subprogram inherits the calling convention of
-the parent subprogram.
-
 An explicitly declared dispatching operation shall not have convention
-Intrinsic.  An implicitly declared dispatching "/=" operator has
-convention Intrinsic, and this is legal.
+Intrinsic.  An implicitly declared dispatching "/=" operator with
+boolean result has convention Intrinsic, and this is legal.
 
 !question 96-11-18
 
@@ -42,43 +36,43 @@
   are defined by the language:
 
       3  The default calling convention for any subprogram not listed
-	 below is Ada.  A pragma Convention, Import, or Export may be used
-	 to override the default calling convention (see B.1).
+         below is Ada.  A pragma Convention, Import, or Export may be used
+         to override the default calling convention (see B.1).
 
       4  The Intrinsic calling convention represents subprograms that are
-	 ``built in'' to the compiler.  The default calling convention is
-	 Intrinsic for the following:
+         ``built in'' to the compiler.  The default calling convention is
+         Intrinsic for the following:
 
-	     5  an enumeration literal;
+             5  an enumeration literal;
 
-	     6  a "/=" operator declared implicitly due to the declaration
-		of "=" (see 6.6);
+             6  a "/=" operator declared implicitly due to the declaration
+                of "=" (see 6.6);
 
-	     7  any other implicitly declared subprogram unless it is a
-		dispatching operation of a tagged type;
+             7  any other implicitly declared subprogram unless it is a
+                dispatching operation of a tagged type;
 
-	     8  an inherited subprogram of a generic formal tagged type
-		with unknown discriminants;
+             8  an inherited subprogram of a generic formal tagged type
+                with unknown discriminants;
 
-	     9  an attribute that is a subprogram;
+             9  an attribute that is a subprogram;
 
-	    10  a subprogram declared immediately within a protected_body.
+            10  a subprogram declared immediately within a protected_body.
 
-	 11   The Access attribute is not allowed for Intrinsic
-	 subprograms.
+         11   The Access attribute is not allowed for Intrinsic
+         subprograms.
 
      12  The default calling convention is protected for a protected
-	 subprogram, and for an access-to-subprogram type with the
-	 reserved word protected in its definition.
+         subprogram, and for an access-to-subprogram type with the
+         reserved word protected in its definition.
 
      13  The default calling convention is entry for an entry.
 
-----------------
+- ----------------
 
 1. What is the default convention of an entity not covered by 6.3.1,
 such as a record type?  (Ada.)
 
-----------------
+- ----------------
 
 2. Does an inherited or overriding subprogram have (by default) the same
 convention as the parent subprogram?  (Yes.)
@@ -111,14 +105,14 @@
 These paragraphs seem to imply that an inherited subprogram inherits the
 calling convention of its parent, as part of the inherited profile.
 
-----------------
+- ----------------
 
 3. Is an implicitly declared dispatching "/=" operator legal?  (Yes.)
 
 Paragraph 3.9.1(1) says that the primitive subprograms of a tagged
-type are called dispatching operations.  Paragraph 3.9.2(10) goes 
-on to say that a dispatching operation shall not be of convention 
-Intrinsic.  However, paragraph 6.3.1(6) says that "/=" declared 
+type are called dispatching operations.  Paragraph 3.9.2(10) goes
+on to say that a dispatching operation shall not be of convention
+Intrinsic.  However, paragraph 6.3.1(6) says that "/=" declared
 implicitly due to the declaration of "=" is of convention Intrinsic,
 by default.
 
@@ -130,28 +124,41 @@
 
 (See summary.)
 
-!wording 96-04-04
+!wording 99-02-06
 
-Add a bullet after 6.3.1(13):
-The default calling convention for any inherited or overriding
-subprogram not listed above is that of the parent subprogram.
+Add two bullets after 6.3.1(13):
+"If not listed above, the calling convention for any inherited
+or overriding dispatching operation of a tagged type is that
+of the corresponding subprogram of the parent type. The
+default calling convention for a new dispatching operation
+of a tagged type is the convention of the full view of the type.
 
-3.9.2(10) should say:
-An explicitly declared dispatching operation shall not have convention
-Intrinsic.
+The default convention of any entity not listed above is Ada."
+
+Add a Note to 6.3.1.:
+"An implementation need not support a pragma Convention on a
+new dispatching operation that specifies a convention different
+from the convention of the type or its other dispatching operations."
+
 
-!discussion 96-11-18
+The last two sentences of 3.9.2(10) should be replaced by:
+"The convention of an inherited or overriding dispatching operation
+is the convention of the inherited operation. An explicitly declared
+dispatching operation shall not have convention Intrinsic."
 
+
+!discussion 99-02-05
+
 Note: This AI subsumes AI95-00065.
 
-----------------
+- ----------------
 
 1. The default convention ought to be Ada for any entity not covered by
 6.3.1.  The dispatching operations of a type ought to inherit the
 convention of the type, for convenient interfacing to other OOP
 languages.  (See below for more discussion of this point.)
 
-----------------
+- ----------------
 
 2. It is important that Ada allow clean interfaces to other programming
 languages.  In particular, it is important that Ada's tagged types can
@@ -159,17 +166,17 @@
 
 If an Ada 95 implementation is tightly integrated with another
 language, such as C++ or Java, it is nice if an Ada tagged type
-can be declared as an extension of a (foreign) type (or class) of the 
-other language.  Presumably, all of the dispatching operations of this 
+can be declared as an extension of a (foreign) type (or class) of the
+other language.  Presumably, all of the dispatching operations of this
 foreign type would be defined as imported, with the convention of
-that other language.  When defining the type extension in Ada, it 
+that other language.  When defining the type extension in Ada, it
 would be very inconvenient if every overriding would have to have
 a pragma Convention on it to match that of the inherited operation,
 as required by 3.9.2(10).
 
 Hence, it seems appropriate to define the default calling convention
-of an overriding of an inherited dispatching operation to be the same as 
-that of the corresponding operation on the parent type, rather than 
+of an overriding of an inherited dispatching operation to be the same as
+that of the corresponding operation on the parent type, rather than
 always being convention "Ada" as specified in 6.3.1(3).
 
 For example:
@@ -193,18 +200,74 @@
 a dispatching operation with convention Java.  Anything else would be
 illegal by 3.9.2(10), and it seems silly to require the programmer
 to litter their program with redundant "pragma Convention"s.
+
+The Note B.1(42) - derived from 13.1 - implies permission of
+implementation-defined restrictions of interfacing pragmas. Hence an
+implementation will be allowed to reject the attempt to create
+"heterogeneous" tagged types, i.e., types having primitive operations
+of different, explicitly specified conventions or of explicity
+specified conventions different from the convention of the type.
+
+- ----------------
+2.a. The "Breach of Privacy" Issue
+
+Presently, the convention of a primitive subprogram can be specified
+in the private part of the declaring package. The current rules
+require explicit confirmation of this convention for overriding
+subprograms and thus constitute a breach of the privacy of the private
+part, since the user needs to know about this privately specified
+convention in order to make the overriding declaration legal.
+
+We are very reluctant to mandate Convention pragmas in the visible part
+of the package. Although such a rule might be derivable from freezing
+rules, it nevertheless could create a compatibility problem for existing
+code.
+
+The proposed new rule of inheriting the convention eases, but does not
+eliminate, the breach of privacy, as any explicitly specified convention
+will still need to confirm the inherited convention.
+
+At the implementation level, both the existing and the proposed model
+breach the private part, as subtype conformance of overriding with
+inherited subprograms includes checking for equality of the convention.
+
+- ----------------
+2.b. Deriving the convention of operations from the type
+
+Having dispatching operations with the convention of some
+other OOP language, while the type is not represented according to the
+convention of this other language, will be almost impossible to
+implement.  The "normal" case will be that both type and operations
+need the convention pragma. In this context, it makes little sense
+that the convention of primitive operations defaults to Ada rather
+than to the convention of their type. The user will be forced to
+repeat the pragma for all the operations of the type.  Considerably
+more convenient is a model, in which the default convention of
+dispatching operations is inherited from the type, but overridable if
+the implementation allows for such mixed conventions.
+
+Since current rules imply that the convention of a type needs to be
+specified for the full view of the type, such dependency creates yet
+another breach of privacy in the case of private tagged types. However,
+the breach already exists as explained in 2.a. and to then exploit it
+for more convenience to the user and a cleaner overall model seems
+justified.
+
+Mandating the specification of the convention for the partial view in
+order to avoid the breach of privacy seems too much of an
+incompatibility for existing code.
 
-----------------
+- ----------------
 
 3. Clearly, an implicitly declared dispatching "/=" should not
 automatically be illegal.
 
-The above wording precludes declaring a dispatching operation by
+The proposed new wording precludes declaring a dispatching operation by
 renaming the Intrinsic "/=", which is good (since there is no real body
 associated with "/=").  It does not make "/=" itself illegal, which is
 also good.
 
-The reason for 6.3.1(4-10) making various subprogram Intrinsic, is that
+The reason for 6.3.1(4-10) making various subprograms Intrinsic is that
 these subprograms don't really exist in machine code.  For example, an
 implementation would typically not generate any code for the
 implicitly-declared "/=" operator -- instead, it would call the "="
@@ -225,13 +288,13 @@
         type Root is tagged null record;
         procedure Proc(X: Root);
     end P;
-    
+
     generic
         type Formal(<>) is new Root with private;
     package G is
         ...
     end G;
-    
+
     package body G is
         ...
         X: Formal := ...;
@@ -242,7 +305,7 @@
         -- Proc'Access would be illegal here, because it is of
         -- convention Intrinsic, by 6.3.1(8).
     end G;
-    
+
     type Actual is new Root with ...;
     procedure Proc(X: Actual);
     package Instance is new G(Formal => Actual'Class);
@@ -271,9 +334,9 @@
 !discussion
 
 Paragraph 3.9.1(1) says that the primitive subprograms of a tagged
-type are called dispatching operations.  Paragraph 3.9.2(10) goes 
-on to say that a dispatching operation shall not be of convention 
-Intrinsic.  However, paragraph 6.3.1(6) says that "/=" declared 
+type are called dispatching operations.  Paragraph 3.9.2(10) goes
+on to say that a dispatching operation shall not be of convention
+Intrinsic.  However, paragraph 6.3.1(6) says that "/=" declared
 implicitly due to the declaration of "=" is of convention Intrinsic.
 
 Together these imply that the "/=" implicitly declarated due to the
@@ -288,7 +351,7 @@
 associated with "/=").  It does not make "/=" itself illegal,
 which is also good.
 
--Tuck
+- -Tuck
 
 ****************************************************************
 
@@ -302,17 +365,17 @@
 
 If an Ada 95 implementation is tightly integrated with another
 language, such as C++ or Java, it is nice if an Ada tagged type
-can be declared as an extension of a (foreign) type (or class) of the 
-other language.  Presumably, all of the dispatching operations of this 
+can be declared as an extension of a (foreign) type (or class) of the
+other language.  Presumably, all of the dispatching operations of this
 foreign type would be defined as imported, with the convention of
-that other language.  When defining the type extension in Ada, it 
+that other language.  When defining the type extension in Ada, it
 would be very inconvenient if every overriding would have to have
 a pragma Convention on it to match that of the inherited operation,
 as required by 3.9.2(10).
 
 Hence, it seems appropriate to define the default calling convention
-of an overriding of an inherited dispatching operation to be the same as 
-that of the corresponding operation on the parent type, rather than 
+of an overriding of an inherited dispatching operation to be the same as
+that of the corresponding operation on the parent type, rather than
 always being convention "Ada" as specified in 6.3.1(3).
 
 For example:
@@ -337,7 +400,7 @@
 illegal by 3.9.2(10), and it seems silly to require the programmer
 to litter their program with redundant "pragma Convention"s.
 
--Tuck
+- -Tuck
 
 ****************************************************************
 
@@ -354,8 +417,8 @@
 Tucker wrote:
 
 > Hence, it seems appropriate to define the default calling convention
-> of an overriding of an inherited dispatching operation to be the same as 
-> that of the corresponding operation on the parent type, rather than 
+> of an overriding of an inherited dispatching operation to be the same as
+> that of the corresponding operation on the parent type, rather than
 > always being convention "Ada" as specified in 6.3.1(3).
 
 AI-117 responds to this issue.
@@ -402,7 +465,7 @@
 overriding operation really has little to do with what it overrides,
 except that it hides it.
 
-- Bob
+- - Bob
 
 
 ****************************************************************
@@ -418,9 +481,9 @@
 !reference 96-5775.a Erhard Ploedereder  96-11-28>>
 !discussion
 
-In 96-5759.a, Bob argues that the rules proposed in the AI and some 
+In 96-5759.a, Bob argues that the rules proposed in the AI and some
 improvements suggested at the recent meeting all share the problem
-that they violate the privacy principles of Ada. 
+that they violate the privacy principles of Ada.
 
 This is true. However, the current ARM semantics do so in the very same way
 by requiring the user to specify a pragma on inherited primitive operations,
@@ -436,8 +499,8 @@
 > for access-to-subprogram types.  Should it not also define the default
 > convention for everything else (e.g. record types)?
 
-Very good point and it does need to be addressed. (Wouldn't this be a 
-natural fall-out of implicit inheritance of Convention from types, as I 
+Very good point and it does need to be addressed. (Wouldn't this be a
+natural fall-out of implicit inheritance of Convention from types, as I
 understood the cited alternative solution suggested at the meeting ?)
 
 

Questions? Ask the ACAA Technical Agent