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
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,66253344eaef63db
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,66253344eaef63db
X-Google-Attributes: gid1108a1,public
X-Google-ArrivalTime: 1994-10-03 09:26:50 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!cs.utexas.edu!convex!news.duke.edu!eff!blanket.mitre.org!linus.mitre.org!linus!mbunix!eachus
From: eachus@spectre.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada,comp.object
Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG)
Date: 3 Oct 94 12:14:10
Organization: The Mitre Corp., Bedford, MA.
Message-ID: <EACHUS.94Oct3121410@spectre.mitre.org>
References: <1994Sep27.165203.9192@swlvx2.msd.ray.com>
	<36bt0c$17oo@watnews1.watson.ibm.com> <1994Sep29.103358@di.epfl.ch>
	<36eebb$jn5@disunms.epfl.ch> <Cwyzx4.H3K@irvine.com>
	<1994Oct2.164105.13127@swlvx2.msd.ray.com>
NNTP-Posting-Host: spectre.mitre.org
In-reply-to: jgv@swl.msd.ray.com's message of Sun, 2 Oct 1994 16:41:05 GMT
Xref: bga.com comp.lang.ada:6408 comp.object:7013
Date: 1994-10-03T12:14:10+00:00
List-Id: <comp.lang.ada>

In article <1994Oct2.164105.13127@swlvx2.msd.ray.com> jgv@swl.msd.ray.com (John Volan) writes:

   > adam@irvine.com (Adam Beneschan) writes:

   >> I'd like to chime in and say I'm not satisfied either.... 

   > I fear there may be many of us out there.

   > That's my fear as well.  That's why I've been trying very hard to
   > find an Ada9X solution.  Eiffel can do decoupled mutual recursion
   > standing on its head.  Smalltalk virtually swims in a sea of
   > decoupled mutual recursion (trivial in a typeless language).  I
   > suspect C++ can actually manage it as well.  (Can any C++ folks
   > confirm this?  Realize what I mean: Can you forward-declare a
   > class and then *not* complete its declaration in the same header
   > file, and yet complete the declaration of a client class?  Or do
   > you *have* to declare both classes in the same header file?)

   Stated this way, you are trying to solve a different problem than
the original one.  This one has a very simple solution: child units.
This eliminates the "necessity" for mutual recursion in the visible
package specifications.

   However, there are limitations to this approach.  (Let me do a bit
of a sketch here:

   package Employees is
     type Employee is tagged private;
     ...
   end Employees;

   package Offices is
     type Office is tagged private;
     ...
   end Offices;

   with Offices; use Offices;
   function Employees.Assigned_Office(E: in Employee) return Office;

   with Employees; use Employees;
   function Offices.Occupant(O: in Office) return Employee;

   As sketched, this provides a clean, clear interface.  However there
are two problems.  First, there is going to have to be some
abstraction breaking to implement the bodies of these units.  It can
be done in a type safe manner, with private child units, and there are
other possibilities.

   Second, these functions are not inheritable, so you might want:

   with Offices; use Offices;
   function Employees.Assigned_Office(E: in Employee'CLASS)
        return Office'CLASS;

   with Employees; use Employees;
   function Offices.Occupant(O: in Office'CLASS) return Employee'CLASS;

   instead of the versions above.  Since such subprograms would have
to deal with all of the (possibly) many subclasses to employees or
offices, this approach can result in unmaintainable code. However for
small projects, or for attributes which are orthogonal to the rest of
the abstraction, this approach works just fine.

    If any extension to the current draft standard is required in this
area--and I don't think one is--it would be to change 3.2.3(6) to make
child units eligible as primitive operations, probably under the
influence of a pragma.   I certainly don't recommend such a change to
the standard--it would open up all sorts of holes--but that should
prevent someone from experimenting with such a pragma.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...