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,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-15 10:03:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!elnk-nf1-atl!newsfeed.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X Date: Sun, 15 Jun 2003 10:05:55 -0700 Organization: AdaWorks Software Engineering Message-ID: <3EECA772.4B662024@adaworks.com> References: <3EE7CC70.E1FD3A67@adaworks.com> Reply-To: richard@adaworks.com NNTP-Posting-Host: 3f.bb.68.d2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 15 Jun 2003 17:03:53 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:39200 Date: 2003-06-15T17:03:53+00:00 List-Id: Steve wrote: > In my opinion the benefit of += has nothing to do with efficiency or ease in > writing. It's all about readability. If we adopt this syntax, in Ada, we will need to include some rules in the language to enable the compiler to discern a clear difference between the += and :=. That is, in Ada's current model, we want to compiler to be able to tell us when a construct is a mistake or warn us when it will potentially create an incorrect execution. What rule can you come up with that will enable the compiler to, at minimum, warn the programmer that this, i := 1; i += 1; poses no hazard. It is bad enough that, in many derivates from C, a legal but erroneous code can be created when the programmer confuses the = and the = =. This cannot currently happen in Ada, ever. So, if there is some approach that will ensure that my i += 1 could not be a mistake for i := 1, that would go a long way toward making it an acceptable construct. Granted, in C the = symbol is an assignment. Therefore, the = = will not be mistaken for a +=. However, the use of these shortcuts can have interesting results when used incorrectly. Consider the difference between ++i and i++. Often this will not create a problem. Often it will. The readability we emphasize for Ada is not suggest human readbility. It also includes compiler readability. We are striving for less ambiguity in the language, not more. Therefore, each new feature must be evaulated in terms of its potential ambiguity, not just for the human reader, but also for the compiler. In this regard, Ada is a leader, not a follower. Leaders are not always popular. Ada may never be popular, but it will continue to be the best language when one requires a language with internal consistency, lack of ambiguity, and a focus on high-iutegrity software. It is very easy to become enamoured of a particular syntax. Many a young man has lost his heart to a pretty face only to discover that the underlying personality was incompatible with his own. Ada is not designed to be just another pretty face. It is designed to support a serious set of goals, consistently, correctly, confirmably, and coherently. We might add, correctly compilable, because that is the ultimate test of any new syntactic feature. Perhaps I am an old fuddy-duddy when it comes to Ada. However, my programming experience pre-dates the advent of Ada by some considerable number of years. I have made, during my career, as many or more programming mistakes as anyone alive. Perhaps that is a function of my cultivating my own stupidity more effectively than most of my contemporaries. One reason I appreciate Ada is the way it helps me look smarter than I really am when creating code. I rely, perhaps too much, on the compiler to trap those silly little mistakes I so often made when programming in some earlier languages, including Assembler, COBOL, Fortran, PL/I, Neat 3, BASIC, C ( and later C++) to name a few. So, when you can define, using well-formed semantics, how the compiler will be improved (not the popularity of the language), how error-checking will be sustained, and how my own stupidity will be mitigated, by the addition of this feature, I will gladly admit my error and support your proposal. At this point, however, the proposal seems to be based largely on the notion that, "If C and its derivatives has it, it must be good." That is not good enough for me. I need more carefully reasoned exposition. Richard Riehle