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,93fa00d728cc528e X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,93fa00d728cc528e X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 1994-10-25 11:25:31 PST Newsgroups: comp.lang.ada,comp.object Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.mathworks.com!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger Date: Tue, 25 Oct 1994 16:43:14 GMT Message-ID: <1994Oct25.164314.28453@swlvx2.msd.ray.com> References: <38hcv3$j85@baleen.cs.ucla.edu> <38i65r$li2@network.ucsd.edu> Sender: news@swlvx2.msd.ray.com (NEWS USER) Organization: Raytheon Company, Tewksbury, MA Xref: nntp.gmd.de comp.lang.ada:16151 comp.object:16565 Date: 1994-10-25T16:43:14+00:00 List-Id: mbk@inls1.ucsd.edu (Matt Kennel) writes: >Jay Martin (jmartin@baleen.cs.ucla.edu) wrote: >: Ada9x is too obese and is being too effected by trying to be an >: "elegant" (rigid) extension of obese Ada83. I really don't understand >: why can't some clown spend a few minutes to come up with a cleaner >: smaller (more minimalist) Ada style language. >That's what Meyer did, it's called Eiffel. Really. Ada83 was a big >influence. Eiffel is nice. I like Eiffel. But is Eiffel really enough? Why does Eiffel need LACE to prop it up, for instance? >Absent this, the problem here in 9x can be "solved" by a nearly transparent >change to the language: say "cyclic dependencies in types, but not >initialization expressions, are now allowed." like >it always should have been, in my opinion. I dispute that this is a "nearly transparent" change to the language. Other folks have already pointed out to you that Ada's order-of-declaration dependencies reflect an underlying assumption about declarations: They all get *elaborated* at run-time, in a specific order. That is, every declaration "takes effect" at a specific point in time during execution, and this might (or might not, as the case may be) cause something to occur at run time (such as initialization). This rule applies to *all* declarations in Ada, including variable declarations, type declarations, subprogram declarations, package declarations, what have you. Your answer to this seems to be: "Well, let's single out one kind of declaration -- type declarations -- as a *special case* that totally violates that general rule, just to make one particular style of programming easier, or to make Ada more closely resemble somebody else's pet language. Go ahead and refer to types that haven't been declared yet -- even types from other packages that haven't been *compiled* yet. We don't really care who gets elaborated first ..." IMHO, that road leads to madness. If you establish broad language design principles, but then overrule them for special cases at every turn, you wind up with a recipe for a bloated, complex, and incoherent language. No thank you. A lot of the additional power in Ada9X over Ada83 has arisen as a direct result of *broadening* the application of Ada's original principles, *eliminating* special-case situations, NOT adding new ones. >Now you can declare an X which has a component of type/package/class/whatever >Y, and have Y which has a component of class X. "Type/package/class/whatever"???? Again, you're conflating all these things to be the same thing, as if Ada were Eiffel. >It's not transparent to the compiler implementors, but no fix >here would be. Of course. But I would rather live with "package abstracts" than "automagically forwarded types." -------------------------------------------------------------------------------- -- 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."); --------------------------------------------------------------------------------