From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!elroy!ucla-cs!uci-ics!etoile.ics.uci.edu!kanderso
From: kanderso@etoile.ics.uci.edu (Ken Anderson)
Newsgroups: comp.lang.ada
Subject: Re: derived types in package specs
Keywords: Environment
Message-ID: <12448@paris.ics.uci.edu>
Date: 21 Apr 89 23:12:34 GMT
Sender: news@paris.ics.uci.edu
List-Id: <comp.lang.ada>

>  This disallows things like
>     type this is new integer;
>     type that is new this;

   The rationale behind this is due to the fact that a derived type receives
it's parents subprograms. I.E. ALRM 3.4(13):

   "The specification of a derived subprogram is obtained implicitly by 
    systematic replacement of the parent type by the derived type in the
    specification of the derivable subprogram..."

Thus because your context is in the package specification, before you can 
derive a new type from this (taken from the example above), all of the
subprograms (and subtypes, expressions, ...) that use type this, must be 
defined. The compiler will not know that all of these have been defined until
it has finished compiling the spec. This insures that everything that must
be derived for a new type is known.


package That is

   type this is new integer;

end That;


------ In some other unit,

with That;
procedure Who is

   type that is new That.this;

begin
   null;
end Who;




Ken Anderson
U.C. Irvine
Go Anteaters!