Re: derived types in package specs

Re: derived types in package specs

[Ken Anderson]

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

derived types in package specs

[Alex Blakemore]

  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

Re: derived types in package specs

[Orville Weyrich]

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

Re: derived types in package specs

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