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,60e2922351e0e780 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-20 10:15:59 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!cyclone.bc.net!news.uunet.ca!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: Re-Marketing Ada (was "With and use") References: <3FB0B57D.6070906@noplace.com> <3FB22125.1040807@noplace.com> <3FB3751D.5090809@noplace.com> <3FB8B9BC.5040505@noplace.com> <3FBA1118.4060105@noplace.com> <0fxub.48425$bQ3.12107@nwrdny03.gnilink.net> <3FBC2EEC.212A1B5@cogeco.ca> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 20 Nov 2003 13:01:27 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1069351250 198.96.223.163 (Thu, 20 Nov 2003 13:00:50 EST) NNTP-Posting-Date: Thu, 20 Nov 2003 13:00:50 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:2754 Date: 2003-11-20T13:01:27-05:00 List-Id: Lutz Donnerhacke wrote: > * Warren Gay wrote: > >>What thinbind would be required to do, is to preprocess the header >>file somewhat differently than the C's preprocessor. Instead of > > This destroys most of the original C API in a unusable way. Rubbish. The whole purpose of preprocessing it in thinbind is to compile a package for Ada use. It need _NOT_ be the same. You only need to arrive at the correct internal answers. There are many ways to skin a cat (pardon the expression to cat lovers out there). As long as the end results work, then you as the user, do not care about 1 pass, 3 passes or n passes. You might care about performance, but given the choice between coding a thin binding by hand or having your computer do it for you, I think the choice is still and easy one. The challenge is to do it well, to make it work in a platform neutral sort of way (the generated thin binding should look consistent in all platforms, so that the clients of the binding won't fail to compile). >>Obviously any macros that provide C programmer conveniences, would >>be a challenge (like putchar()). It should be possible >>to infer inline Ada functions from them. I suppose one could apply the >>following C test : >> >> Case 1 : with or without macro arguments >> Does the code fragment represent a complete compilable >> C statement/block? If so, is there an implied return value? >> Define an inline procedure/function with >> or without arguments matching the name. > > > Hard work. Especially when considering marco expansion down to the plain > syscall (Linux). You don't care about operating system details. You only care about things at the C compiler level. Yes it is difficult, but this is no more difficult than what GCC does now for optimization and compilation. >> Case 2 : the defined macro components appear to not represent >> a complete statement, nor block of code. Just drop the >> code fragment, because it has already been used >> earlier for macro expansion and is no longer required. > > > Almost all API constants are marcos. A major part of structures are of compiler > option dependant design. Several structures are different in the man page > and in the implementation. Several macros are used to transform the API > conforming code into the real structure. This can't be ignored. I am not suggesting that the macro expansions be ignored. But some of them have to be expanded along the way to provide the correct view of the code. But the other objective is to come away with macro definitions that fold into constants. These can be coded into an Ada spec. A tricky process to be sure, but this can be done. >>#1 is also complicated by "do you expand macro functions?", or >>do you "translate them into Ada inline functions?" I think you would >>need to need to do both (a hints file could control this (see next)). > > Thin binding to C is expected as a function/procedure and some > types/constants which can be combined like described in the C API man pages. > > So you have to start from the man page and fill in the blanks by designing > the Ada types(!) and calls like expected. Your point isn't clear to me. Name an example. Lets take an example: #define increment(x) (++x) Now you're right that there is no type information here. But this can be written as a generic procedure. No type information is required here. > Then you have to find out how > these API-types are really defined and used. In a good number of cases you > need quite a different type than described in the man page. C does not know > about variant records and therefore collects a lot of things via unions and > some paragraphs of English text. This has to transformed to an approbriate > Ada type. No argument about unions. However, I do believe that Ada0Y is opening the door to that solution. >>But I think C code can be handled in a well defined way. > > > I tend to disagree. BTDT. It won't be a trivial task, but surely it is no MORE difficult than a compiler. After all, what we're speaking of here is "compiling" C header files into Ada. If a C compiler can translate C code into object code, then I am not convinced that another C compiler could not generate Ada code. In this case, we are only interested in a thin binding, not a complete translation of the code. Because of these trade offs, some things become easier, while other things will challenge. I have already acknowledged the practical need for a hints file. I do agree that there will be some C things that it will be hard to automate completely. Perhaps some Computer Science major will take this project on? Professors out there looking for project ideas? Let's see if this is practical! -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg [Remove nospam from the email address: the worms made me do it!]