Re: Standard Ada Preprocessor

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

Randy Brukardt wrote:

> Updating the Ada standard is as much a political process as it is a
> technical one. In this case, I and others tried to get a solution added to
> Ada 95. There was too much opposition at that time. Given that nothing has
> changed, I'd expect the same result if the same solutions are presented.
> Indeed, we have a meta-rule that we won't even waste time on issues decided
> during Ada 95's development unless there is significant new information.
> (The few that have come up, like 'in out' for functions, have ended up with
> precisely the same results as the last time - even with new information.)
> 
> The only new information that I could think of that would help here would be
> an elegant solution. Certainly, the fact that the problem exists - or its
> scope - haven't changed a bit in the last 12 years. I'm going to spend my
> time on issues that have a chance to be approved (like a limited containers
> library), not tilting at windmills. (I've done enough of that in the last
> couple of years.)
> 
> Otherwise, you'll get have to use a non-standard solution like Gnatprep.

What Randy says is 100% correct.  There is a lot of work invovled in 
updating a language standard, and this time around there is no full-time 
team working on Ada 0Y, so things that didn't make the cut in Ada 9X are 
even less likely to get in this time.

However, having said that, I will continue to work on making it easier 
to use Ada in place of a pre-processor language.  The main requirements 
for that, as they have been all along, are major goals of the Ada 
community.  As long as there is "only one Ada," and Ada compilers do 
static code elimination, then it is possible to use Ada if and case 
statements for conditional code.

Yes, I know that there are some things you can't do this way.  But I 
haven't found them to be a big deal.  For example, if I have numeric 
code that uses 32 and 36-bit integers depending on target, I know how to 
define a portable integer type that doesn't require creating a 36-bit 
integer type on hardware that doesn't support it.

Floating-point is a bit harder, but there what really changes is whether 
there is a type with more precision than IEEE double, and what it is 
called. That IS a case where I do have multiple bodies, but since the 
code for machines that support IEEE extended and those that don't is 
totally different, I don't mind mantaining separate bodies.

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