Re: derived types in package specs

[eachus@mbunix.mitre.org (Robert Eachus)]

     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...