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

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

Robert I. Eachus wrote:

> Marin David Condic wrote:
>> Most of what's in System seems to be useful only at run time. By then, 
>> I could have easily solved the problem for myself by having some kind 
>> of app-defined configuration file or similar thing I read in and use 
>> to determine which calls to make. So any solution has to happen at 
>> compile time or it really doesn't do any good.
> 
> My point was that we can fix System to some extent, since Strings can 
> now be static.  Of course there is NO universal solution because on some 
> systems some values will be static, and on others they won't be known 
> until run-time.  But if we "fix" System so that the compiler can 
> document such things, then users will be able to do what they can do.

I hate "no universal solution" fixes. I hate having to revist
things multiple times. I hate preprocessors too, but I hate
the other issues more.

> I certainly don't buy the "conditional compilation must happen at 
> compile time" argument.  It may be true in most embedded applications 
> that you can statically know these things at compile time.  But I also 
> deal with creating .dlls that must match the current hardware.  If that 
> means that I have to generate self-modifying code, so be it.  (In 
> practice I build and install the correct dispatch table when 
> initializing a .dll.)

DLLs only are part of _one_ vendor's solutions. Try dealing with
different POSIX-like environments from _many_ vendors. The solutions
get dirtier and quickly.

For example, you'd pretty much have to have a different package
for every POSIX-like environment, because of changes like what
was included in the stat(2) structure (and others). Worse, you'd
have to matrix it out to the various releases of Linux, FreeBSD,
NetBSD, OpenBSD, Solaris, IRIX, HPUX etc. You cannot hope to
accommodate all of these differences by package names. Throw
into the mix a different set of compilers, and different versions
of a readline library, and the solution is entirely doomed.

> But every once in a while I like to dream about the facility that Ada 
> environments were supposed to have had, where I could just say compile 
> this code for these dozen hardware specifications, and package the 
> result in one load module. ;-)
> 
> However, back to the world as it exists.  

The world as it is, does not need to remain entirely static ;-)

> The discipline of Ada is that 
> you should be able to push most, if not all, hardware dependencies first 
> into package and other unit bodies, and then into variant parts and if 
> statements.  

Ok, so we're getting back to the argument "Ada doesn't do it
this way". This works for limited embedded environments, but
I think you're hearing from others, that it still does not
do the job well enough in the modern Open Sourced world. If
Ada sticks to this model (the "embedded only"), then it is
then doomed to never achieve wider acceptance, IMO.

 > It is hard word to do that.  But IMHO it is much easier to
> maintain than you can ever save during development by not doing the work.

Matrix 10 POSIX environments x 10 versions of the same, x 4
different versions of a curses library. That leaves you with
400 different custom (possibly groups of) packages to work
with. Real slick indeed. :(

> So I don't believe in preprocessors for Ada code.  

Think "conditional compilation". I see the "how" as an
implementation detail, that need _not_ track the C/C++
experience.

> There are times that 
> I do get frustrated at the fact that I can put case statements in type 
> declarations and sequences of statements, but I can't wrap a single 
> declaration in one.  But usually after a short break, I come back and it 
> wasn't necessary after all.

I get frustrated with the short sightedness of the "not invented
here syndrome". But maybe, that is just me. ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk