Re: Standard Ada Preprocessor

[Jacob Sparre Andersen <sparre@nbi.dk>]

Warren W. Gay VE3WWG wrote:
> Jacob Sparre Andersen wrote:
> > Warren W. Gay VE3WWG wrote:

> > But don't you agree that allowing a preprocessor to work on
> > package specifications isn't exactly good Ada style.
> 
> No argument. But I do have a problem to solve. The problem is ugly,
> and the solution might be ugly too ;-)

:-(

Do you have any examples, where you would have, or actually have, used
a preprocessor on package specifications?  (I hope I haven't missed
some in the discussion)

I probably make too simple systems, but I find it hard to imagine
cases, where it wouldn't be more appropriate to - at least - keep the
variant parts of the code away from package specifications.

> > Then you can't trust the package specifications anymore.  Although
> > I prefer a simple "choose an appropriate package body" method, I
> > can see some benefits of allowing full preprocessing of package
> > bodies.
> 
> You might be using a different meaning for "trust" than I use. As I
> see it, it need not be any different trust-wise than #included
> source code in a C program.  You know in advance that certain
> elements will be compiled certain way in certain environments. I can
> trust that to be the case no matter how many times that is called
> upon.

My problem is that if the package specifications vary with the target
environment, that means that all the code using that package also may
have to vary with the target environment, and thus propagate use of
conditional compilation. - I doubt that the ARG would let that into
the standard.

> > My main problem right now is: Is it possible to specify a sensible
> > common method for asking the compiler questions about the target
> > environment?  How?
> 
> That is the problem for Ada that has remained unsolved for (IMO) too
> long.

Haven't anybody tried to put a suggestion together?

> > My first thought was to tell the user (of the compiler) to give
> > the compiler some appropriate flags, indicating the information
> > needed for selecting which package bodies to choose.  But that
> > would still leave the problem of making those configuration
> > decisions to the user instead of automating them.
> 
> The problem that exists now is not generating the configuration.

I am not sure I agree.

> That can be done a multitude of ways, and is done in Open Sourced
> projects all over the place.

Yes, but the Open Source world has a de-facto standard for doing it.
We should either get those tools to support Ada as well as they
support C and C++ or make an easier and safer solution for Ada.

> The problem is taking it from configuration to source code. That is
> where the rubber hits the road right now. C/C++ deal with this just
> fine. Ada is challenged here.

I would say that that part is close to trivial - if we can agree to
which granularity to support.  At one extreme there is the current
situation with no formalised conditional compilation, somewhere in
between there is letting the compiler choose appropriate package
bodies given the configuration parameters, and at the other extreme we
have mandating something like the C preprocessor.

Personally I would like to have the solution of letting the compiler
choose appropriate package bodies.  But without some level of
automated detection of the target environment, it wouldn't be of much
use, and I could just as well handle it myself as I do today.

> It is not up to the compiler to know what configuration to use. But
> given directions about the configuration, the job is to generate a
> compiled version of that solution ;-)

I can understand your point of view, but if we really want to compete
with `./configure && make && su -c make install`, we have to do better
than that.

If users have to find out which versions of which libraries are on
their systems _and_ how to tell the compiler that information, we are
already _far_ behind what I can do myself with existing tools and
without much work.

> Again, Autoconf et al work fine for C/C++ systems. It requires real
> gyrations to use it with Ada ;-)

Sure?  I have never had to create an Autoconf/Automake configuration
from scratch, but I find it hard to imagine that it requires excessive
amounts of work to get it to do the testing needed to configure an Ada
program.

> The fact that a conditional compilation feature is made available,
> does not require it to be used.

Right.  But programmers have an awful habit of using whatever tools
available.

> So given the above, the real resistance is boils down to the
> argument "I don't want to ever see it".

If you are talking about full C preprocessor style conditional
compilation, you are certainly right.

If we are talking about some intermediated solution, where the public
part of package specifications are untouched by the conditional
compilation mechanism _and_ we can include some implementation advise
about the compiler guessing or asking the user the questions needed to
resolve the conditional compilation, then I will most likely support
it.

Jacob
-- 
"I don't want to gain immortality in my works.
 I want to gain it by not dying."