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-22 09:39:40 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!priapus.visi.com!orange.octanews.net!news.octanews.net!news-out.visi.com!petbe.visi.com!129.250.169.16.MISMATCH!pln-e!lotsanews.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: <49cbf610.0401170627.79c3dfe5@posting.google.com> <400A9B48.3060100@noplace.com> <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> In-Reply-To: <400FC8E8.2040100@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 22 Jan 2004 12:25:18 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1074792264 198.96.223.163 (Thu, 22 Jan 2004 12:24:24 EST) NNTP-Posting-Date: Thu, 22 Jan 2004 12:24:24 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:4658 Date: 2004-01-22T12:25:18-05:00 List-Id: Marin David Condic wrote: > And that only expands geometrically if you try to support enumerals for > other vendor's implementations in order to be able to accept code built > for their compilers. > > How about *adding* something to system like: > > System.Compiler_ID : constant String := "Something Useful Here" ; > ... > You still need some mechanism to wrap that around declarations and other > stuff. Perhaps that could be solved with some flavor of a pragma that > could take a case-like if statement around what you want conditionally > compiled. Maybe the whole thing should be solved with a pragma since you > don't want to have to first "with" System before you can start > conditionally withing other packages. That also gets simpler to deal > with from a language perspective since there has always been the ability > to have implementation defined pragmas. > > MDC ... Not only do you have system(s) to worry about, you have version(s) of system(s), you have optionally installed component(s) and choice(s) in compiler(s) as well. If you are writing source code to accomodate these different variables, you have quite a source code issue on your hand. Here are a couple of examples: - Are you using: - GNU curses library? - the real UNIX curses library (or non BSD variant)? - are you using PDcurses library? - Does the user have (and want to use) the readline library? These are just two cases, which require you to configure your code. Blocks of code are unnecessary if no readline support exists. Whether you are using PDcurses, UNIX curses or GNU curses requires you to work around bugs and shortcomings in different ways. I havn't re-checked, but IIRC, Florist ends up generating a large portion of specs, and I suspect that bodies are probably "processed" as well. Any bindings related code, gets very quickly into the need for conditional compilation. Part of the Florist need for generated specs is due to the constants that must be ferreted out of C header files. But the other reason to #if is related to whether a particular API is even present on the platform of choice, and whether or not certain structures (records) are required. In bindings, you often run into optional structural components as well. The system call stat(2) for example uses a structure. But the members of that structure changes, depending upon the POSIX platform chosen. The only way to avoid this is to dumb it down so much that all platforms provide the same thing. But this doesn't work well with stat, because you'd have to dumb it down a lot, to achieve full portability - causing needed functionality to be lost. -- Warren W. Gay VE3WWG http://ve3wwg.tk