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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-06 19:53:41 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!howland.erols.net!newshub2.home.com!news.home.com!news.mindspring.net!not-for-mail From: Lao Xiao Hai Newsgroups: comp.lang.ada Subject: Re: How to make Ada a dominant language Date: Mon, 06 Aug 2001 19:55:15 -0700 Organization: AdaWorks Software Engineering Message-ID: <3B6F5893.8F620D80@ix.netcom.com> References: <3B676974.C80C72E5@sneakemail.com> Reply-To: richard@adaworks.com NNTP-Posting-Host: 9e.fc.c5.3f Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 7 Aug 2001 02:53:28 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:11439 Date: 2001-08-07T02:53:28+00:00 List-Id: This has been an entertaining discussion. There are several points that Russ makes that deserve some careful response. Some earlier messages covered some of the points. Most of those responses dealt with the syntactic issues. I choose to respond to his "with" / "use" observation since this is at the heart of Ada's design. As a prefatory remark, we note that the default of every Ada construct intended to be safe. One can take a default of safe and relax it to a construct that is less safe. It is more difficult in a language where the default is unsafe, to promote a construct to one that is more safe. Chapter Eight of the Ada Language Reference Manual has a set of carefully delineated rules regarding the difference between scope and visibility. In my experience, more programmers have more difficulties with Ada because of these rules than any other part of the language. Yet, we see that most programmers choose not to study this issue until their frustration emboldens them to dash their mouse to the floor and smash it in rage. The language design for Ada is unique in its differentiation between scope and visibility. More recent language designs, for example the namespace option of C++, have adopted a somewhat anemic version of this feature, but Ada remains more powerful in this respect. An #include statement in some popular languages has the approximate semantics of an Ada with/use combination. I say approximate because there are some additional rules that make Ada a tad more reliable. Consider an electrician who decides to string some wire through your house. It is typical that the wire will have insulation over most of its length and some well-defined interfaces at other points, usually the terminal points. A similar kind of thing is done in many other engineering designs. A pipeline is built with specific locations where one can open or close it for extracting the content, or for adding some content. A "with" clause, in Ada, is somewhat analogous to stringing the wire through the house. We keep the insulation intact to reduce the probability of burning down the house. All the electricity we want is streaming through that wire, but our access to it is carefully controlled. If we want access to the current, we can cut a little piece from the insulation and tap into it with another wire, but we take care to replace the insulation for the splice when we are done. An #include, as defined for most languages, does not have a concept of insulation. Every feature is directly exposed, all the time. Some very interesting errors can occur in large-scale software. Since an Ada context clause ("with") makes nothing directly visible, the software engineer has responsibility to identify where to remove the insulation, how to remove it, and precisely how much to remove. A visibility clause ("use") makes everything visible. This is the equivalent of removing all the insulation at one time. Good Ada design suggests that this may be too much exposure, for a variety of reasons. Consequently, we employ one of several mechanisms as alternatives to the global visibility clause. As engineers, we should always be interested in techniques for reducing risk. The somewhat tedious technical discussion that follows is guaranteed to bore experienced Ada programmers, but may be of some use to those new to the language such as Mr. Paielli. Given a package specification, package P1 is type T1 is ... type T2 is ... procedure Process (Q_Data : in out T1); procedure Process (R_Data : in out T2); private -- private declarations end P1; we have several approaches available to controlling visibility and reducing ambiguity. The global visibility clause: with P1; use P1; procedure Test_1 is X : T1; Y : T2; Z : T2; begin if y = Z then Process(X); end if; end Test_1; For this little program, there is probably no difficulty. However, one might want to further disambiguate by ensuring the right call is made. For example, Process (Q_Data => X); would be a better choice for the parameter association. As a point of interest, it is appropriate to use a different symbol than assignment for this since the semantics of association and assignment are quite different. Another way to control visibility might be as follows: with P1; procedure Test_2 is use type P1.T2; X : P1.T1; Y : P1.T2; Z : P1.T2; begin if Y = Z then P1.Process(Q_Data => X); end if; end Test_2; In this example, we have used the more restrictive version of the visibility clause ("use type") so the equality operator will be directly visible. The problem with this is that, even though we are now required to use dot notation for all operation calls, we also make all the other infix operators visible. For more rigorous designs, we might want to avoid this approach. Often, the directly visibility of infix operators makes it easier to write some code, but it also fails to restrict the writer to those options that, from an engineering perspective, make sense. Sometimes a programmer will localize the visibility clause. with P1; procedure Test_3 is X : P1.T1; Y : P1.T2; Z : P1.T2; begin declare use P1; -- or better yet, use type P1.T2 begin if Y = Z then P1.Process(Q_Data => X); end if; end; end Test_3; This does have the benefit of localizing the visibility clause. However, a well-crafted paper by Geoff Mendal once analyzed this option and found it lacking in the rigor or disambiguity necessary for consistent reliability. Most Ada development organizations I deal with prefer the following: with P1; procedure Test_4 is X : P1.T1; Y : P1.T2; Z : P1.T2; function "=" (L, R : P1.T2) return Boolean renames P1."="' begin if Y = Z then P1.Process(Q_Data => X); end if; end Test_4; In this example, we have made the equality operator directly visible through renaming. While this may seem somewhat bizzare to the newcomer, it actually has much to recommend it, from an engineering point-of-view. This becomes especially important when one wants to really restrict the set of operations immediately available to a maintenance programmer in some distant time. Another approach I have seen useful is a compromise. I realize Tucker Taft will leap all over me for continuing to suggest this alternative, but I find some organizations are using it with some success, and a minimum of risk. This is the proactive approach of a nested infix operators package. I personally prefer it to the "use type" clause. I also prefer this to the creation of a child library unit, although that approach has much to recommend it. package P1 is type T1 is ... type T2 is ... procedure Process (Q_Data : in out T1); procedure Process (R_Data : in out T2); package Operators is function "=" (L, R : P1.T2) return Boolean renames P1."="); end Operators; private -- private declarations end P1; Now we can have a use clause on the nested package only. with P1; procedure Test_5 is X : P1.T1; Y : P1.T2; Z : P1.T2; use P1.Operators; begin if Y = Z then P1.Process(Q_Data => X); end if; end Test_5; In this case, the use clause applies only to the nested package. I hope this clarifies a few issues related to the scope and visibility features of Ada. Certainly, there is more to be studied before one can fully apprehend all of this topic. However, it is, to my mind, equally as important as the type safety that causes such a fuss. This aspect of Ada, along with type safety, is the foundation of the Ada software engineering model. We could change a lot of syntactic rules, alter the reserved word list, and lots of other things, but we would not want to relax the reliability of the language by abandoning this important feature. I hope this helps, Mr. Paielli. Regards, Richard Riehle ---------------------------------------------------------------------------------- Russ wrote: > Well, I guess I touched some raw nerves with my proposal to clean up > Ada's syntax. I certainly appreciate the feedback. > > I have come to the conclusion that my first item (eliminating the "end" > keyword and making the indentation structure an inherent part of the > syntax, as in Python) is NOT a good idea after all. The "end" lines > really do help with readability, particularly for long procedures that > end on a different page than they started. > > However, I still stand by the other items in my proposal. I think > semicolons should be essentially eliminated, and I think "=" should be > used for assignment and named association. I also still think the > declaration syntax should be reversed. By the way, someone correctly > pointed out that what I am proposing has a lot in common with Fortran > 95. > > Furthermore, I think the idea of having another "dialect" of Ada is an > innovative concept with real potential. If you reject it out hand, you > simply have a closed mind. > > Most of the replies I received on this thread were very reasonable. A > recurring theme, however, was that syntax is trivial and not worth > discussing. I understand that the syntax is not the most important > aspect of a language, but that doesn't mean it is not worth discussing > or improving. > > I have a colleague who started programming in Fortran way back in the > sixties (maybe even the fifties). He is a master algorithm developer and > programmer. His code is meticulously correct, efficient, and minimal. > When I introduced him to C and C++ several years ago, he was amazed that > he had to clutter his code with all those semicolons and constantly put > up with the compiler's nagging when one is left out. He adapted, of > course, but his initial reaction was right. All those semicolons are > nothing more than a lot of noise. They are litter in your code, and if > you never minded them at all, then your code is probably filled with > lots of other litter too. If so, I hope it is not being used in any > safety-critical systems. > > Russ Paielli