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: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-02 10:18:26 PST Newsgroups: comp.lang.ada,comp.object,comp.lang.c++ Path: bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!solaris.cc.vt.edu!MathWorks.Com!news2.near.net!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG) Date: Sun, 2 Oct 1994 16:41:05 GMT Message-ID: <1994Oct2.164105.13127@swlvx2.msd.ray.com> References: <1994Sep27.165203.9192@swlvx2.msd.ray.com> <36bt0c$17oo@watnews1.watson.ibm.com> <1994Sep29.103358@di.epfl.ch> <36eebb$jn5@disunms.epfl.ch> Sender: news@swlvx2.msd.ray.com (NEWS USER) Keywords: Ada 9X, C++, Eiffel, Smalltalk, object-oriented Organization: Raytheon Company, Tewksbury, MA Xref: bga.com comp.lang.ada:6378 comp.object:6985 comp.lang.c++:31377 Date: 1994-10-02T16:41:05+00:00 List-Id: 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. [snip] >And based on my experience writing large Ada 83 programs, my gut >instinct is that this is the sort of flaw that will be cursed by many >9X users down the line... 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?) We want Ada9X to be successful. We want Ada9X to attract programmers who might not have considered using Ada before. If something is trivial in other languages, it is not necessary that it be *trivial* in Ada9X. But it must at least be *feasible*. [snip] >What I think John wants (and I concur) is some way for package >specifications to use accesses to types in other packages that haven't >been compiled yet--sort of like a forward declaration that crosses >package boundaries. Perhaps something like this could be added to >Ada 0X or whatever the next revision of the language would be. I agree wholeheartedly with the *goal*, but not with the *means* you suggest. Goal: Some kind of "forward declaration" that crosses package boundaries. (Good and worthy goal.) Means: Some way for package specifications to use access types in other packages that *haven't been compiled yet*. (Horrible means, terrible implications, shudder, shudder :-) Actually, I have a better idea. Let's take a bit of inspiration from a notion that is already intrinsic to the design of Ada: Although a package is considered to be a single, self-contained, organic entity -- a *unit* of program modularity -- nevertheless it is syntactically broken up into two *parts* that present complementary *views* of that single unit -- two views which can be *separately compiled*. They are: (1) the package specification, which presents the *interface* view of the package, and (2) the package body, which presents the *implementation* view of the package. All that is really needed is to a break off a third syntactic part that can offer a view of the package where we can make "forward declarations" -- or rather, where "incomplete" declarations could be tolerated, because they will eventually be completed in the package specification. We could offer up this new part as a separately-compilable piece of code. In keeping with the long-standing Ada practice of *recycling* reserved words for new uses rather than creating new ones (bet you didn't know that Ada language designers were environmentalists! :-), let's call this new package part a "package abstract" (where "abstract" is a noun rather than an adjective, like the "abstract" of an article). Rules: (1) A package abstract would be considered a declarative region contiguous with the public part of the corresponding package specification. The spec would implicitly have visibility to any declaration that appeared in its corresponding package abstract. (2) To avoid a situation analogous to the problem of "optional" package bodies in Ada 83, we would need to syntactically distinguish ordinary package specs from those that have an abstract. The following would be illegal: (a) Compiling an ordinary spec when a package abstract with the same name is already in the library. (b) Compiling a package abstract when an ordinary package spec with the same name is already in the library. (c) Compiling a package-spec-with-abstract before its corresponding package abstract. (Analogous to compiling a package body before the corresponding package spec.) (Of course, for the GNAT compiler, you'd have to translate these into source-file dependency rules rather than order-of-compilation rules.) (3) We would also need an alternate syntax for the "with" clause, to allow a client to import only the abstract of a package. Such a client would only be able to make use of those declarations from the package abstract that were actually "complete". Later (in its body, say) a client could import the full spec via a normal "with" clause, and this would give it access to the complete view of all the public features of the package. Example: ---------------------------------------------------------------------- abstract of package Employee is -- note additional syntax type Object is tagged limited private; -- This is an example of an incomplete declaration that -- can be "tolerated" in a package abstract type Pointer is access all Object'Class; None : constant Pointer := null; -- These are examples of complete declarations (or are they?) end Employee; ---------------------------------------------------------------------- with abstract of Office; -- examples of import of package abstracts with abstract of Memo; with abstract of Meeting; with abstract of Job_Description; ... package with abstract Employee is -- note additional syntax ... function Office_Occupied_By (The_Employee : in Employee.Object'Class) return Office.Pointer; procedure Occupy_Office (The_Employee : in out Employee.Object'Class; New_Office : in Office.Pointer); -- mutually recursive with Office.Accomodate_Employee ... private type Object is tagged limited record ... Its_Occupied_Office : Office.Pointer; Its_Job_Description : Job_Description.Pointer; ... ... end record; end Employee; ---------------------------------------------------------------------- with Office; -- normal import of full package specifications with Memo; with Meeting; with Job_Description; ... package body Employee is ... function Office_Occupied_By (The_Employee : in Employee.Object'Class) return Office.Pointer is begin return The_Empoyee.Its_Occupied_Office; end Office_Occupied_By; procedure Occupy_Office (The_Employee : in out Employee.Object'Class; New_Office : in Office.Pointer) is use type Office.Pointer; begin if New_Office /= Office.None and then New_Office /= The_Employee.Its_Occupied_Office then begin Employee.Vacate_Office (The_Employee); The_Employee.Its_Occupied_Office := New_Office; Office.Accomodate_Employee (The_Office.all, The_Employee'Access); end if; end Occupy_Office; ... end Employee; ---------------------------------------------------------------------- Obvious Problems: (1) It's certainly pretty late in the game to consider this kind of thing for Ada9X. Maybe Ada0X could do something with it. Also, I haven't studied the whole MRT history, so I don't know if someone has already thought of something like this. I don't want to take credit (or blame :-) for someone else's idea. (2) In making this suggestion, I am engaging in the execrable practice of "YALFing" (where YALF = "Yet Another Language Feature" :-). This extra feature might make it trivial to write code in this particular style, but is it worth the added complexity to the language? (I'm still holding out hope that there is some elegant way of combining the *existing* features of Ada 9X to support this coding style.) (3) Is a pointer type really "complete" by the end of a package abstract? What if, instead of a private type, the Object type in the package abstract were an incomplete type declaration that got completed in the *public* part of the package spec? What if that complete type were a record type or an array type? Would a client-of-spec be able to use record-component or array-indexing syntax with the pointer type, whereas a client-of-abstract would not? (4) Could a package-with-abstract be generic? Where would the generic clause go? On the abstract? On the spec? On both? If both, would they have to be identical, or could the abstract introduce some generic formal parameters and the spec introduce more? How would instantiation work? Would you need an alternate syntax for instantiation-of-abstract vs. instantiation-of-spec? What if a client instantiated the abstract and then later instantiated the spec with the same name and actual parameters? Would they be two views of the same instantiated package, or two different instantiated packages? What if you tried this at the library level? What implications does all of this have for the generic contract model? Not being a language lawyer, I'm sure there must be other conceptual difficulties and complexities. I can't begin to assess what it would cost you compiler-writers out there to try to implement this feature, but I can well imagine it giving you the screaming willies^H^H^H^H^H hillaries! ;-) -- John Volan > -- Adam >(P.S. John, how about we get together and start our own church? :-) Dibbs! I get to be pope first! :-) -------------------------------------------------------------------------------- -- Me : Person := (Name => "John Volan", -- Company => "Raytheon Missile Systems Division", -- E_Mail_Address => "jgv@swl.msd.ray.com", -- Affiliation => "Enthusiastic member of Team Ada!", -- Humorous_Disclaimer => "These opinions are undefined " & -- "by my employer and therefore " & -- "any use of them would be " & -- "totally erroneous."); --------------------------------------------------------------------------------