Re: Standard Ada Preprocessor

[Marin David Condic <nobody@noplace.com>]

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.)

MDC



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: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

======================================================================