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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!cornell!uw-beaver!mit-eddie!husc6!cca!mirror!ishmael!ada-uts!stt
From: stt@ada-uts
Newsgroups: comp.lang.ada
Subject: Re: HELP needed!!
Message-ID: <57900036@ada-uts>
Date: Fri, 10-Jul-87 12:56:00 EDT
Article-I.D.: ada-uts.57900036
Posted: Fri Jul 10 12:56:00 1987
Date-Received: Sat, 18-Jul-87 06:58:06 EDT
References: <322@louie.udel.EDU>
Nf-ID: #R:louie.udel.EDU:-32200:ada-uts:57900036:000:1862
Nf-From: ada-uts!stt    Jul 10 12:56:00 1987
List-Id: <comp.lang.ada>


A solution is to pass an access-to-A as the generic actual type,
or include an access-to-list-header as the component of B (and move
the instantiations down below the full record type definitions).

However, your best solution is probably
to define A and B as access types themselves,
and defer the whole data structure definition to the package body
(see 3.8.1:3), as follows:

    type A is private;
    type B is private;
    . . .
private
    type A_Record;  -- full definition deferred to package body
    type A is access A_Record;
    type B_Record;  -- full definition deferred to package body
    type B is access B_Record;
end pkg;

package body pkg is
    <instantiations>
    type A_Record is
       B_List : List_Of_B.List;
     . . .

This also saves you greatly on recompilations when
you decide to add or change component definitions within
A_Record or B_Record.

Tucker Taft
c/o Intermetrics, Inc.
Cambridge, MA  02138

P.S. Here is a rationale for the restrictions...

Mutually recursive types clearly require the use of
access types somewhere.  You have hidden the use
within the generic.  This conflicts with the general
rule that the legality of an instantiation
is determined by the legality of the generic itself and
the legality of the actual/formal parameter matching.
(The only error which cannot be detected until the actual
parameter substitution takes place within the spec
and body of the generic has to do with the
use of unconstrained types (see 12.3.2:4).)

Allowing uncompleted private types as actual parameters as in your
example would severely increase the number of error situations which
could only be determined upon parameter substitution.
In your example it would be illegal if a list header included an instance
of the item type directly, whereas if a list header included only
an access type, then it would be legal.