Re: Accessing C macro constants from Ada95

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <7ev36j$34t$1@pegasus.csx.cam.ac.uk>,
  mgk25@cl.cam.ac.uk (Markus Kuhn) wrote:
> In Robert Dewar <robert_dewar@my-dejanews.com> 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