Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)

["Warren W. Gay VE3WWG" <warren@ve3wwg.tk>]

Dmitry A. Kazakov wrote:
> On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic
> <nobody@noplace.com> wrote:
> 
>>That's why much as I might find some kind of preprocessing distasteful 
>>and certainly don't want to watch it degenerate into the unholy mess 
>>that you have with C, I think we need *some* mechanism for conditional 
>>compilation.
>>
>>Those who argue that it should all be isolated with different package 
>>bodies have to address the fact that a) this is often difficult or 
>>impossible
...
>>and b) it implies some kind of configuration management or 
>>build utilities that are totally outside the scope of the language and 
>>may not exist.
> 
> But the language defines the notion of a library. If we could extend
> it in a way allowing selection of a child units path during
> compilation, then I believe, it could be 80% of the issue.

Whether the problem is 50% or 20% is not the issue. The problem is
that even if I have a 2% problem, it is a _royal_pain_(TM). If you
have to support different implementation defined pragmas, if you have
to support optional record components (in bindings to OS services
or to different C libraries like readline), then whether the
problem is big or small, it is unsolved if it ain't 100% solved.

>>I'd like to be able to hand off a collection of source code and say 
>>"This is the main program - just compile it from there on your 
>>machine..." If it involves different bodies, I've got to provide you 
>>with detailed build instructions and can't assume you've got the same 
>>tools as I do. All that gets fixed automagically if I could put some 
>>conditional compilation statements into the code that indicate which way 
>>to go based on some kind of directive to the compiler. (I don't trust 
>>something in the package System to be sufficient - that at best can only 
>>tell you about the compiler, but not necessarily about the external 
>>platform and its potential variations.)
> 
> If we could limit variations to compilation units, I think we could,
> then there might be a better way than preprocessing.

As soon as you start splitting code into different parallel "files",
you are denormalizing and decentralizing your code. This is
maintenance hell.  If you find a bug in one of these "portability"
unique files, then you have to edit several files to effect the
same fix. It also much more difficult to view the impact to
other "platforms" for such a fix.

Don't get me wrong. I support the push for a better solution, but
I haven't seen any evidence of anything better than a conditional
compile. Whether conditional compilation comes about by preprocessing
or as part of the internal compile process, I don't care (compiler
writers will care however). But I think that the lack of portability
in Ada does hold it back for more general use.

> We could invent some sort of abstract packages [units], providing some
> interface (types, values, procedures) without any implementation. So
> types and constants could be declared incomplete there. Then a set of
> normal compilation units could provide various
> platform/condition-specific implementations of an abstract unit. Using
> such an unit in "with", "use" etc should select an implementation at
> compile-time from the set of visible concrete units. That would be
> some sort of polymorphic compilation units.

MDC also pointed to the need sometimes to do conditional "with" in
a compile. If I am using GNAT, I may need (or find it convenient)
to use a GNAT.* package. If I use another Ada compiler, I may want
to use some other vendor provided packages for similar functionality.
Of course, depending upon what you "with", will also conditionally
change what you want to compile.

So in the end, there is a strong need for "conditional compiles".
If we can agree on that, then let's leave preprocessing out of the
discussion and focus on "conditional compilation". How that is
achieved is an implementation issue.

Again, perhaps conditional compilation should also be optional
to placate those who will have no part in it ;-)
(perhaps enabled by compile option).
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk