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 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-23 09:30:32 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!c03.atl99!sjc70.webusenet.com!news.webusenet.com!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" 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: <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <4011127C.4030801@noplace.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 23 Jan 2004 12:16:20 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1074878128 198.96.223.163 (Fri, 23 Jan 2004 12:15:28 EST) NNTP-Posting-Date: Fri, 23 Jan 2004 12:15:28 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:4725 Date: 2004-01-23T12:16:20-05:00 List-Id: Dmitry A. Kazakov wrote: > On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic > wrote: > >>That's why much as I might find some kind of preprocessing distasteful >>and certainly don't want to watch it degenerate into the unholy mess >>that you have with C, I think we need *some* mechanism for conditional >>compilation. >> >>Those who argue that it should all be isolated with different package >>bodies have to address the fact that a) this is often difficult or >>impossible ... >>and b) it implies some kind of configuration management or >>build utilities that are totally outside the scope of the language and >>may not exist. > > But the language defines the notion of a library. If we could extend > it in a way allowing selection of a child units path during > compilation, then I believe, it could be 80% of the issue. Whether the problem is 50% or 20% is not the issue. The problem is that even if I have a 2% problem, it is a _royal_pain_(TM). If you have to support different implementation defined pragmas, if you have to support optional record components (in bindings to OS services or to different C libraries like readline), then whether the problem is big or small, it is unsolved if it ain't 100% solved. >>I'd like to be able to hand off a collection of source code and say >>"This is the main program - just compile it from there on your >>machine..." If it involves different bodies, I've got to provide you >>with detailed build instructions and can't assume you've got the same >>tools as I do. All that gets fixed automagically if I could put some >>conditional compilation statements into the code that indicate which way >>to go based on some kind of directive to the compiler. (I don't trust >>something in the package System to be sufficient - that at best can only >>tell you about the compiler, but not necessarily about the external >>platform and its potential variations.) > > If we could limit variations to compilation units, I think we could, > then there might be a better way than preprocessing. As soon as you start splitting code into different parallel "files", you are denormalizing and decentralizing your code. This is maintenance hell. If you find a bug in one of these "portability" unique files, then you have to edit several files to effect the same fix. It also much more difficult to view the impact to other "platforms" for such a fix. Don't get me wrong. I support the push for a better solution, but I haven't seen any evidence of anything better than a conditional compile. Whether conditional compilation comes about by preprocessing or as part of the internal compile process, I don't care (compiler writers will care however). But I think that the lack of portability in Ada does hold it back for more general use. > We could invent some sort of abstract packages [units], providing some > interface (types, values, procedures) without any implementation. So > types and constants could be declared incomplete there. Then a set of > normal compilation units could provide various > platform/condition-specific implementations of an abstract unit. Using > such an unit in "with", "use" etc should select an implementation at > compile-time from the set of visible concrete units. That would be > some sort of polymorphic compilation units. MDC also pointed to the need sometimes to do conditional "with" in a compile. If I am using GNAT, I may need (or find it convenient) to use a GNAT.* package. If I use another Ada compiler, I may want to use some other vendor provided packages for similar functionality. Of course, depending upon what you "with", will also conditionally change what you want to compile. So in the end, there is a strong need for "conditional compiles". If we can agree on that, then let's leave preprocessing out of the discussion and focus on "conditional compilation". How that is achieved is an implementation issue. Again, perhaps conditional compilation should also be optional to placate those who will have no part in it ;-) (perhaps enabled by compile option). -- Warren W. Gay VE3WWG http://ve3wwg.tk