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

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

O.K., but three things.

1) With it being an enumeral, unless *ALL* implementations use the same 
ones, I have code that won't compile, right? Assuming Aonix doesn't have 
an enumeral like: SYSTEM_NAME_GNAT then I clearly can't write "if 
(SYSTEM_NAME_GNAT) then...". A character string would be more usable in 
this regard, but then you still need to have some useful set of 
character strings. This is probably the primary reason it isn't used - 
its totally useless for any sort of portability concern. The code works 
so long as its the Gnat compiler doing it, but it doesn't work (or even 
compile) for Aonix or something else, right? So I might just as well not 
have had the conditional statements in there in the first place because 
it didn't work to begin with and it didn't work just as nicely with the 
"if" statement wrapped around it. It would also be totally unreasonable 
to expect that all vendors would pick up all other vendor's enumeral 
sets to make sure it was portable at least at the compilation level.

2) No matter what I do, I can't use this in a *declaration*. Earlier 
versions of Gnat (for the PC - it wasn't supported on the Alpha and 
maybe not for others) would support a 96 bit float. Now that has become 
a 128 bit float. (My guess is that they both held an IEEE 80 bit float, 
but I never checked that far.) So I'd like some capability to say 
something like:

if (System.Name = "GNAT v12.something") then
    type X is new Float_96 ;
    for X'Size use 96 ;
elsif (System.Name = "GNAT v15.something") then
    type X is new Float_128 ;
    for X'Size use 128 ;
end if ;

This may be a trivial example that could probably be better done with 
something like System.Max_Digits, but that doesn't mean there are not 
more complicated and difficult cases that just plain can't be handled 
with the current setup.

3) Even in executable parts of the code, this doesn't get you around a 
problem where one compiler/target will support a given statement and 
another compiler/target will not. Suppose you had some compiler/target 
dependent package available to you - GNAT.Something. In a different 
compiler/target, you have a similar package - AONIX.SomethingElse. You'd 
like (at some low level of isolation) to build a skin over this by 
withing the appropriate package and making the appropriate call. 
Something like:

if (System.Name = "GNAT") then
     with GNAT.Something ;
elsif (System.Name = "AONIX") then
     with AONIX.SomethingElse ;
end if ;

package Isolation_Skin is
     procedure Do_The_Thing is
     begin
         if (System.Name = "GNAT") then
             GNAT.Something.Do_It_The_GNAT_Way ;
         elsif (System.Name = "AONIX") then
             AONIX.SomethingElse.Do_It_The_AONIX_Way ;
         end if ;
     end Do_The_Thing ;
end Isolation_Skin ;

Under the current system, I can't pull the "with" trick part, but the 
idea is that the statement: AONIX.SomethingElse.Do_It_The_AONIX_Way may 
not even be compilable in the Gnat environment. There are plenty of 
"implementation defined" or "implementation dependent" features of Ada - 
not to mention compiler bugs, etc., that would make sure that a given 
body of code might not compile for an implementation, so a simple "if" 
statement can't get you around it. It must be pre-processed in some 
manner to effectively comment out the branches that don't work.

Granted, you can create two package bodies and isolate it down at that 
point, but then you've got to configuration manage and build with two 
bodies. Ada has no "Standard" configuration management or build tools 
built in to handle this so you get no guarantee from the language that 
you could provide some kind of build script or whatever to do it. (Hence 
why developers tend to like some kind of conditional compilation. Its 
the only way you can *guarantee* that you have a mechanism of getting 
your code to work on two different platforms.)

BTW: I have no hesitation to dip into the package System when I've got 
to do something system dependent - referencing addresses, etc. For 
PC/Workstation apps, this isn't that often, but in the embedded world 
its absolutely critical. Naturally, you try to isolate these 
dependencies down at some low level so they don't intersperse all 
throughout the code and make porting a more difficult job, but there 
should be no reason to hesitate to use System when there is some system 
dependent feature you need. So at least in *my* individual little Ada 
culture, there is no phobia about it. :-)

MDC


Robert I. Eachus wrote:
> 
> Technically what we expected way back when was that users would write 
> code that depended on the value of System.System_Name, which was made an 
> Ada constant for just that reason.  (Compilers could evaluate "if 
> System.System_Name = VAX then..." at compile time to eliminate any 
> overhead.)
> 
> In practice, two things prevented that.  First, vendors didn't list all 
> supported systems in package System, usually just the one you were 
> compiling for. But more important was that the Ada culture quickly 
> became to avoid dependencies on System for any reason whatsoever.
> 
> Now, we are where we are:
> 
> -----------------------------------------------------------
> with Ada.Text_IO; use Ada.Text_IO;
> with System; use System;
> procedure System_Names is
>   package Name_IO is new Enumeration_IO(System.Name);
> begin
>   Put(" The Available System Names are: ");
>    for I in System.Name'Range loop
>      Name_IO.Put(I);
>      if I = System.Name'Last
>      then
>        Put_Line(".");
>      else
>        Put(", ");
>        if Col > 60 then New_Line; end if;
>      end if;
>    end loop;
>    New_Line;
>    Put(" Current System.System_Name is: ");
>    Name_IO.Put(System.System_Name);
>    Put_Line(".");
> end System_Names;
> -----------------------------------------------------------
> 
> E:\Ada\Test>system_names
> system_names
>  The Available System Names are: SYSTEM_NAME_GNAT.
> 
>  Current System.System_Name is: SYSTEM_NAME_GNAT.
> 
> Is there any compiler that produces a useful output?  Of course, with 
> GNAT at least I can modify system and recompile it.  But of course, the 
> usual is to do the easier thing, and have some other system dependent 
> package defined by the project will all the dependencies depending on 
> that.  But that forces projects to do the version control that should 
> come from the compiler switches.  (The code generator has to know enough 
> about the target to patch up System.  But for that to work the type 
> System.Name has to contain a useful set of names.)
> 
> Incidently this is the first program I have written in a while that had 
> a bug not caught by the compiler.  For some reason Are was capitalized 
> in one of the message strings. ;-)
> 


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

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