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!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!software.ORG!blakemor
From: blakemor@software.ORG (Alex Blakemore)
Newsgroups: comp.lang.ada
Subject: Re: derived types
Message-ID: <8904231604.AA02941@venera.isi.edu>
Date: 23 Apr 89 15:33:24 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>


	Re: 3.4.(15) and 7.4(4)
	>>  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 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.
	
	OK, the above restrictions make it easier for compilers to make a single pass
	over package specs.  That alone may justify their inclusion in the reference manual.
	Is that the only reason for these restrictions ?
	
	Cascading the derivations across several packages is probably the best
	solution but it does introduce other problems, esp if the base type is private.
	See Bardin & Thompson's papers in Ada Letters, VIII, 1-2 for examples of
	these problems and partial solutions if you're interested.
	
	                                Alex Blakemore
	                                Software Productivity Consortium