Re: Mut. Recurs. in Ada9X w/o Breaking Encapsulation?

[eachus@spectre.mitre.org (Robert I. Eachus)]

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

  >> I still don't see why having separate chunks of something for
  >> interface and implementation should necessarily disallow mutual
  >> dependencies.  It's perplexing why you just can't say Ada 9x
  >> shall now allow mutual dependencies among interfaces or
  >> implementations.

  > Well, I think you'll have to take that up with the language designers
  > and the compiler writers.  Anyone want to chime in here? :-)

  If gazelles had longer necks and ran slower they would be giraffes?

     Any language has "fundamental theorems" in its design. (Or at
least a language should, some languages have "just grown".)  If chosen
properly, these basic rules provide a consistancy to the language and
make it more useful in the languages intended domain.  One of the
fundamental theorems in Ada is that there exists a consistant
elaboration order, where everything is declared before it can be named
and elaborated before it can be used.

     This is one of the nicest properties of Ada from  a debugging and
maintenance viewpoint, but it does impose some costs on programmers.
For example, incomplete type declarations are needed if you are
declaring a type that is indirectly self-referential.  (The typical
case is a record type containing pointers to other records of the
type.)

     So if you want a language that allows use before elaboration,
choose another language.  (Notice that Ada does allow--but does not
require compilers to support, due to halting problem issues and
intractability--deferring the selection of an elabortation order until
run-time and then "selecting the one that works today."  The only
thing that is definitely forbidden is referring to a yet to be
initialized portion of a construct.  Since types have attributes, and
these attributes do need determination, types also require
elaboration.  It may seem silly that the fundamental reason that you
can't have directly recursive types in Ada is that you have to
determine the size of one type before the other, but that is the way
it is. (There is a restriction on the use of incomplete type names in
3.8.1(4), and a restriction in 8.2(16) on visibility to prevent
directly recursive types.)

  >>I think cyclic dependency graphs are a fact of life.

  > Oh, I fully agree that cyclic dependency (mutual recursion) is
  > often unavoidable.  But again, I think you prove my point for me
  > about Eiffel programmers -- you don't seem to be able to see the
  > difference between dependency-in-your-interface vs.
  > dependency-in-your-implementation.

   Just to make sure I don't confuse the issue, there is no problem
implementing recursive structures in Ada.  The only limit imposed by
all the above is that the mutual recursion must be expliciltly
indirect in the implementation--it can be, and often is, direct in the
interface.  For example in a tree package you might have:

   function Parent(N: Node) return Node;

or if edges are important:

   function Parent_Link(N: Node) return Edge;
   function Destination(E: in Edge) return Node;




      

--

					Robert I. Eachus

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