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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-30 17:03:40 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!shaw.ca!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 30 Jan 2004 19:03:38 -0600 Date: Fri, 30 Jan 2004 20:03:36 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions References: <1075159458.149886@master.nyc.kbcfp.com> <1075225041.167448@master.nyc.kbcfp.com> <1075303237.975898@master.nyc.kbcfp.com> <9khh10pti0dn8gcp7f18ghptaifluj0fud@4ax.com> <1075390647.405841@master.nyc.kbcfp.com> <1075405582.982776@master.nyc.kbcfp.com> <1075478950.231615@master.nyc.kbcfp.com> In-Reply-To: <1075478950.231615@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-blyhB6MadYluZCnajgdfOBXFa5ZSLGKLWCIxOK7oUQSviv/YuebmRdU7lWT2mUtOdMGoHkXFcdZqBXS!gtaB40YrmCu204+b3cn5RLtEoIjxPoMZo2Q8QmOdxBR5awgjb0rBtL5jg1Zexw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5130 Date: 2004-01-30T20:03:36-05:00 List-Id: Hyman Rosen wrote: (Others have done a good job of answering most of Hyman's points, but...) >> To change the rules now would make lots of code obsolete. > How can defining something which was previously unspecified > make code obsolete? I'm not saying that Ada should change > any specified behavior it currently has, I'm just saying > that currently unspecified behavior should become specified. Your assumption is that you could create a new rule which makes the new language a subset of the old one. In one sense, that is easy. Keep all the old legality rules and just add new ones. Some existing programs will no longer compile, but if they do compile, they will have the same semantics as before. I don't think you can come up with a set of rules like that without a lot of effort, but you are welcome to try. The SPARK people certainly took that path and did it successfully. But what if you keep the legality rules the same, and "just" change the semantics? Then the problem is proving that existing code will have the same semantics under the new rules as under the old ones. The current situation is that order of evaluation in Ada is partially specified. I know of lots of code which was validated in part "by hand" and in part by tools which recognize the current Ada rules. If the semantics change, recompiling this code makes all that analysis junk. (For example, red/black analysis in crypto code.) If you want to reuse the existing code with new code, it is impractical to redo that analysis. (The code is often written so as to make the analysis easier. But it won't necessarily be that easy for the new semantics.) So you either use a "project validated" compiler, or throw the code away. I know what I would do, and changes in Ada that would make using "new" Ada compilers an issue are just what I said, a non-starter. Notice that I and many other programmers know the existing Ada rules very well, and so does the SPARK Examiner. That is one measure of how much would be thrown away by a major change to 11.6. Incidently Ada 95 did change 11.6. But it is worth noting that the changes were to resolve AI-315--remember that is an Ada 83 AI number--which we never found a fix for that wouldn't do too much damage to the language and to compilers. Since Ada 95 was a much bigger change than Ada 0Y will be, we accepted that change then. But not without a lot of soul searching. It may have been that more soul-searching would have been worthwhile. (The change is to define canonical semantics in terms of external effects.) See 11.6(3) and 1.1.3(8-15). In fact, I think that one change did more to slow the adoption of Ada 95 than any other change from Ada 83. > There's certainly work involved in the compiler to make it > evaluate things in a specific order. I personally would not > classify it at the "go away" level. I know that GCC includes > a Java compiler, so it at least has infrastructure for doing > this at some level. Once again, the problem is not with the compiler. The whole idea of the entire HOLWG effort, even before GREEN became Ada, was to reduce the number of programming languages and compilers used by the DoD so that an infrastructure of support tools could be built around one or more core languages. The HOLWG then decided that no existing language was sufficient as a base language for embedded system programming and tools. That started a process that ended up creating Ada. SPARK is one of the few non-compiler Ada tools that has reached the necessary critical mass to be able to say that it won't go away. Other tools are part of the support infrastructure for each compiler, and should last at least as long as the compiler does. An example in this category is gnatchop. There are lots of other tools, such as GtkAda that have not reached the plateau, but if Ada usage keeps growing they will get there. Or you can consider Rational's tools. Rational made a business decision to develop those tools for several languages, primarily C++ and Ada. It might be interesting to find out what the relative sizes of the Ada and C++ markets are for Rational's tools, but from the original HOLWG viewpoint, it is irrelevant. The tools are commercial, and the tools are available. Anything else is gravy. So in my opinion, any change to Ada which had the effect of invalidating existing toolsets is a non-starter--and a bad idea. Incidently there is nothing preventing anyone reading this from getting the GNAT compiler source and modifying it to support, say, in out parameters for functions. But if you want to try a major change like the one Hyman is suggesting, I know I wouldn't have the energy or patience to try it. A change like in out parameters for functions is localized, and even thought the localization may only be to a dozen places in the code, it shouldn't require modifying more than 5 KSLOC. Changing the order of evaluation rules would affect a substantial fraction of the entire compiler. Call it reviewing 500 KSLOC and modifying 100 KSLOC. Put out an RFP and I'll "No bid." ACT might respond. ;-) -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush