Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site boulder.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!nbires!boulder!geoff
From: geoff@boulder.UUCP (Geoffrey M. Clemm)
Newsgroups: net.lang.ada
Subject: Re: Mutually Recursive Data-Structures in ADA
Message-ID: <406@boulder.UUCP>
Date: Mon, 23-Sep-85 11:25:53 EDT
Article-I.D.: boulder.406
Posted: Mon Sep 23 11:25:53 1985
Date-Received: Wed, 25-Sep-85 12:09:32 EDT
References:  <8509191758.AA23499@UCB-VAX.ARPA>
Reply-To: geoff@boulder.UUCP (Geoffrey Clemm)
Organization: University of Colorado, Boulder
Lines: 42

In article <8509191758.AA23499@UCB-VAX.ARPA> BRYAN@SU-SIERRA.ARPA (Doug Bryan)
suggests to use generic packages to separate the parts of a mutually recursive
data type into separate packages.

I agree that generics allow one to "un-nest" packages, but one of the main
reasons I wanted to separate the mutually recursive data type into separate
packages was to provide for re-compilation efficiency.  In our compiler,
generics are just treated as fancy macros (as far as I can tell), which
means that a generic solution, i.e.

   GENERIC PACKAGE a ... END a;
   GENERIC PACKAGE b ... END b;
   PACKAGE all IS
      PACKAGE my_a IS NEW a;
      PACKAGE my_b IS NEW b;
      ...
      END all;

is no better than

   PACKAGE all IS
      PACKAGE my_a IS ... END my_a;
      PACKAGE my_b IS ... END my_b;
      ...
      END all;

The only way that I can get re-compilation efficiency (i.e. if I modify
one part of the mutually recursive data structure, I only have to recompile
the accessing functions for that part), would be to place them in separate
non-generic packages, i.e.

   PACKAGE my_a IS ... END my_a;
   PACKAGE my_b IS ... END my_b;

And that's what I don't think I can do in ADA.

Geoffrey Clemm

P.S. The reason I am concerned with recompilation efficiency is that
I am doing exploratory programming with a large system, half of which
is accessing functions to data structures that all end up being mutually
recursive.  If I had an efficient validated ADA interpreter I wouldn't care ...