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=1.9 required=5.0 tests=BAYES_50,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!rutgers!gatech!csun1!weyrich
From: weyrich@csun1.UUCP (Orville Weyrich)
Newsgroups: comp.lang.ada
Subject: Re: derived types in package specs
Message-ID: <152@csun1.UUCP>
Date: 23 Apr 89 01:50:16 GMT
References: <8904210606.AA05183@venera.isi.edu>
Distribution: na
Organization: Univ. of GA, CS Dept., Athens
List-Id: <comp.lang.ada>

>From article <8904210606.AA05183@venera.isi.edu>, by blakemor@software.ORG (Alex Blakemore):
 
>   Does anyone have an idea of the rationale behind RM 3.4(15) ?
 
>   This disallows things like
>     type this is new integer;
>     type that is new this;
 
>   and what really hurt was
>     type this is private;
>     that that is new this;

What's wrong with doing the same thing as:
	  type this is new integer;
	  type that is new integer;

and
      type this is private;
	  type that is private;

Certainly in the second example it Ada's restriction is reasonable: would
you want THAT to inherit the (private) invisibility from THIS, or would you 
want THAT to be fully visible?


-- 
Orville R. Weyrich, Jr.          | UUCP    : ...gatech!csun1!weyrich
Department of Computer Science   | INTERNET: weyrich@csun1.cs.uga.edu
University of Georgia            |
Athens, GA 30602 USA             | MA BELL : (404) 542-1082