* derived types in package specs
@ 1989-04-20 17:34 Alex Blakemore
1989-04-23 1:50 ` Orville Weyrich
1989-04-24 15:27 ` Robert Eachus
0 siblings, 2 replies; 4+ messages in thread
From: Alex Blakemore @ 1989-04-20 17:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: derived types in package specs
@ 1989-04-21 23:12 Ken Anderson
0 siblings, 0 replies; 4+ messages in thread
From: Ken Anderson @ 1989-04-21 23:12 UTC (permalink / raw)
> 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!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: derived types in package specs
1989-04-20 17:34 Alex Blakemore
@ 1989-04-23 1:50 ` Orville Weyrich
1989-04-24 15:27 ` Robert Eachus
1 sibling, 0 replies; 4+ messages in thread
From: Orville Weyrich @ 1989-04-23 1:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: derived types in package specs
1989-04-20 17:34 Alex Blakemore
1989-04-23 1:50 ` Orville Weyrich
@ 1989-04-24 15:27 ` Robert Eachus
1 sibling, 0 replies; 4+ messages in thread
From: Robert Eachus @ 1989-04-24 15:27 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1989-04-24 15:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-04-21 23:12 derived types in package specs Ken Anderson
-- strict thread matches above, loose matches on Subject: below --
1989-04-20 17:34 Alex Blakemore
1989-04-23 1:50 ` Orville Weyrich
1989-04-24 15:27 ` Robert Eachus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox