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

["Robert I. Eachus" <rieachus@comcast.net>]

Robert I. Eachus wrote:

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

Warren W. Gay VE3WWG wrote:

> 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 think you misunderstood what I was saying here.  On some systems 
memory size is static.  This is common in embedded systems, the RAM may 
be part of the CPU chip.  In that case users would want the compiler to 
  use a static value for memory size.  But on a PC, if I stick another 
DIMM in and reboot, I want my (previously compiled) program to see the 
right memory size.  So a compiler targeting a PC should use a system 
call to get the memory size at run-time.  That was what I meant by "no 
universal solution."  We (the ARG) should give Implementation Advice 
about when the values in package System should be static and when they 
should use a system call.  But the choice should be left to the 
implementor, because he knows the characteristics of the actual target.


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

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush