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,
	LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,93fa00d728cc528e
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,93fa00d728cc528e
X-Google-Attributes: gid1108a1,public
X-Google-ArrivalTime: 1994-10-19 12:39:31 PST
Newsgroups: comp.lang.ada,comp.object
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!lll-winken.llnl.gov!enews.sgi.com!wdl1!dst17!mab
From: mab@dst17.wdl.loral.com (Mark A Biggar)
Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger
Message-ID: <1994Oct19.143843.372@wdl.loral.com>
Keywords: Ada9X, "withing" problem, CORBA, IDL
Sender: news@wdl.loral.com
Organization: Loral Western Development Labs
References: <1994Oct18.221751.15457@swlvx2.msd.ray.com>
 <CxwAuy.1CL@inmet.camb.inmet.com> <38289r$79m@oahu.cs.ucla.edu>
Date: Wed, 19 Oct 1994 14:38:43 GMT
Xref: bga.com comp.lang.ada:7098 comp.object:7569
Date: 1994-10-19T14:38:43+00:00
List-Id: <comp.lang.ada>

In article <38289r$79m@oahu.cs.ucla.edu> jmartin@oahu.cs.ucla.edu (Jay Martin) writes:
>With all these ugly workarounds it looks like we must have a
>language extension to Ada to handle mutual dependencies.
>Otherwise Ada9x is a "joke".  Of course if there is no way that Ada
>will be extended quickly, it will be a "joke" anyway.  Hopefully C++
>has taught language designers/standardizers something.
>The extension would be of the form:
>
>package forward X is
>  type XType;
>  type XPtrType is access XType;
>end X;
>
>And would be severely resticted to only allow for incomplete types
>declaration and access types to incomplete types.  These of course
>would have to be repeated/elaborated in the package spec.

This is going back to a "One True Way" of OOP again.  What's so ugly about:

package Forward_X is
    type X_Parent is abstract tagged null record;
    type X_Ptr_Type is access all X_parent;
end Forward_X;

Especially when supported bu generics like John is proposing.

>Thus, there would be a third package part in Ada compilation libraries
>(Spec and body being the other two).  What it does is tells the Ada
>compiler to not give an error if these yet to be specified types are
>used in a spec.  
>So basically a programmer could compile the forwards first, then the
>specs and finally the bodies into the Ada library.  (GNAT looney
>tunes "#include the spec" implementation of the Ada library
>would place all the withed package's forwards before their specs
>when compiling.) 
>Of course, you couldn't directly declare incomplete objects in the private
>parts of specs.   An elegant way of handling this (which would
>be too obese to put in ada) would be to have a separately compiled
>"package representation" part of a package which would basically
>remove the private part of spec out of the spec.  For example:
>with X; 
>package representation Y is
>  type YType is
>   record
>     P1:integer;
>     P2:X.XType;
>   end record;
>end X; 
>Its neat because it removes implementation details from the spec 
>where they never belonged and allows for mutually recursive types to
>be directly included into the abstract data type (instead of having a
>pointer to it).

But this would still require the compliation of both spec and "representation"
parts before you could compile anything that depended on the package.
Totally revamping the package scheme just to increase the eligence of 
a boundary case (especially when there are reasonable workarounds) is
unproductive.

--
Mark Biggar
mab@wdl.loral.com