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!tut.cis.ohio-state.edu!ucbvax!software.ORG!blakemor
From: blakemor@software.ORG (Alex Blakemore)
Newsgroups: comp.lang.ada
Subject: derived types in package specs
Message-ID: <8904210606.AA05183@venera.isi.edu>
Date: 20 Apr 89 17:34:23 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>


  Does anyone have an idea of the rationale behind RM 3.4(15) ?

  "If a derived type or private type is declared immediately within
   the visible part of a package, then, within this visible part,
   this type must not be used as the parent type of a derived
   type definition." ... see also 7.4.1.(4)

  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;

  The draft copy of the Ada design rationale doesn't seem to discuss this.
  If this were legal, I think I could come up with a very nice use for
  derived types (something that has been rare but not unheard of in my experience)
  So there must have been a reason right ?

                                  Alex Blakemore
                                  Software Productivity Consortium
                                  blakemore@software.org