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

[Marin David Condic <nobody@noplace.com>]

Yeah. Isolating them down at some low level is fine. But that still 
leaves you with the problem of "How do I code up the stuff at the low 
level?" You're either controlling it with some kind of build scripts & 
CM or you do it with something inside the language. Given that it needs 
to be done & I can't keep pushing it off with indirection forever, I'd 
like a language mechanism for doing it.

Maybe conditional compilation is not the answer. But then let's come up 
with something else. Sooner or later, I've got to have a way of 
maintaining code that works in one place but not in another and relying 
on external mechanisms is often difficult or impossible. (Handing source 
code off to unknown destinations is a good example - you may not know 
who or what is at the other end and may not be able to trust that they 
have mechanisms or competence to manage multiple builds. Source code I 
can trust because I can verify that it works as intended. Mechanisms 
outside that are uncertain.)

MDC


Robert I. Eachus wrote:
> 
> Now I see why you worry about about illegal code and I don't.  As far as 
> I am concerned, ANYTHING I can do to minimize differences between 
> versions is worth the effort.  That certainly includes building 
> wrappers.  So in the Ada 83 days when different compilers had different 
> names for the trancendental math packages, I had MY standard.  (Usually 
> kept updated based on the latest NUMWG work, but that is a detail.) 
> Similarly, I had my package that did command line arguments, with 
> different bodies for Alsys and Verdix, etc.  So I kept a collection of 
> 'standard' packages needed for portability.  If I needed to deal with 
> say, a bug in Solaris, I did it there.
> 
> The net result was one directory of implementation dependent packages, 
> with multiple implementations, and applications that were completely 
> implementation independent.  I kept the package specifications for the 
> implementation dependent stuff identical, if necessary by making the 
> bindings thicker than might otherwise be needed.  The only case where I 
> can ever remember a problem, Rational called me about one of my ADAR 
> packages that didn't compile due to an Unchecked_Conversion.
> 
> Rational didn't allow Unchecked_Conversions of access types.  In 
> addition to telling them a work around, I suggested that they treat this 
> case as as a compiler bug.  It involved an Unchecked_Conversion of an 
> object of an access type to the same access type. (Why did I do it?  It 
> allowed me to put a with clause on a body instead of on the package 
> specification.)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================