From phl@rational.com Wed Aug 21 07:55:45 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA23211; Wed, 21 Aug 96 07:55:45 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA29948; Wed, 21 Aug 96 07:56:00 EDT Received: from rational2.rational.com by sw-eng.falls-church.va.us (8.7.1/) id LAA12294; Wed, 21 Aug 1996 11:54:13 GMT Received: from igor.rational.com (igor.rational.com [89.64.2.102]) by rational2.rational.com (8.6.12/8.6.9) with ESMTP id EAA07292 for ; Wed, 21 Aug 1996 04:55:56 -0700 Received: from sorbonne.rational.com (sorbonne.rational.com [192.229.50.20]) by igor.rational.com (8.6.9/igor-1.0-wwong) with ESMTP id EAA29766; Wed, 21 Aug 1996 04:55:42 -0700 Received: from cluny.Rational.COM (cluny [192.229.50.109]) by sorbonne.rational.com (8.6.9/8.6.9) with SMTP id NAA25318; Wed, 21 Aug 1996 13:55:20 +0200 From: "Pascal Leroy" Message-Id: <9608211355.ZM28105@rational.com> Date: Wed, 21 Aug 1996 13:55:37 +0200 Organization: Rational Software Corporation Phone: +33 (1) 30 12 09 50 Reply-To: pleroy@Rational.COM X-Mailer: Z-Mail (3.2.0 06sep94) To: ada-comment@sw-eng.falls-church.va.us Subject: Anonymous access types and finalization Cc: swb@rational.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii !topic Anonymous access types and finalization !reference RM95 3.10(2) !reference RM95 3.7(27) !reference RM95 7.6.1(11) !from Pascal Leroy 96-08-20 <> !discussion The finalization of an object created by an allocator occurs when the master of the ultimate ancestor of the access type is left, as stated in 7.6.1(11). In the case of access discriminants, 3.10(2) tells us that "an access_definition defines an anonymous access type"; I take this to imply that an anonymous access type is an "ultimate ancestor" in the sense of 7.6.1(11). In addition, 3.7(27) tells us that "an access_definition is elaborated when the value of a corresponding access discriminant is defined"; I take this to imply that the master of the anonymous access type is the master that elaborated the discriminant constraint. The interaction of these rules has the unfortunate consequence that it makes it possible to reference an object after it has been finalized, as shown in the following example: procedure P1 is type T (D : access Some_Controlled_Type) is ... ; procedure P2 is type T_Ref is access T; X : T_Ref; procedure P3 is begin X := new T (D => new Some_Controlled_Type); -- (1) end P3; begin P3; -- (2) end P2; begin P2; end P1; The discriminant constraint for the allocated object X.all is elaborated by P3. The elaboration of this constraint also elaborates the access_definition, therefore, the master of the anonymous access type is P3. So when leaving P3, at the point marked (1), the allocated object X.all.D.all is finalized, as per 7.6.1(11). But of course, after leaving P3 we can still use the name X.all.D.all to reference this object (at the point marked (2)), and this is bad... It seems to me that we need a rule that says that the master of an anonymous access type A used in the specification of an access discriminant in type T, the master of A is the master of T, not the master that caused A to be elaborated. Or, alternatively, that when an allocator is used as a discriminant value for an anonymous access type, the master of the allocated object is defined to be the master of the discriminated object. (These two proposals are different, but they both seem to cure the problem, although the first one is probably easier to implement.) _____________________________________________________________________ Pascal Leroy +33.1.30.12.09.68 pleroy@rational.com +33.1.30.12.09.66 FAX From phl@rational.com Wed Aug 21 07:57:17 1996 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA23273; Wed, 21 Aug 96 07:57:17 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA29954; Wed, 21 Aug 96 07:57:32 EDT Received: from rational2.rational.com by sw-eng.falls-church.va.us (8.7.1/) id LAA12304; Wed, 21 Aug 1996 11:55:45 GMT Received: from igor.rational.com (igor.rational.com [89.64.2.102]) by rational2.rational.com (8.6.12/8.6.9) with ESMTP id EAA07295 for ; Wed, 21 Aug 1996 04:57:28 -0700 Received: from sorbonne.rational.com (sorbonne.rational.com [192.229.50.20]) by igor.rational.com (8.6.9/igor-1.0-wwong) with ESMTP id EAA29785; Wed, 21 Aug 1996 04:57:14 -0700 Received: from cluny.Rational.COM (cluny [192.229.50.109]) by sorbonne.rational.com (8.6.9/8.6.9) with SMTP id NAA25331; Wed, 21 Aug 1996 13:56:53 +0200 From: "Pascal Leroy" Message-Id: <9608211357.ZM28108@rational.com> Date: Wed, 21 Aug 1996 13:57:10 +0200 Organization: Rational Software Corporation Phone: +33 (1) 30 12 09 50 Reply-To: pleroy@Rational.COM X-Mailer: Z-Mail (3.2.0 06sep94) To: ada-comment@sw-eng.falls-church.va.us Subject: Profile of predefined operators Cc: swb@rational.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii !topic Profile of predefined operators !reference AI95-00145 !from Pascal Leroy 96-08-20 <> !discussion The referenced AI didn't trigger a lot of discussions, to say the least, so let me try again... There are two other issues related to the question of the profile of predefined operators. One is the interaction with the contract model, the other is the fact that it is impossible to write a specification for the predefined operators of composite types. As an example of the first issue, look at the following example: generic type T is (<>); package P is function F (L, R : T) return Boolean; end P; package body P is function F (L, R : T'Base) return Boolean renames "="; -- (1) function F (L, R : T) return Boolean renames "="; -- (2) end P; Which (if any) of the declarations (1) and (2) is legal? If we follow 4.5, which seems to say that the predefined operators are parameters of the (unconstrained) type, then (1) is legal and (2) is illegal. If we follow the declarations given in the specification of Standard (A.1(7)) then we should use (1) if T happens to be an enumeration type, and (2) if T happens to be an integer type. Of course, since the body of a generic is compiled in an "assume-the-worst" manner, neither (1) nor (2) is legal. This is a nuisance. In the rest of this discussion I assume that the intended meaning is that of 4.5, and that A.1(7) is a mistake. Consider now what happens if we change the formal part of P to be: generic type T is private package P is ... Then we cannot even write (1), because the attribute 'Base is not available for a composite type. And of course (2) doesn't make sense: type T is array (1 .. 10) of Character; -- This type has an operator "=", but its profile is certainly not: -- function "=" (Left, Right : T) return Boolean; -- So we just cannot write that profile in Ada. Sigh. This situation is quite unpleasant, because a renaming-as-body would be very useful in this case. Clearly, similar difficulties arise with private types, at places that have visibility over the private view: package P is type T is private; function Foo1 (L, R : T) return Boolean; function Foo1 (L, R : T) return Boolean renames "="; -- legal? private type T is new Natural; -- alternatively, type T is new Float; end function Foo2 (L, R : P.T) return Boolean; function Foo2 (L, R : P.T) return Boolean renames "="; -- legal? Does he completion of type T affect the legality of the renaming-as-bodies in these examples? The language would be more useful if 'Base was allowed in a limited number of circumstances for non-scalar types; in particular, it would be nice to be able to write an Ada specification for the predefined operators. _____________________________________________________________________ Pascal Leroy +33.1.30.12.09.68 pleroy@rational.com +33.1.30.12.09.66 FAX From 100071.47@CompuServe.COM Wed Aug 21 09:43:51 1996 Return-Path: <100071.47@CompuServe.COM> Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA23711; Wed, 21 Aug 96 09:43:51 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA02496; Wed, 21 Aug 96 09:44:06 EDT Received: from dub-img-3.compuserve.com by sw-eng.falls-church.va.us (8.7.1/) id NAA15072; Wed, 21 Aug 1996 13:42:18 GMT Received: by dub-img-3.compuserve.com (8.6.10/5.950515) id JAA23813; Wed, 21 Aug 1996 09:43:12 -0400 Date: 21 Aug 96 09:41:38 EDT From: Bernard Maudry <100071.47@CompuServe.COM> To: "'Ada95-Comments'" Subject: Controversial visibility of inherited private components in a child unit private part (or body) Message-Id: <960821134138_100071.47_EHK66-1@CompuServe.COM> !topic Controversial visibility of inherited private components in a child unit <> private part (or body) !reference RM95 7.3 (15) 7.3.1 (3) 7.3.1 (10) !from Bernard Maudry 96-08-21 !keywords visibility inherited private components child !discussion I would like to know if the following code is legal or not as 2 of the 4 compilers I use think that it is illegal. I will not try to explain you the problem as you will better understand it when reading the code below. package Top is type Node is abstract tagged private ; private type Node is abstract tagged record Name : Integer := 0; end record; end Top ; package Top.Mid is type Node is abstract new Top.Node with private ; private type Node is abstract new Top.Node with record Kind : Integer := 0; end record; end Top.Mid ; with Top.Mid; generic type Parent is abstract new Top.Mid.Node with private; package Top.Extra is type Node is abstract new Parent with null record ; end Top.Extra ; with Top.Mid; with Top.Extra; package Top.Mid.Extra is new Top.Extra (Parent => Top.Mid.Node); with Top.Mid.Extra ; package Top.Mid.Bot is type Node is new Top.Mid.Extra.Node with null record ; The_Node : Node ; private -- The legality of the two following lines of code is controversial. -- Of 4 Ada95 compilers, 2 of them think they are legal, and the 2 others -- reject them as illegal. -- Where is the truth ? Why ? Buggy_1 : Integer := The_Node.Name; Buggy_2 : Integer := The_Node.Kind; end Top.Mid.Bot ;