blakemor@software.ORG (Alex Blakemore) (04/21/89)
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.orgkanderso@etoile.ics.uci.edu (Ken Anderson) (04/22/89)
> 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!
weyrich@csun1.UUCP (Orville Weyrich) (04/23/89)
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
eachus@mbunix.mitre.org (Robert Eachus) (04/24/89)
In article <8904210606.AA05183@venera.isi.edu>, Alex Blakemore asked for the rationale behind 3.4(15), and implicitly asked how do export both a private type and a type derived from the derived type. I'm not sure how interested the readership is in the rationale, but the "workaround" that follows should be a standard Ada idiom. > 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 ? Yup! In Ada80 all of the operations of a parent type were derived (read subprograms with parameters or return values of the parent type). This was very tricky to implement, and it was a while before anyone realized that this definition of derived operations not only covered: function "+" (L,R: Foo) return Foo; but also included: function "+" (L: Foo; R: Bar) return Bar; now if we have the sequence: type Foo is range 0..10; type Bar is new Foo; X: Foo := 3; ... function "+" (L: Foo; R: Bar) return Bar; the rules said that this "+" was derived, and hid the predefined "+" for bar! A little wierd but tolerable. However replace the initial value for X with 2+1 and which "+" gets used? Note that the function definition need not be in the same lexical scope for this problem to occur (in Ada 80). The fix for derived subprograms was as follows: Only subprograms declared implicitly or explicitly in the visible part of same package specification as the parent type may be derived. 3.4(11) Explicitly declared subprograms are NOT derivable in the same visible part (but they can be in the private part). 3.4(11) It is illegal to derive from a derived type in the same visible part. 3.4(15) The prohibition against deriving from private types in the visible part of the same package is to prevent "circular" definitions of operations. For example, the operations of a derived type could be used in the complete definition of the private parent type were this allowed: type Foo is private: type Bar is new Foo; ... private type Foo is range Bar'FIRST..Bar'LAST; Now to solve the posed problem. You want to export from a package a private type and types derived from the private type? The easiest solution is to use nested packages, since the restriction on applies to types IMMEDIATELY within the visible part: package Outer is package Inner is type This is private; private type This is ...; end Inner; subtype This is Inner.This; type That is new This; .... end Outer; Note that the alternate arrangement is not permitted, since the derived type declaration must follow the complete declaration of the private type. 7.4.1 (4) Hope this is of some help. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...