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,38159b1b5557a2e7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-29 19:20:53 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: Thu, 29 Jan 2004 21:20:51 -0600 Date: Thu, 29 Jan 2004 22:20:50 -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: Standard Ada Preprocessor References: <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <_JSdna166JuxFo3dRVn-hg@comcast.com> <401115B7.5020205@noplace.com> <101djamfnrb185a@corp.supernews.com> <101gh24t2rkcma9@corp.supernews.com> In-Reply-To: <101gh24t2rkcma9@corp.supernews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4ZqdncEqFrsJUITdRVn-ug@comcast.com> NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-CwDRE+RqI4FvxAOW0QQmNa/fUPrPbH+FM1/RWUk0w5T9K2v1FRtL0/8sIQ5WpuYF9NIpg7cUxzj3bJN!272SF4AG/b3yyR6bgRNgNRi7fP+F4fhpYAGtDVKvfgEXTSubgSt3zNHGLMRdCg== 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:5084 Date: 2004-01-29T22:20:50-05:00 List-Id: Randy Brukardt wrote: > Updating the Ada standard is as much a political process as it is a > technical one. In this case, I and others tried to get a solution added to > Ada 95. There was too much opposition at that time. Given that nothing has > changed, I'd expect the same result if the same solutions are presented. > Indeed, we have a meta-rule that we won't even waste time on issues decided > during Ada 95's development unless there is significant new information. > (The few that have come up, like 'in out' for functions, have ended up with > precisely the same results as the last time - even with new information.) > > The only new information that I could think of that would help here would be > an elegant solution. Certainly, the fact that the problem exists - or its > scope - haven't changed a bit in the last 12 years. I'm going to spend my > time on issues that have a chance to be approved (like a limited containers > library), not tilting at windmills. (I've done enough of that in the last > couple of years.) > > Otherwise, you'll get have to use a non-standard solution like Gnatprep. What Randy says is 100% correct. There is a lot of work invovled in updating a language standard, and this time around there is no full-time team working on Ada 0Y, so things that didn't make the cut in Ada 9X are even less likely to get in this time. However, having said that, I will continue to work on making it easier to use Ada in place of a pre-processor language. The main requirements for that, as they have been all along, are major goals of the Ada community. As long as there is "only one Ada," and Ada compilers do static code elimination, then it is possible to use Ada if and case statements for conditional code. Yes, I know that there are some things you can't do this way. But I haven't found them to be a big deal. For example, if I have numeric code that uses 32 and 36-bit integers depending on target, I know how to define a portable integer type that doesn't require creating a 36-bit integer type on hardware that doesn't support it. Floating-point is a bit harder, but there what really changes is whether there is a type with more precision than IEEE double, and what it is called. That IS a case where I do have multiple bodies, but since the code for machines that support IEEE extended and those that don't is totally different, I don't mind mantaining separate bodies. -- 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