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-02-04 10:36:38 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!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: Wed, 04 Feb 2004 12:36:35 -0600 Date: Wed, 04 Feb 2004 13:36:34 -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 (Was: why ada is so unpopular ?) References: <400A9B48.3060100@noplace.com> <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <401118FD.701@noplace.com> <40126B5E.8050205@noplace.com> <99wTb.4905$bp1.159188@news20.bellglobal.com> In-Reply-To: <99wTb.4905$bp1.159188@news20.bellglobal.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-aBHo19DI2QNqKw/4c+Tcljahy8fSHZdc7g4Da9I+3+BZJ5xWRSNEXrv1IiU56ta+HjJF4hz7z+zkIhE!YwNmMN4Yw1VZyyV6opozY/Tuep7hMepvkD1KKB2G+K2dHQN+GSwJDL7t9d3nUg== 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:5241 Date: 2004-02-04T13:36:34-05:00 List-Id: Warren W. Gay VE3WWG wrote: > Robert I. Eachus wrote: >> Hmmm. I won't say that this is not a potentially killer problem. >> Just that the issue has nothing to do with configuration clauses. > > > That statement is rather strong. This kind of thing is > handled in the C/C++ world all the time as a configuration > item. Now we could argue whether it should or not, but > I don't want to beat on that dead horse here. > >> First let me deal with the different size issue... > This does work I suppose, if you add the different pragma Imports > to do the mappings between C_Routine and Different_C_Routine to > the same C function xyz(). Yep, I left that part out as obvious. I still think we are violently agreeing. I have no objection to using a preprocessor with Ada when needed, and I expect that good compilers will provide one. > But this type of a solution can explode > if the variations to the different versions of OS kernels is > added. Linux for example has gone through many revisions, and > so IMO, it is much simpler to define pid_t as a particular type, > once and for all, once you know what it should be. If you > had to code for these variances everywhere a pid_t was > involved, it would be much more ugly than the > conditional compiled solution. > > But, that is _opinion_, and I expect that we'll disagree > about that. No, if it makes sense to export pid_t as an abstract data type, then do it, and the Linux version dependencies are all in that package. If you only use pid_t in one or two places, then that is a waste of effort. Each time we work on a project, both you and I will make hundreds of such decisions. I don't think it is right to force anyone to do something in only one "Ada approved" way. >> Why all the dire words up above? We used to call it "version skew." >> If your project depends on components and tools from more than three >> vendors or from the same vendor with different update schedules, you >> can have the problem that there may never be a consistant set of all >> three that works together. That is a problem outside the ability of >> anyone here to fix. All you can do is to choose the components that >> your project DEPENDs on, and keep that list small. > > But this was my original point: if this is done successfully in C/C++ > every day, then why can we not provide the same capability > (albiet in a better way) to compete at this same level? > Because of the conditional compilation bias, people want > to explain away the need for it. I have seen many projects killed by version skew. I could go so far as to say it is the number one killer of all projects, and all open source projects. As you depend on more external applications/systems the number of potential version skew problems goes up as N(N-1)/2. If your code only depends on say, GNAT, no version skew. (Or from another project's point of view, one opportunity for version skew, since your project may not work with all versions of GNAT. But when you have a system that depends on the OS, the compiler, a graphics package, a database, and a browser, N is five. The number of potential mismatches is 10. That can be dealt with in an embedded development project--choose a set of versions that work together and never change any of them. But for an open source project you can't do that. And that is why bringing other standards into the language and compiler is a win. Every standard that becomes explicitly part of the language or implicitly through support by most compilers means that the compiler developers deal with the version skew, and you don't have to. > Anyway, I have said my piece on this subject. I have > no energy to flog this dead horse even more. I already > know what I have to do ;-) Same here. I can't slay the version skew monster, but I can try to minimize the number of cases it comes up. Where we differ is on which is the best way to do that. I want to bring as many "standard" interfaces inside the Ada boundary as possible, you want to standardize the preprocessor. As I have said before, I have no objection to that, as long as you don't expect the ARG to do it. Expecting WG9 to do it is another issue, and I don't have a strong opinion on that, other than a PRG or whatever should be created instead of assigning the problem to the ARG. Remember that in several cases issues have been treated exactly this way, only to eventually end up in the Ada standard. For example, there was an awful lot of work done by the NUMWG and the NRG on math packages for Ada. I participated a small bit mostly as a liason with the ARG to explain why some particular proposals caused other issues in the language. Other such groups include the CRG (character sets) and the work done on information systems that eventually ended up as Annex F and decimal types. -- 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