Re: Standard Ada Preprocessor

From: Marin David Condic (
Date: 01/29/04

Date: Thu, 29 Jan 2004 12:40:57 GMT

Well, let's sum it up this way: Its possible to have a given statement
that works in environment A but not in B. For B you need an alternate
statement. The decision has to be made at compile time because its the
compiler that rejects the statement, so you can't wait until runtime and
look at some configuration parameter to decide which statement to use.
That leaves you with these choices:

1) Have the two alternate lines in the same file & let the compiler
decide (based on some condition) which to actually read & interpret.

2) Build your own pre-processor because the compiler writers won't do
the job in a standard way for you - but this is really no different than
having the compiler decide. Its still indicating in the source code
which line to compile.

2) Have the two alternate lines in two alternate files and let the build
process decide which to actually send to the compiler. (Substitute the
word "line" for "file" and you see the problem is identical - just using
different mechanisms for which line to let the compiler try to interpret.)

You aren't fundamentally changing the problem - just where it will be
dealt with. If the argument against conditional compilation is that it
will make ugly, incomprehensible code, then that same argument goes
against the build process. It is, after all, some set of instructions
that will be obeyed by the computer and hence a kind of programming
language, so giving *it* the responsibility is just going to result in
ugly, incomprehensible code at the build level. Only it won't be
portable and you can't count on it being there and someone who doesn't
know what's going on with the different bodies of code is likely to
bugger it up. Not to mention the other related maintenance problems such
as not having all the code relating to one specific conceptual function
in one place - the "unnormalized database" situation described (I think)
by Warren.

So worrying about adding a feature that has the potential to be abused
is, in my mind, a non-starter. The feature *will* be added *somewhere*
so long as people have to manage code that must work in more than one
environment. One camp says "Your life will be so much better if only you
push that problem off to the build process level rather than the source
code level." Another camp says "I've been there and done that and I
think that at least some of the time, I'd rather deal with that problem
at the source code level".

The problem is inherently unpleasant no matter which way you go. But you
*will* have to deal with it and IMHO, *sometimes* I want to deal with it
at the source code level because it creates the fewest headaches for me.
The fact that someone might abuse it is also a non-starter. People can
abuse *anything* in a programming language. (Look at the religious wars
over using something like the predefined type "Integer" - some think its
handy and convenient and others think it is apostasy and should never be
used at all under any circumstances. Yet its in the language and Ada
programs are probably still better built on average than those in some
other languages. Life goes on in an imperfect world.)


Simon Wright wrote:
> I'm probably missing the point here, but as I recall the C side of
> things has a humungous incomprehensible heap of autoconf, m4, shell
> scripts, GNU make only, imake .. people are happy enough with that,
> where's the problem on the Ada side in selecting the right source file
> variant?
> I've just added support for arrays to my UML-to-Ada generator, under
> pressure. I _know_ I'm going to regret it, people are just bound to
> decide to (eg) implement their own associations using them rather than
> rely on the built-ins .. if you give people a bad feature they will
> use it badly. Of course the market rules here, shame really ..

Marin David Condic
I work for:
My project is:
Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r
     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."
         --  Al Bundy