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: 109fba,66253344eaef63db X-Google-Attributes: gid109fba,public 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-13 13:20:48 PST Path: bga.com!news.sprintlink.net!hookup!swrinde!howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.kei.com!eff!blanket.mitre.org!linus.mitre.org!linus!mbunix!eachus From: eachus@spectre.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.ada,comp.lang.c++,comp.object Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encapsulation? Date: 13 Oct 94 11:24:50 Organization: The Mitre Corp., Bedford, MA. Message-ID: References: <1994Oct8.171744.26604@swlvx2.msd.ray.com> <377t87$t7n@network.ucsd.edu> <1994Oct12.211820.23051@swlvx2.msd.ray.com> NNTP-Posting-Host: spectre.mitre.org In-reply-to: jgv@swl.msd.ray.com's message of Wed, 12 Oct 1994 21:18:20 GMT Xref: bga.com comp.lang.ada:6874 comp.lang.c++:32660 comp.object:7340 Date: 1994-10-13T11:24:50+00:00 List-Id: 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...