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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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-19 19:03:24 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!border2.nntp.ash.giganews.com!border1.nntp.ash.giganews.com!firehose2!nntp4!intern1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!feed.cgocable.net!read2.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3FBC2EEC.212A1B5@cogeco.ca> From: Warren Gay Reply-To: warren@cogeco.ca X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2003 22:03:08 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read2.cgocable.net 1069297408 24.150.168.167 (Wed, 19 Nov 2003 22:03:28 EST) NNTP-Posting-Date: Wed, 19 Nov 2003 22:03:28 EST Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:2706 Date: 2003-11-19T22:03:08-05:00 List-Id: Stephen Leake wrote: > "Stephane Richard" writes: > > > Maybe the Ada folks need to design a C/C++ to Ada > > "binder", that is able to reliably take a C/C++ > > include file, and generate a spec and body that > > can be used by other Ada programs (in thinish > > binding mode). > > > > THIS NEEDS TO BE A STANDARD TOOL, that can be > > counted on to work (no tweaking required), > > to be consistent, and to be available with > > the COMPILER toolset. > > Old news. Been tried many times before. Not possible in practice. > > The C preprocessor is just too powerful, and is used in too many > interesting ways, to make this work. I don't buy defeat at the pre-processor level. You give CPP too much credit ;-) Let's give this tool a name, say "thinbind" for discussion purposes: What thinbind would be required to do, is to preprocess the header file somewhat differently than the C's preprocessor. Instead of expanding all macro source code to C source code in one pass, you would need to use an iterative approach. Consider: Pass: #1. Preprocess, expanding all C macros that involve code that does not compile into a constant (ie. any code fragment, or aggregate initialization construct etc.) #2. Iterate #1 as necessary, until all code fragment macros have been expanded into C/C++ expressions that can be compiled into a single constant (string or numeric) #3. All macro definitions that can compile into a folded constant, can now be translated into Ada constants of some form (universal numbers, unless overruled by the hints file, and string constants for use within the generated spec). #4. Process full macro expansions (this now removes _all_ #defines from the header file). This may include macro function/procedures. #5. Process all structures, constants and function prototypes, typedefs etc. (ie. everything else that C provides) I believe iteration at the steps 1-2 are necessary, because the C preprocessor may boil certain expressions down to constant or string expressions, with enough macro substitutions (you wouldn't want to lose out on these possibilities). Macros are often nested to produce a consumable "manifest value". 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. 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. These would be non-trivial tests to make, and yet, I believe these are not insurmountable either. For example, visibility tests for all named arguments, constants and functions could be done. If any of them come up undefined (or in conflict), then you can assume the macro just defines a code fragment. #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)). To help the process, you may want to give the programmer the option of a hints file (vs comand line options, which may be too many). This can be preprocessed itself to allow conditional compilation of what hints to use (to be very portable in the C sense). It could identify macros that should not be expanded into procedures/functions for example. It may provide a number of other hints, like entities that if present in the header file, the Ada programmer is uninterested in (perhaps C uses it as an intermediate macro to achieve the end result). Or perhaps there may be cases where you want to force something, or you need to resolve an ambiguous case. Maybe you want a set of macros to be of a certain type, or to use a default type. Obviously name case is another C/C++ complication, and this can make the generated code ugly. However, thinbind can check for clashes if the name case is squashed, and only use ugly distinguishing caseless conventions where clashes occur in the Ada namespace. The hints file can also be used to resolve this with an Ada friendly name of the programmer's own choosing. Obviously, C++ presents some special challenges. C++ templates may not be practical to do, as some other poster has pointed out. But I see that as a phase II project at best. But I think C code can be handled in a well defined way. This could be a proof of concept project for the C++ effort to follow. Warren.