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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6413b417b806eb28 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Accessing C macro constants from Ada95 Date: 1999/04/13 Message-ID: <7ev9ft$n9m$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 465833516 References: <7eg43i$d3b$1@nnrp1.dejanews.com> <370CC730.4C6112DB@utech.net> <370D7007.2D3AD58B@rocketmail.com> <7el9so$geb@drn.newsguy.com> <7elrg5$egk2@ftp.kvaerner.com> <7emjk8$rp3@drn.newsguy.com> <7ep6uj$o97$1@nnrp1.dejanews.com> <7eqoj2$r27$1@pegasus.csx.cam.ac.uk> <7erp6b$o3f$1@nnrp1.dejanews.com> <7ev36j$34t$1@pegasus.csx.cam.ac.uk> X-Http-Proxy: 1.0 x13.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Apr 13 11:23:47 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-04-13T00:00:00+00:00 List-Id: In article <7ev36j$34t$1@pegasus.csx.cam.ac.uk>, mgk25@cl.cam.ac.uk (Markus Kuhn) wrote: > In Robert Dewar writes: > |> Note incidentally that there is nothing to stop a given > |> compiler from implementing: > |> > |> X : constant Int; > |> pragma Import (C, X, "header.h/X"); > > Yes, that is exactly what I was thinking about. This > would simplify the fully automatic, portable, and > comfortable generation of thin C bindings > significantly. To me, this seems a very minor issue, since it can perfectly well be done by a competent binding generator tool, what does it matter whether the tool generates a pragma Import of the above form, or an appropriate constant definition (obviously the latter is preferable, since it would be a static constant, making the former static is problematic). > I really do not see the big difficulty here. The > specification of this Ada pragma for importing constants > from the C preprocessor macros could just reference the > ISO C standard to get all the required semantics > and terminology readily specified there. Not by a long shot, this would be VERY difficult to do. The C preprocessor is a completely unrestricted macro processor, and obviously arbitrary macros cannot be handled. Specifying what could and what could not be handled could not be done simply by reference to the C standard (by the way, is the C standard freely available? that would be an absolute requirement even if it were practical). > Similarly, in an implementation, compilers like GNAT do > already have a full C preprocessor built in, because they > also happen to be full C compilers, so just use the > existing C mechanics to process the *.h files. No, that won't help. If you preprocess a header file, you lose the semantic information of what is going on, in particular the disapearence of macro names will obscure things within a given header. For example, if we have #define LOWPRIO 10 #define HIGHPRIO 52 #define DEFPRIO ((LOWPRIO + HIGHPRO)/2) The best Ada translation, and one that is well within reach of a reasonably coded binding generator is LOWPRIO : constant := 10; HIGHPRIO : constant := 52; DEFPRIO : constant := (LOWPRIO + HIGHPRIO) / 2; but if you work from the preprocessed header file, you can't do that. What is needed is juggling the input and output of the preprocessor. The rules for importation of constants would be very delicate, in particular, understanding what would and would not be static would be a real mess. What you are really trying to reach for here is trying to define the semantics of a particular binding generator approach into the Ada standard. This would have been a very bad idea, since we just don't know enough yet to know how to do this. Standardizing things you do not understand is a mistake. People without experience in language design often draw, often with a big brush, a picture of a general facility that they would like to have, and it is obvious to them that it is needed. Unfortunately the phrase "The Devil is in the Details" might well have been invented for this field, and any attempt to develop Marcus' proposal in a general direction suitable for standardization would be bound to fail in my opinion. A given implementation could do a limited job, and indeed it would be an interesting (and not totally unreasonably difficult) project to try to put some capability like this into GNAT. This is not a direction that ACT sees as technically sound however. We think it makes FAR more sense to try to develop freely available binding tool generation technology. The currently available C2Ada is very limited, and it is here that we can really get something happening. For one thing, we see little future in a binding tool that can only handle C, it is clearly essential to be able to handle C++ and Java as well, and that is the starting point for our work in this area. Robert Dewar Ada Core Technologies (I added the formal signature because of the peek into our future plays in the last couple of paragraphs :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own