Re: Standard Ada Preprocessor

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

Alexandre E. Kopilovitch wrote:
> Robert I. Eachus wrote:
>  
>>I think the right approach is to keep improving Ada for software 
>>engineers and let programmers use C++.
> 
> No, thanks. We programmers will use all the languages we see as good and
> possible for our current task and circumstances. Including Visual Basic, Java,
> Lisp, Smalltalk, assemblers etc., and including certainly Ada and C++.

Agreed. I was being a little flip in the comment.  My meaning was that 
programmers tend to ignore the software engineering issues raised by C++.

I expect software engineers to continue to use whichever language is 
most appropriate for the purpose.  I've probably now written more Ada 
than PL/I but it is close.  (Remember I helped develop an Ada compiler 
that ran on Multics, and then worked on Stratus VOS for a while.) C is 
probably now third instead of Fortran. Since I tend to be heavily into 
numeric/linear algebra code, I still write Fortran from time to 
time--but more C than Fortran.  I haven't written much Pascal in the 
last twenty years, but that could change.  Same for BASIC, although some 
people do use Visual BASIC for user interfaces, that is not the type of 
code I usually write. (I learned C++ and did some programming in it just 
for the experience.  In fact, I did the same thing with Prolog and a 
couple of other languages.)

I don't know if you consider SQL, XML, and HTML as a programming 
languages, but recently I have written a lot of all three.  And of 
course I have done my share of sh, csh, and Lisp programming.  I even 
programmed some numerics code in APL...

>> We are doomed to live in a world where most code is poorly designed.
> 
> Code is man-made, and man-made things of all kinds are mostly poorly designed.

That is usually referred to as Sturgeon's Law: "Sure, 90% of science 
fiction is crud. That's because 90% of everything is crud." ;-)

>> All we can do is try to keep an island of sanity,
> 
> Island can't be defended by itself. It was proven several times that even
> good air forces cannot defend their airbases by themselves, without sufficient
> support on the ground.
> 
> Certainly you know all that very well.

Of course.  Again my meaning was not that we should give up entirely, 
but that some fights were not worth fighting over and over again.  In 
fact, to restate my position:

1) There are good pre-processors available for Ada, for when you need to 
use a preprocessor with Ada.

2) There is no need for a STANDARD Ada pre-processor, because most of 
the need for that sort of thing in Ada is better done in Ada.  I'd 
rather spend my efforts in the standards area on making Ada a 99% 
solution instead of a 90% solution.

3) I have discovered lots of "tricks" that allow you to avoid using a 
pre-processor with Ada.  Here they are.  If you like, you can use them. 
  If you don't like, fine.

4) In particular, remembering that addresses in address clauses need not 
be static is a huge help.  In fact, I have sometimes put declarations 
with address clauses in inner scopes.  Then I made the addresses 
non-static according to Ada rules just so that the (unused) record 
declaration will compile with a different compiler.

Also use named numbers to make "portable" representation clauses 
tolerable. I always put the complex expressions in one package 
specification and write:

"for Some_Record_Type use
    Component_1 at Start_1 range First_Bit_1 .. Last_Bit_1;
    Component_2 at Start_2 range First_Bit_2 .. Last_Bit_2;
    Component_3 at Start_3 range First_Bit_3 .. Last_Bit_3;
    ..."

Wherever record rep clauses are needed. Of course, Start_n, First_Bit_n, 
and Last_Bit_n are named numbers (usually more descriptive) from that 
package.  That way the decision as to whether to have multiple versions 
of that one file, or use complicated (static) expressions to handle both 
little and big endian architectures can be made when I need to port the 
application to a new environment.  Having all of the numbers used in rep 
specs in one place is a big help however you manage them, so I do it 
even if I am never planning to port the code to a new compiler or OS.

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