From rbrukardt@BIX.com Thu Oct 6 03:14:52 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA26852; Thu, 6 Oct 94 03:14:52 EDT Received: from bos2a.delphi.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA12904; Thu, 6 Oct 94 03:14:43 EDT Received: from bix.com by delphi.com (PMDF V4.3-9 #7804) id <01HHXONZ6IF4AUY2QJ@delphi.com>; Wed, 05 Oct 1994 23:38:44 -0400 (EDT) Received: by bix.com (CoSy3.31.1.45) id <9410052334.memo.83926@BIX.com>; Wed, 5 Oct 1994 23:34:48 -0400 (EDT) Date: Wed, 05 Oct 1994 23:34:48 -0400 (EDT) From: rbrukardt@BIX.com Subject: Where did the rules go? To: ada9x-mrt@inmet.com Message-Id: <9410052334.memo.83926@BIX.com> Content-Transfer-Encoding: 7BIT X-Cosy-To: ada9x-mrt@inmet.com !topic Where did the rules go? !reference RM9X-3.7;5.0 !from Randy Brukardt 94-10-5 <> !discussion I was recently updating the section/paragraph references in our Ada 9x compiler manual, and noticed a set of rules that I can't seem to find anywhere in RM9X. In RM9X;4.0 and before, the rules restricting the uses of discriminants in constraints were in 3.7 (paragraphs 11 and 12 in RM9X 4.0). I've looked everywhere I can think of in the manual for those rules. The index entries on discriminants are no help. Where did those two rules go? I'm pretty sure that there was no intent to eliminate them. Randy. From jps1@reading.ac.uk Thu Oct 6 10:48:57 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA20878; Thu, 6 Oct 94 10:48:57 EDT Received: from mail1.rdg.ac.uk (sussdirt.rdg.ac.uk) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA22815; Thu, 6 Oct 94 10:48:48 EDT Received: from csres.cs.reading.ac.uk (actually lovage.rdg.ac.uk) by sussdirt.rdg.ac.uk with SMTP - Local (PP); Thu, 6 Oct 1994 15:48:15 +0100 Received: from brigadier by csres.cs.reading.ac.uk (4.1) id; Thu, 6 Oct 94 15:48:07 BST Date: Thu, 6 Oct 94 15:44:18 BST Received: by brigadier (4.1) id AA12096; Thu, 6 Oct 94 15:44:18 BST From: jps1@reading.ac.uk Message-Id: <9410061444.AA12096@brigadier> To: ada9x-mrt@inmet.com Subject: Problem instantiating generic package using an incompletely declared type !topic Problem instantiating a generic package formal "private" type <> parameter with an incompletely declared type to create a linked list based on a controlled access type !reference RM9X-3.10.1;5.0, RM9X-12.5.1;5.0, RM9X-7.6;5.0 !from Phil Slater 94-10-06 !keywords controlled instantiation incomplete !discussion I attempted to create an assignable, self-deallocating ADT based on a linked list, by making the linking access type controlled. The following generic package specification defines the access type: ----------------------------------------------------------------------------- with Ada.Finalization; generic type Anything is private; type Pointer is access Anything; package AutoPointer_Package is type AutoPointer is new Ada.Finalization.Controlled with record Ptr : Pointer; end record; procedure Initialize (Object : in out AutoPointer); procedure Adjust (Object : in out AutoPointer); procedure Finalize (Object : in out AutoPointer); end AutoPointer_Package; ----------------------------------------------------------------------------- The body of this package is not relevant so is not included. Following this, I had to create the linked list using an instance of AutoPointer in place of the normal access type: ----------------------------------------------------------------------------- with AutoPointer_Package; generic type List_Element is limited private; package AssList is type Assignable_List is private; -- ... subprograms etc here private type List_Node; type List_Node_Ptr is access List_Node; package AutoLink is new AutoPointer_Package (List_Node, List_Node_Ptr); type List_Node is record Value : List_Element; Next : AutoLink.AutoPointer; end record; type Assignable_List is new AutoLink.AutoPointer with null record; end AssList; ----------------------------------------------------------------------------- The instantiation of package AutoLink appears to be illegal at the position it is placed, because the declaration of type Link_Node is incomplete. However, it cannot appear anywhere else! For example, the GNAT compiler gave the following: F:\DJGPP\JPS>gcc -c asslist.ads asslist.ads:10:50: premature use of incomplete type asslist.ads:10:50: invalid use of type before its full declaration compilation abandoned Is it worth considering allowing the use of an incompletely declared type for generic instantiation to permit this functionality to be achieved, (or is there something obvious I have missed?!) From bobduff@dsd.camb.inmet.com Thu Oct 6 11:01:16 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA21380; Thu, 6 Oct 94 11:01:16 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA23235; Thu, 6 Oct 94 11:01:13 EDT Received: by dsd.camb.inmet.com (4.1/SMI-4.1) id AA21374; Thu, 6 Oct 94 11:01:04 EDT Date: Thu, 6 Oct 94 11:01:04 EDT From: bobduff@dsd.camb.inmet.com (Bob Duff) Message-Id: <9410061501.AA21374@dsd.camb.inmet.com> To: rbrukardt@BIX.com Cc: ada9x-mrt@inmet.com In-Reply-To: <9410052334.memo.83926@BIX.com> (rbrukardt@BIX.com) Subject: Re: Where did the rules go? !topic Where did the rules go? !reference RM9X-3.7;5.0 !reference 94-4830.a rbrukardt@BIX.com 94-10-6 !from Bob Duff <> !discussion > In RM9X;4.0 and before, the rules restricting the uses of discriminants > in constraints were in 3.7 (paragraphs 11 and 12 in RM9X 4.0). > >... Where did those two rules > go? They have been moved to 3.8(12). - Bob From gary@alsys.com Thu Oct 6 20:46:58 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA14591; Thu, 6 Oct 94 20:46:58 EDT Received: from gw.alsys.com ([136.175.17.2]) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA18438; Thu, 6 Oct 94 20:46:55 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA00786; Thu, 6 Oct 94 17:46:46 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA15327; Thu, 6 Oct 94 17:46:45 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA15668; Thu, 6 Oct 1994 17:46:43 +0800 Date: Thu, 6 Oct 1994 17:46:43 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9410070046.AA15668@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Formal derived types inheriting abstract subprograms Content-Length: 2850 !topic Formal derived types inheriting abstract subprograms !reference RM9X-3.9.3(6);5.0 !from Gary Dismukes 94-10-6 <> !discussion I've come across a restriction in RM9X-5.0 involving formal derived types that inherit abstract subprograms that I believe was not present in version 4.0. I would like confirmation of whether the restriction is intended, because I believe it is likely to interfere with a common paradigm of using formal derived types. The restriction does not seem necessary on semantic grounds so perhaps it was felt not to be worth the trouble to relax because it's deemed not to provide enough user benefit. The version 5.0 rules for overriding of abstract subprograms appear to make the following example illegal: package PK_A is type TA is abstract tagged null record; procedure P ( X: TA ) is abstract; end PK_A; generic type FT is new PK.TA with private; -- Illegal by 3.9.3(6);5.0 package GPK is type Mix_In is new FT with ...; procedure P ( X: Mix_In ); end GPK; package body GPK is procedure P ( X: Mix_In ) is begin P( FT( X ) ); -- Invoke the parent operation ... do other stuff end; end GPK; package PK_B is type TB is new PK_A.TA with ...; procedure P ( X: TB ); package NPK is new GPK( TB ); end PK_B; The formal derived type declaration is illegal because 3.9.3(6) requires any abstract subprograms inherited by a nonabstract untagged type to be overridden, and there's no way to override a subprogram inherited by a formal derived type. However, in any instantiation of the generic GPK, the actual type will have to be nonabstract and each of its primitive subprograms must be nonabstract, thus ensuring that each of the primitive operations of the formal type is associated with a concrete subprogram. It seems that it will be very common to need a generic of this kind, say to define a mix-in, where we want to inherit from an abstract type and parameterize the generic by a concrete type. It doesn't work well to declare the formal derived type as abstract because that interferes with the ability to call the primitive subprograms of the actual type except via dispatching calls (which may not be the desired semantics). While a mix-in type within the generic can override the abstract operations inherited from the formal derived type, these overriding operations can't invoke the corresponding parent operation of the actual type with a nondispatching call. The only workaround that I can see is to change the parent abstract type to a nonabstract type, which hardly seems like an attractive solution. Although the version 4.0 rules were a little muddled in this area, they appeared to allow the above paradigm. So perhaps the appearance of this restriction in 5.0 was not intended. -- Gary