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

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Preben Randhol wrote:
>> Well, who would be in charge of an Ada GUI and develop it actively and
>> not every 10-15 years ?
...
> Ada has this "Portability Fetish" that often cripples it. "If we can't 
> make a feature work on everything from a PC to a digital toaster then it 
> can't be part of the language!" We solve that with some kind of library 
> external to the standard that exists in source and works on some stated 
> number of platforms and where it doesn't work - don't try to use it. The 
> problem, of course, is to get the vendors to actually think that Ada 
> *needs* something like this and exhibit the will & leadership to get it.
...
> MDC

Portability of course is an important issue. This becomes even more
important to Open Sourced projects, since they must be easy to
compile and maintain for all/most flavours of UNIX, and different
Windows environments (native and/or CYGWIN etc.)

(I'll probably take some heat for this but..)

In my opinion, the preprocessing of C code has made C the clear
winner (and now C++) for portability. Examples of code that
compiles and runs on the ancient Atari, BeOS, UNIX and Windows
etc are not hard to find. Unless the Ada code is pretty
much disconnected from the operating system, you won't find
the same level of portability.

Granted preprocessing results in ugly code. But it is
pretty clear that developers prefer to maintain one
source module, rather than trying to keep 10+ parallel modules
synchronized (for each supported platform).
It is certainly my preference to centralize maintenance.
Any time you can centralize the control of something,
maintenance becomes cleaner, and is forced
to be consistent (much like database normalization).

gnatprep obviously helps to address this issue for the "gnat
world". But IMHO Ada could be well served if there was a standard
for an Ada preprocessors.  Its use of course would be optional
(for the purests and those situations where it is not needed),
but a standard would make Ada code more easily portable.

Failing that, everyone must bake their own solution to this
problem. Many maintain that by centralizing problem code into
separate libraries works well enough. But this does not help
in the cases where a product can be compiled with different
options turned on or not (say from a Makefile). In other cases,
it may mean enhancements involve maintenance of several parallel
modules, instead of one centralized location.

I havn't checked to see if any current discussions are
taking place about the possibility of standardizing a
preprocessor. But if were to guess, it has been discussed
and summarily dismissed on religious grounds ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Marin David Condic]

While I find preprocessors distasteful and can see how they can become 
an unholy mess (look at some of that "Portable C" code to which you 
refer! :-) I'm afraid I'd have to agree to some extent.

Ada ought to have some sort of answer for how to deal with maintaining a 
single body of code that has to compile for more than one environment. 
Even if you have the same target hardware and two different compilers 
(even from the same manufacturer sometimes!) you can have statements 
that will compile on one but not on the other. Isolation with separate 
bodies is sometimes difficult to do and always complicates the build 
process. Some form of conditional compilation would make the job easier.

Naturally that has risks and can lead to all sorts of abuse. I'm not 
sure there is a good answer, but Ada ought to try to address it somehow. 
Eventually, developers need some scheme for how to deal with 
implementation differences and platform differences. To the extent that 
it can be handled via isolation in "standard" & "portable" interfaces, 
this is a good thing. But we've seen reluctance to do so for a variety 
of reasons, not the least of which is the time & expense to get those 
interfaces specified & implemented by the vendors. Even then, you'll 
have differences that can't be cleanly dealt with that still give full 
access to the underlying features of an OS or implementation.

I'm not smart enough to figure out if there is a better answer than 
conditional compilation, so I'd have to agree that some sort of standard 
method of getting conditional compilation or preprocessing would be a 
good thing.

MDC


Warren W. Gay VE3WWG wrote:
> 
> (I'll probably take some heat for this but..)
> 
> In my opinion, the preprocessing of C code has made C the clear
> winner (and now C++) for portability. Examples of code that
> compiles and runs on the ancient Atari, BeOS, UNIX and Windows
> etc are not hard to find. Unless the Ada code is pretty
> much disconnected from the operating system, you won't find
> the same level of portability.
> 
> Granted preprocessing results in ugly code. But it is
> pretty clear that developers prefer to maintain one
> source module, rather than trying to keep 10+ parallel modules
> synchronized (for each supported platform).
> It is certainly my preference to centralize maintenance.
> Any time you can centralize the control of something,
> maintenance becomes cleaner, and is forced
> to be consistent (much like database normalization).
> 
> gnatprep obviously helps to address this issue for the "gnat
> world". But IMHO Ada could be well served if there was a standard
> for an Ada preprocessors.  Its use of course would be optional
> (for the purests and those situations where it is not needed),
> but a standard would make Ada code more easily portable.
> 
> Failing that, everyone must bake their own solution to this
> problem. Many maintain that by centralizing problem code into
> separate libraries works well enough. But this does not help
> in the cases where a product can be compiled with different
> options turned on or not (say from a Makefile). In other cases,
> it may mean enhancements involve maintenance of several parallel
> modules, instead of one centralized location.
> 
> I havn't checked to see if any current discussions are
> taking place about the possibility of standardizing a
> preprocessor. But if were to guess, it has been discussed
> and summarily dismissed on religious grounds ;-)
> 


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

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

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

[Robert I. Eachus]

Marin David Condic wrote:

> Ada ought to have some sort of answer for how to deal with maintaining a 
> single body of code that has to compile for more than one environment. 
> Even if you have the same target hardware and two different compilers 
> (even from the same manufacturer sometimes!) you can have statements 
> that will compile on one but not on the other. Isolation with separate 
> bodies is sometimes difficult to do and always complicates the build 
> process. Some form of conditional compilation would make the job easier.

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

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

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

[Randy Brukardt]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:LNOdncWFbKUojpLdRVn-uQ@comcast.com...
> 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?

Dunno. We used to have additional names in that enumeration, but I believe
we removed the capability because of the ACVC. In Ada 83, you were supposed
to be able to set the value of the System_Name (via a pragma, I believe) to
any of the allowed choices. The best way to "avoid" that test was to have
only one name in the enumeration. Then, the test couldn't do anything
useful.

Although that capability is long gone, I suppose implementers are sticking
with the way it was back then.

Besides, having all of your supported targets in the enumeration is a real
maintenance headache. If you add or drop support for a target, you have to
go modify System in all of the targets. Yuck.

                 Randy.

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

[Marin David Condic]

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

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

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

[Marin David Condic]

And that only expands geometrically if you try to support enumerals for 
other vendor's implementations in order to be able to accept code built 
for their compilers.

How about *adding* something to system like:

     System.Compiler_ID : constant String := "Something Useful Here" ;

This would not break anything that was already using System_Name 
(although given its general uselessness, I doubt that is very much) and 
would provide a mechanism for identifying the compiler that is doing the 
job. Then statements like "if (Compiler_ID = "Something") then..." would 
possibly be useful.

You still need some mechanism to wrap that around declarations and other 
stuff. Perhaps that could be solved with some flavor of a pragma that 
could take a case-like if statement around what you want conditionally 
compiled. Maybe the whole thing should be solved with a pragma since you 
don't want to have to first "with" System before you can start 
conditionally withing other packages. That also gets simpler to deal 
with from a language perspective since there has always been the ability 
to have implementation defined pragmas.

MDC


Randy Brukardt wrote:
> 
> Besides, having all of your supported targets in the enumeration is a real
> maintenance headache. If you add or drop support for a target, you have to
> go modify System in all of the targets. Yuck.
> 
>                  Randy.
> 
> 
> 


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

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

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

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]


"Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com...
> 1) With it being an enumeral, unless *ALL* implementations use the same
> ones, I have code that won't compile, right?
Wrong. If you prefer it as string, you can always write:
   If Name'Image (System_Name) = "Whatever" then ....

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

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

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert I. Eachus" <rieachus@comcast.net> wrote in message
> news:LNOdncWFbKUojpLdRVn-uQ@comcast.com...
> > 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?
> 
> Dunno. We used to have additional names in that enumeration, but I believe
> we removed the capability because of the ACVC. In Ada 83, you were supposed
> to be able to set the value of the System_Name (via a pragma, I believe) to
> any of the allowed choices. The best way to "avoid" that test was to have
> only one name in the enumeration. Then, the test couldn't do anything
> useful.

There was also a pragma to change the size of a storage unit.
Very strange.  Compilers are not generally capable of redesigning
the target hardware in the fly!

Anyway, it seems to me that the whole idea of System.System_Name could
never work, unless there were some world-wide registry of names.
Much easier to let individual projects roll their own -- they know
what systems they (currently) support, and they know whether they care
about the target hardware, or the target OS, or the Ada compiler,
or whatever.

- Bob

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> And that only expands geometrically if you try to support enumerals for 
> other vendor's implementations in order to be able to accept code built 
> for their compilers.
> 
> How about *adding* something to system like:
> 
>     System.Compiler_ID : constant String := "Something Useful Here" ;
> 
...
> You still need some mechanism to wrap that around declarations and other 
> stuff. Perhaps that could be solved with some flavor of a pragma that 
> could take a case-like if statement around what you want conditionally 
> compiled. Maybe the whole thing should be solved with a pragma since you 
> don't want to have to first "with" System before you can start 
> conditionally withing other packages. That also gets simpler to deal 
> with from a language perspective since there has always been the ability 
> to have implementation defined pragmas.
> 
> MDC
...

Not only do you have system(s) to worry about, you have version(s)
of system(s), you have optionally installed component(s) and choice(s)
in compiler(s) as well. If you are writing source code to accomodate
these different variables, you have quite a source code issue on your
hand. Here are a couple of examples:

  - Are you using:
    - GNU curses library?
    - the real UNIX curses library (or non BSD variant)?
    - are you using PDcurses library?

  - Does the user have (and want to use) the readline library?

These are just two cases, which require you to configure your code.
Blocks of code are unnecessary if no readline support exists. Whether
you are using PDcurses, UNIX curses or GNU curses requires you to
work around bugs and shortcomings in different ways.

I havn't re-checked, but IIRC, Florist ends up generating a large
portion of specs, and I suspect that bodies are probably "processed"
as well. Any bindings related code, gets very quickly into the need
for conditional compilation. Part of the Florist need for generated
specs is due to the constants that must be ferreted out of C header
files. But the other reason to #if is related to whether a particular
API is even present on the platform of choice, and whether or not
certain structures (records) are required.

In bindings, you often run into optional structural components as well.
The system call stat(2) for example uses a structure. But the members
of that structure changes, depending upon the POSIX platform chosen. The
only way to avoid this is to dumb it down so much that all platforms
provide the same thing. But this doesn't work well with stat, because
you'd have to dumb it down a lot, to achieve full portability - causing
needed functionality to be lost.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Robert A Duff wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>"Robert I. Eachus" <rieachus@comcast.net> wrote in message
>>news:LNOdncWFbKUojpLdRVn-uQ@comcast.com...
>>
>>>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?
>>
>>Dunno. We used to have additional names in that enumeration, but I believe
>>we removed the capability because of the ACVC. In Ada 83, you were supposed
>>to be able to set the value of the System_Name (via a pragma, I believe) to
>>any of the allowed choices. The best way to "avoid" that test was to have
>>only one name in the enumeration. Then, the test couldn't do anything
>>useful.
> 
> There was also a pragma to change the size of a storage unit.
> Very strange.  Compilers are not generally capable of redesigning
> the target hardware in the fly!
...

Non-standard pragmas (implementation defined) are another reason
why conditional compilation (or preprocessing) is required.
Sometimes it is necessary to use the non-standard pragmas,
especially when doing bindings.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> O.K., but three things.
> 
...
> 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 ;
...

Another very good point!

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Robert A Duff]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com...
> > 1) With it being an enumeral, unless *ALL* implementations use the same
> > ones, I have code that won't compile, right?
> Wrong. If you prefer it as string, you can always write:
>    If Name'Image (System_Name) = "Whatever" then ....

... which is always False, even when System_Name = Whatever.  ;-)

- Bob

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

[Robert I. Eachus]

Marin David Condic wrote:

> How about *adding* something to system like:
> 
>     System.Compiler_ID : constant String := "Something Useful Here" ;
> 
> This would not break anything that was already using System_Name 
> (although given its general uselessness, I doubt that is very much) and 
> would provide a mechanism for identifying the compiler that is doing the 
> job. Then statements like "if (Compiler_ID = "Something") then..." would 
> possibly be useful.

In Ada 83 that wouldn't have worked.  But I think it would be wonderful 
to get rid of the type Name in system and add three string constants:

Operating_System:      constant String := implementation_dependent;
Hardware_Architecture: constant String := implementation_dependent;
Compiler:              constant String := implementation_dependent;
Version:               constant String := implementation_dependent;

If I were going to write this up as an AI, I would include as 
"Implementation Advice" that the strings be static, that configuration 
pragmas be allowed to affect the values, and that the version strings 
for a particular compiler should sort as strings into cronological order.

Oh, and redefine System_Name to return a String, but not necessarily a 
static String.  It should give the name of the machine the program is 
running on.  (The machine I am typing this on is Milliways.) Memory_Size 
should be redefined as a function that returns the system memory size, 
and there should be a functions Stack_Size and Heap_Size that return the 
actual maximum permitted Stack_Size (either for the main program or for 
the task where it is called), any the size of the default heap.  (The 
more I think about it, the type they return is not a stumbling block. 
That should be an implementation defined integer or modular type. Any 
program that needs to use the type will either use numberic literals or 
do a type conversion.)

Anyone interested enough to propose this as a (late) addition to Ada0Y? 
  Since Jean Ichbiah interchanged Name and System_Name at the very last 
moment in Ada 83, there certainly is a precedent for changing System 
late in the game. As far as I know that was the only significant change 
between the printers proof and the published ANSI standard.  (Page 
number 2-2 certainly wasn't significant. ;-)

> You still need some mechanism to wrap that around declarations and other 
> stuff. Perhaps that could be solved with some flavor of a pragma that 
> could take a case-like if statement around what you want conditionally 
> compiled. Maybe the whole thing should be solved with a pragma since you 
> don't want to have to first "with" System before you can start 
> conditionally withing other packages. That also gets simpler to deal 
> with from a language perspective since there has always been the ability 
> to have implementation defined pragmas.

My current approach to this problem is to have packages OS, and ISA. 
Then in whatever library I am working these do the necesssary via 
package renames.  I've thought about using a preprocessor, but so far 
the renames work and look much neater, as far as the source code is 
concerned.  What I would really, really like is for the compiler to 
expand those names based on compile time flags and defaults.  I don't 
think that trick should be a language defined/required behavior, but I 
don't see any reason why a compiler couldn't validate even if it 
included such a feature.


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

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

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]


"Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message de news:wccd69bx2td.fsf@shell01.TheWorld.com...
> "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
>
> > "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com...
> > > 1) With it being an enumeral, unless *ALL* implementations use the same
> > > ones, I have code that won't compile, right?
> > Wrong. If you prefer it as string, you can always write:
> >    If Name'Image (System_Name) = "Whatever" then ....
>
> ... which is always False, even when System_Name = Whatever.  ;-)
>
Of course, should be "WHATEVER"....
Sigh, even in this case, everything posted should be tried on a compiler :-)

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

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

[Marin David Condic]

That's why much as I might find some kind of preprocessing distasteful 
and certainly don't want to watch it degenerate into the unholy mess 
that you have with C, I think we need *some* mechanism for conditional 
compilation.

Those who argue that it should all be isolated with different package 
bodies have to address the fact that a) this is often difficult or 
impossible and b) it implies some kind of configuration management or 
build utilities that are totally outside the scope of the language and 
may not exist.

I'd like to be able to hand off a collection of source code and say 
"This is the main program - just compile it from there on your 
machine..." If it involves different bodies, I've got to provide you 
with detailed build instructions and can't assume you've got the same 
tools as I do. All that gets fixed automagically if I could put some 
conditional compilation statements into the code that indicate which way 
to go based on some kind of directive to the compiler. (I don't trust 
something in the package System to be sufficient - that at best can only 
tell you about the compiler, but not necessarily about the external 
platform and its potential variations.)

MDC

Warren W. Gay VE3WWG wrote:
> 
> Not only do you have system(s) to worry about, you have version(s)
> of system(s), you have optionally installed component(s) and choice(s)
> in compiler(s) as well. If you are writing source code to accomodate
> these different variables, you have quite a source code issue on your
> hand. Here are a couple of examples:
> 

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

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

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

[Marin David Condic]

The more I think about it the more I want there to be a conditional 
compilation capability that would allow some unlimited set of logical 
names to be associated with strings at compile time. What you propose 
would be helpful but A) still only helps where you can put an "if" 
statement and is useless around declarations and b) doesn't account for 
all the possible variants that may impact a program at compile time or 
run time. "Operating_System", for example, is insufficient to tell you 
if you have certain libraries available to you or not. Unless you force 
some structure on the string that allows it to be parsed to provide more 
detailed information.

I think we either need a single logical compile-time variable with a 
structured string that can be parsed (some format like "Attrribute => 
Value, ....") or you need an arbitrary set of compile time variables 
that the developer can establish and document as required settings for 
conditional compilation.

Most of what's in System seems to be useful only at run time. By then, I 
could have easily solved the problem for myself by having some kind of 
app-defined configuration file or similar thing I read in and use to 
determine which calls to make. So any solution has to happen at compile 
time or it really doesn't do any good.

MDC


Robert I. Eachus wrote:
> 
> In Ada 83 that wouldn't have worked.  But I think it would be wonderful 
> to get rid of the type Name in system and add three string constants:
> 
> Operating_System:      constant String := implementation_dependent;
> Hardware_Architecture: constant String := implementation_dependent;
> Compiler:              constant String := implementation_dependent;
> Version:               constant String := implementation_dependent;
> 

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

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

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

[Marin David Condic]

O.K. But we always had that capability. Right now I could write a 
package and call it "Configuration" (or whatever) and house in it a 
bunch of different strings that tell me what is or is not available in a 
particular compiler/target/version/etc arrangement. But unless you can 
actually *do* something with that info, having it available is totally 
useless. By the time I'm running and can read it and branch around some 
piece of code - its too late. I need it to solve issues at compile time 
- where a given compiler can't even see a given statement or it will choke.

Perhaps a pragma that took some constant string and compared it to a 
string literal and compiled the associated code only if equal would be 
sufficient. I could build my "package Configuration" and have something like

pragma If_Equal (Configuration.OS => "TOPS 10",
<some collection of Ada code - declarative or executable>) ;

It would be a cheap fix that minimizes the impact to any existing 
packages or code and only requires compile-time interpretation of a 
pragma - something compilers already do.

MDC


Robert A Duff wrote:
> 
> Anyway, it seems to me that the whole idea of System.System_Name could
> never work, unless there were some world-wide registry of names.
> Much easier to let individual projects roll their own -- they know
> what systems they (currently) support, and they know whether they care
> about the target hardware, or the target OS, or the Ada compiler,
> or whatever.
> 
> - Bob


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

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

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

[Marin David Condic]

But the language already says that if an implementation doesn't 
recognize a pragma, that it should be ignored. So you already have some 
limited conditional compilation. Its not a big stretch to imagine from 
there some pragma that lets you include or exclude statements depending 
on some compile-time condition.

MDC


Warren W. Gay VE3WWG wrote:
> 
> Non-standard pragmas (implementation defined) are another reason
> why conditional compilation (or preprocessing) is required.
> Sometimes it is necessary to use the non-standard pragmas,
> especially when doing bindings.


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

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

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

[Marin David Condic]

O.K. So there's a trick to get around it. (Do we call this "The Other 
Rosen Trick"? :-) Is Name'Image guaranteed to be in a given character 
case? (I've not checked that recently & must have forgot.)

That may eliminate one possible problem, but it really doesn't help make 
this feature useful. It still only helps at run time and I could have 
done that with a package of my own. If it doesn't let you branch around 
things that won't compile for a given configuration, then it really is 
mostly useless.

MDC


Jean-Pierre Rosen wrote:
> "Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:400FC65B.2020006@noplace.com...
> 
>>1) With it being an enumeral, unless *ALL* implementations use the same
>>ones, I have code that won't compile, right?
> 
> Wrong. If you prefer it as string, you can always write:
>    If Name'Image (System_Name) = "Whatever" then ....
> 


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

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

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

[Dmitry A. Kazakov]

On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic
<nobody@noplace.com> wrote:

>That's why much as I might find some kind of preprocessing distasteful 
>and certainly don't want to watch it degenerate into the unholy mess 
>that you have with C, I think we need *some* mechanism for conditional 
>compilation.
>
>Those who argue that it should all be isolated with different package 
>bodies have to address the fact that a) this is often difficult or 
>impossible

... different bodies which are not necessarily packages. If smaller
units required there are subroutines for that.

> and b) it implies some kind of configuration management or 
>build utilities that are totally outside the scope of the language and 
>may not exist.

But the language defines the notion of a library. If we could extend
it in a way allowing selection of a child units path during
compilation, then I believe, it could be 80% of the issue.

>I'd like to be able to hand off a collection of source code and say 
>"This is the main program - just compile it from there on your 
>machine..." If it involves different bodies, I've got to provide you 
>with detailed build instructions and can't assume you've got the same 
>tools as I do. All that gets fixed automagically if I could put some 
>conditional compilation statements into the code that indicate which way 
>to go based on some kind of directive to the compiler. (I don't trust 
>something in the package System to be sufficient - that at best can only 
>tell you about the compiler, but not necessarily about the external 
>platform and its potential variations.)

If we could limit variations to compilation units, I think we could,
then there might be a better way than preprocessing.

We could invent some sort of abstract packages [units], providing some
interface (types, values, procedures) without any implementation. So
types and constants could be declared incomplete there. Then a set of
normal compilation units could provide various
platform/condition-specific implementations of an abstract unit. Using
such an unit in "with", "use" etc should select an implementation at
compile-time from the set of visible concrete units. That would be
some sort of polymorphic compilation units.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

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

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]


"Marin David Condic" <nobody@noplace.com> a �crit dans le message de news:40111AC2.7010802@noplace.com...
> O.K. So there's a trick to get around it. (Do we call this "The Other
> Rosen Trick"? :-) Is Name'Image guaranteed to be in a given character
> case? (I've not checked that recently & must have forgot.)
Yes, it is guaranteed upper case (that's why my example is actually wrong!)

> That may eliminate one possible problem, but it really doesn't help make
> this feature useful. It still only helps at run time and I could have
> done that with a package of my own. If it doesn't let you branch around
> things that won't compile for a given configuration, then it really is
> mostly useless.
Sure. I was only addressing your claim that it would be better to have System_Name as a string.
In a sense, you already have it. The rest of the discussion is a different issue.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

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

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> ... I think it would be wonderful 
> to get rid of the type Name in system and add three string constants:
>
> Operating_System:      constant String := implementation_dependent;
> Hardware_Architecture: constant String := implementation_dependent;
> Compiler:              constant String := implementation_dependent;
> Version:               constant String := implementation_dependent;

I think that Compiler string constant (followed by its Version) should be
placed first in this sequence to underline the understanding that it is
the main key and that the meaning of all other items here (that is,
Operating_System and Hardware_Architecture) is relative to the Compiler.

Also, it may be useful to duplicate the pair
 {Operating_System, Hardware_Architecture}
- to cover the case of cross-compilation, that is:

 Compiler:                     constant String := implementation_dependent;
 Version:                      constant String := implementation_dependent;
 Host_Operating_System:        constant String := implementation_dependent;
 Host_Hardware_Architecture:   constant String := implementation_dependent;
 Target_Operating_System:      constant String := implementation_dependent;
 Target_Hardware_Architecture: constant String := implementation_dependent;





Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

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

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic
> <nobody@noplace.com> wrote:
> 
>>That's why much as I might find some kind of preprocessing distasteful 
>>and certainly don't want to watch it degenerate into the unholy mess 
>>that you have with C, I think we need *some* mechanism for conditional 
>>compilation.
>>
>>Those who argue that it should all be isolated with different package 
>>bodies have to address the fact that a) this is often difficult or 
>>impossible
...
>>and b) it implies some kind of configuration management or 
>>build utilities that are totally outside the scope of the language and 
>>may not exist.
> 
> But the language defines the notion of a library. If we could extend
> it in a way allowing selection of a child units path during
> compilation, then I believe, it could be 80% of the issue.

Whether the problem is 50% or 20% is not the issue. The problem is
that even if I have a 2% problem, it is a _royal_pain_(TM). If you
have to support different implementation defined pragmas, if you have
to support optional record components (in bindings to OS services
or to different C libraries like readline), then whether the
problem is big or small, it is unsolved if it ain't 100% solved.

>>I'd like to be able to hand off a collection of source code and say 
>>"This is the main program - just compile it from there on your 
>>machine..." If it involves different bodies, I've got to provide you 
>>with detailed build instructions and can't assume you've got the same 
>>tools as I do. All that gets fixed automagically if I could put some 
>>conditional compilation statements into the code that indicate which way 
>>to go based on some kind of directive to the compiler. (I don't trust 
>>something in the package System to be sufficient - that at best can only 
>>tell you about the compiler, but not necessarily about the external 
>>platform and its potential variations.)
> 
> If we could limit variations to compilation units, I think we could,
> then there might be a better way than preprocessing.

As soon as you start splitting code into different parallel "files",
you are denormalizing and decentralizing your code. This is
maintenance hell.  If you find a bug in one of these "portability"
unique files, then you have to edit several files to effect the
same fix. It also much more difficult to view the impact to
other "platforms" for such a fix.

Don't get me wrong. I support the push for a better solution, but
I haven't seen any evidence of anything better than a conditional
compile. Whether conditional compilation comes about by preprocessing
or as part of the internal compile process, I don't care (compiler
writers will care however). But I think that the lack of portability
in Ada does hold it back for more general use.

> We could invent some sort of abstract packages [units], providing some
> interface (types, values, procedures) without any implementation. So
> types and constants could be declared incomplete there. Then a set of
> normal compilation units could provide various
> platform/condition-specific implementations of an abstract unit. Using
> such an unit in "with", "use" etc should select an implementation at
> compile-time from the set of visible concrete units. That would be
> some sort of polymorphic compilation units.

MDC also pointed to the need sometimes to do conditional "with" in
a compile. If I am using GNAT, I may need (or find it convenient)
to use a GNAT.* package. If I use another Ada compiler, I may want
to use some other vendor provided packages for similar functionality.
Of course, depending upon what you "with", will also conditionally
change what you want to compile.

So in the end, there is a strong need for "conditional compiles".
If we can agree on that, then let's leave preprocessing out of the
discussion and focus on "conditional compilation". How that is
achieved is an implementation issue.

Again, perhaps conditional compilation should also be optional
to placate those who will have no part in it ;-)
(perhaps enabled by compile option).
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Marin David Condic wrote:
> 
>> How about *adding* something to system like:
>>
>>     System.Compiler_ID : constant String := "Something Useful Here" ;
>>
>> This would not break anything that was already using System_Name 
>> (although given its general uselessness, I doubt that is very much) 
>> and would provide a mechanism for identifying the compiler that is 
>> doing the job. Then statements like "if (Compiler_ID = "Something") 
>> then..." would possibly be useful.
> 
> In Ada 83 that wouldn't have worked.  But I think it would be wonderful 
> to get rid of the type Name in system and add three string constants:
> 
> Operating_System:      constant String := implementation_dependent;
> Hardware_Architecture: constant String := implementation_dependent;
> Compiler:              constant String := implementation_dependent;
> Version:               constant String := implementation_dependent;

This is still a very limited solution to the problems where
conditional compilation is needed. MDC pointed out a good
example where conditional "with" is desirable (and of course
this affects coresponding code).  These items only deal with
system and compiler level issues.

How do you solve the issues involved with different curses
libraries?

  - UNIX/*BSD curses library?
  - GNU/Linux curses library?
  - PDcurses?

If you're writing a curses binding, you not only need to know
which of these you're binding to, you need some serious
interface changes within your Ada code to be successful
(changes to API calls, conventions etc.)  Some of the pragmas
you will use, will also be conditional upon what platform
and "library" you're interfacing with.

Even where interfaces are identical, you often have to work
around bugs or implementation limitations. The current
"Ada compile process" does not solve this issue.

So I would suggest that the lack of "conditional compilation"
capability in Ada holds it back from general use. If you don't
want preprocessing, then fine. Engineer a "conditional
compile" capability, and leave the "how" as an implementation
detail.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> But the language already says that if an implementation doesn't 
> recognize a pragma, that it should be ignored. So you already have some 
> limited conditional compilation. Its not a big stretch to imagine from 
> there some pragma that lets you include or exclude statements depending 
> on some compile-time condition.
> 
> MDC
> 
> Warren W. Gay VE3WWG wrote:
> 
>> Non-standard pragmas (implementation defined) are another reason
>> why conditional compilation (or preprocessing) is required.
>> Sometimes it is necessary to use the non-standard pragmas,
>> especially when doing bindings.

That is fine, when the compiler doesn't recognize the pragma. But
what happens if two compilers both recognize an implementation
pragma, but have different requirements? Different parameters
for example?

Or how about different consequences?  Maybe it only applies
in one case, but not the other?
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:
> 
> As soon as you start splitting code into different parallel "files",
> you are denormalizing and decentralizing your code. This is
> maintenance hell.  If you find a bug in one of these "portability"
> unique files, then you have to edit several files to effect the
> same fix. It also much more difficult to view the impact to
> other "platforms" for such a fix.

C with preprocessor directives is also Maintenance Hell. I don't see 
that it's a better Hell.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

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

[Jeffrey Carter]

Robert I. Eachus wrote:

>... I think it would be wonderful 
>to get rid of the type Name in system and add three string constants:
>
>Operating_System:      constant String := implementation_dependent;
>Hardware_Architecture: constant String := implementation_dependent;
>Compiler:              constant String := implementation_dependent;
>Version:               constant String := implementation_dependent;

FOUR string constants ... chief among our string constants ... I'll come 
in again.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

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

[Larry Hazel]

Warren W. Gay VE3WWG wrote:

> As soon as you start splitting code into different parallel "files",
> you are denormalizing and decentralizing your code. This is
> maintenance hell.  If you find a bug in one of these "portability"
> unique files, then you have to edit several files to effect the
> same fix. It also much more difficult to view the impact to
> other "platforms" for such a fix.

Why is it more difficult to edit several files than several places in 
one file separated by some ugly conditional compilation directives.  The 
code in the separate files would be much cleaner and easier to read. 
The only conditional compilation need I see is some way to select which 
body to use with a spec.
> 
> Don't get me wrong. I support the push for a better solution, but
> I haven't seen any evidence of anything better than a conditional
> compile. Whether conditional compilation comes about by preprocessing
> or as part of the internal compile process, I don't care (compiler
> writers will care however). But I think that the lack of portability
> in Ada does hold it back for more general use.
> 
> MDC also pointed to the need sometimes to do conditional "with" in
> a compile. If I am using GNAT, I may need (or find it convenient)
> to use a GNAT.* package. If I use another Ada compiler, I may want
> to use some other vendor provided packages for similar functionality.
> Of course, depending upon what you "with", will also conditionally
> change what you want to compile.

You should "with" compiler specific units only in a body, so that 
shouldn't be a problem.
> 
> So in the end, there is a strong need for "conditional compiles".
> If we can agree on that, then let's leave preprocessing out of the
> discussion and focus on "conditional compilation". How that is
> achieved is an implementation issue.
> 
> Again, perhaps conditional compilation should also be optional
> to placate those who will have no part in it ;-)
> (perhaps enabled by compile option).

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

[Leon Winslow]

**** Post for FREE via your newsreader at post.usenet.com ****

I'm interested in knowing why no one has mentioned that 40 years ago the
COBAL language included a statement to specify the machine and/or
operating system for the executable code.  If you wanted the program to
run on a UNIX box, you essentially entered UNIX at the head of the
program; if you wanted it to run on a Windows box you entered Windows.
The rest of the program remained the same.  (Its been a long time since
I used this feature so I don't remember the exact syntax.  Maybe someone
else knows?)

Of course, very few compilers actually implemented more than one
option.  If you wanted a different one, you usually needed a different
compiler.

The important feature however is that the rest of the program was
independent of the machine that would execute the program.  If COBAL
could implement this 40 years ago, why can't we try something similar?


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
                      http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:
> Warren W. Gay VE3WWG wrote:
>> As soon as you start splitting code into different parallel "files",
>> you are denormalizing and decentralizing your code. This is
>> maintenance hell.  If you find a bug in one of these "portability"
>> unique files, then you have to edit several files to effect the
>> same fix. It also much more difficult to view the impact to
>> other "platforms" for such a fix.
> 
> C with preprocessor directives is also Maintenance Hell. I don't see 
> that it's a better Hell.

Given that it should be optional, it would not be your problem ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:QEcQb.20015$cQ6.817492@news20.bellglobal.com...
> Dmitry A. Kazakov wrote:
> >>I'd like to be able to hand off a collection of source code and say
> > If we could limit variations to compilation units, I think we could,
> > then there might be a better way than preprocessing.
>
> As soon as you start splitting code into different parallel "files",
> you are denormalizing and decentralizing your code. This is
> maintenance hell.  If you find a bug in one of these "portability"
> unique files, then you have to edit several files to effect the
> same fix. It also much more difficult to view the impact to
> other "platforms" for such a fix.

I have to agree with Dmitry. This is a configuration management problem, and
an editor problem, not a language problem. There's no need to mess with the
language here.

We of course have this sort of problem managing the various versions of
Janus/Ada. Existing version control systems didn't seem to address the
problem in a useful way, in that they don't provide a way to get the most
current files of a particular target, given that some files are shared, some
are related, and some are unique. Tagging and branching just don't do the
trick (tagging because that relates to specific versions of a file, wheras I
want the most recent, and branching because it generally doesn't allow
working on all of the branches at once, nor does it allow identifying which
branch belongs to which app). So our solution was to build a wrapper around
an existing version control system (originally was PVCS, now is CVS) to
track the interelationships, allow grabbing the most recent version of
everything (as well as specific tagged versions), and so on. We can get
reports of related files changed in one version and not updated in another,
so we can mostly avoid "the fix a bug in one version, but not in all
versions" problem.

But the real problem here is version control is at too large a granule.
There is no reason for it to be done at the file level; it would be better
to do it at the level of "pieces", where the actual file that is compiled is
assembled out of pieces by the tools, and versioned separately. Then, even
shared code within related files would change once, and the problems of
different versions would be minimized. (If the change is in unshared code,
there is no alternative to checking the other versions manually; that's true
in a conditional compilation environment as well.)

My conclusion is this a tools problem, not a language problem. The problem
with Ada is immature programming systems, not a lack of conditional
compilation. (And a lot of people who are unwilling to do better -- which of
course is the same reason it is hard to get people to use Ada in the first
place.)

               Randy Brukardt

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

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:PMcQb.20017$cQ6.818801@news20.bellglobal.com...
> How do you solve the issues involved with different curses
> libraries?
>
>   - UNIX/*BSD curses library?
>   - GNU/Linux curses library?
>   - PDcurses?

You use a thick curses binding, of course. And if the bodies need to be
different, then there are different bodies. So what?

There are a number of parts of Claw that have different bodies (and in a few
cases, specs of private packages) for different compilers. It would be nice
if there was an automated way to keep the common parts of those in sync, but
that's a tools issue, not a language issue.

Similarly, the bodies for Claw-less sockets will be completely different
between the Windows version and the GNAT sockets version (and I think, the
Linux version, if we ever do that). (This is closer to your situation.)
There isn't much point in trying to share the code; far too little can be
shared. Conditional compilation only makes sense when you can share large
parts of the code -- but in those cases, careful use of subunits can again
put the differences all into a single body that might as well be handled
separately.

                   Randy.

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

[tmoran]

>But the real problem here is version control is at too large a granule.
>There is no reason for it to be done at the file level; it would be better
>to do it at the level of "pieces", where the actual file that is compiled is
  My impression (having never used it) was that the Rational environment
offered that.  If so, how did it work out?

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

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:
> Jeffrey Carter wrote:
>>
>> C with preprocessor directives is also Maintenance Hell. I don't see 
>> that it's a better Hell.
> 
> Given that it should be optional, it would not be your problem ;-)

So, I'll never have to look at poorly written SW again in my life? Where 
do I sign up?

-- 
Jeff Carter
"C++ is like giving an AK-47 to a monk, shooting him
full of crack and letting him loose in a mall and
expecting him to balance your checking account
'when he has the time.'"
Drew Olbrich
52

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

[Marin David Condic]

Having to maintain something that works on more than one environment is 
always some version of Hell. Given that we don't have one single 
computer architecture and one single OS and one single compiler, etc., 
there is *some* form of Hell we'll have to deal with. Conditional 
compilation may just be the least painful version of Hell in some 
circumstances.

MDC


Warren W. Gay VE3WWG wrote:
> Jeffrey Carter wrote:
>>
>> C with preprocessor directives is also Maintenance Hell. I don't see 
>> that it's a better Hell.
> 
> 
> Given that it should be optional, it would not be your problem ;-)


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

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

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

[Marin David Condic]

It may not be the editing that is a pain but the build process that is a 
pain. Or at least the bigger pain. Since Ada can't promise you some kind 
of build process or CM environment, it can't do much to provide you with 
a *portable* solution to the problem. However, conditional compilation - 
ugly as it may be - is at least *portable*.

MDC

Larry Hazel wrote:
> 
> Why is it more difficult to edit several files than several places in 
> one file separated by some ugly conditional compilation directives.  The 
> code in the separate files would be much cleaner and easier to read. The 
> only conditional compilation need I see is some way to select which body 
> to use with a spec.

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

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

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

[Marin David Condic]

Probably because it was widely ignored by implementers and hence pretty 
close to useless. In a perfect world, all compilers would recognize 
platform differences and correct for them so you had 100% portable code 
- but this is not likely to happen while I'm above ground. Its really 
pretty hopeless to expect that a compiler writer can forsee *all* 
platform differences and deal with them via some abstraction, so you 
have to leave it in the hands of the developer. Somehow, the developer 
needs to detect and code around such platform differences.

MDC



Leon Winslow wrote:
> **** Post for FREE via your newsreader at post.usenet.com ****
> 
> I'm interested in knowing why no one has mentioned that 40 years ago the
> COBAL language included a statement to specify the machine and/or
> operating system for the executable code.  If you wanted the program to
> run on a UNIX box, you essentially entered UNIX at the head of the
> program; if you wanted it to run on a Windows box you entered Windows.
> The rest of the program remained the same.  (Its been a long time since
> I used this feature so I don't remember the exact syntax.  Maybe someone
> else knows?)
> 
> Of course, very few compilers actually implemented more than one
> option.  If you wanted a different one, you usually needed a different
> compiler.
> 
> The important feature however is that the rest of the program was
> independent of the machine that would execute the program.  If COBAL
> could implement this 40 years ago, why can't we try something similar?
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
>                       http://www.usenet.com
> Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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

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

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

[Robert I. Eachus]

Marin David Condic wrote:

> Most of what's in System seems to be useful only at run time. By then, I 
> could have easily solved the problem for myself by having some kind of 
> app-defined configuration file or similar thing I read in and use to 
> determine which calls to make. So any solution has to happen at compile 
> time or it really doesn't do any good.

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.

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

Now it would be nice if I had a compiler that could create a .dll that 
would use x87, 3dNow!, SSE, SSE2, or possibly now SSE3 code as 
appropriate.  I don't.  But assuming I know what I am doing creating the 
correct .dll is not too painful.  (Low-crawling under barbed wire in the 
mud, rather than crawling over broken glass in freezing rain.)

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

So I don't believe in preprocessors for Ada code.  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.

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

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

[Robert I. Eachus]

Marin David Condic wrote:

> Perhaps a pragma that took some constant string and compared it to a 
> string literal and compiled the associated code only if equal would be 
> sufficient. I could build my "package Configuration" and have something 
> like
> 
> pragma If_Equal (Configuration.OS => "TOPS 10",
> <some collection of Ada code - declarative or executable>) ;
> 
> It would be a cheap fix that minimizes the impact to any existing 
> packages or code and only requires compile-time interpretation of a 
> pragma - something compilers already do.

Today you can write code that says:

if Configuration.OS = "TOPS 10"
then
   <some collection of executable Ada code>
else
   <some other collection of excutable Ada code>
end if;

And your compiler should eliminate the code not executed if 
Configuration.OS is a static string constant.  That is available now.

What about declarations?  Then you have two choices.  The first is 
variant parts:

type Foo(Choice: Boolean) is record
   case Choice is
     when True =>
        Tops_10_Component: Float;
     when False =>
         ...
   end case;
end record;

Or you can do:

if Configuration.OS = "TOPS 10"
then
   declare
      Tops_10_Only: Integer := ...;
   begin
      <some collection of executable Ada code>
   end;
else
   declare
      Some_Other_Declaration: Some_Record_Type;
   begin
      <some other collection of excutable Ada code>
   end;
end if;

Also you can make a static Boolean constant:

Tops_10: constant Boolean := Configuration.OS = TOPS 10";

If you want or need to, I usually do.   Oh, one other neat trick.  Look 
at Foo above.  When creating all those objects of type Foo, you don't 
want to have to remember to specify the correct constraint.  So just say:

subtype Foob is Foo(Tops_10);

If you forget and declare an object of type Foo, the compiler will tell 
you.  (Unless of course you give it an initial value, but then you don't 
really have a bug anyway, since the value has the right discriminant.)

If you are generating decent floating point code for x86 processors 
right now you can end up with a LARGE enumeration type and case 
statements. (Actually, combining the cases so the right one is available 
on each system is a non-trivial exercise.  And once I get it working, I 
often leave the intended static constants as variables and set them at 
install-time or run-time.  I need that to make testing survivable, so 
why not let people use it that way. ;-)

So right now, these features are a usable part of the language.  Not 
heavily used, but they can be.  Which is why I think that "fixing" 
System and explaining why would be a big help.



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

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

[Robert I. Eachus]

Marin David Condic wrote:

> O.K. So there's a trick to get around it. (Do we call this "The Other 
> Rosen Trick"? :-) Is Name'Image guaranteed to be in a given character 
> case? (I've not checked that recently & must have forgot.)

UPPER_CASE.

> That may eliminate one possible problem, but it really doesn't help make 
> this feature useful. It still only helps at run time and I could have 
> done that with a package of my own. If it doesn't let you branch around 
> things that won't compile for a given configuration, then it really is 
> mostly useless.

Is it just me, or is this really an issue?  Remember it IS static, which 
means that it does give you contitional compilation at compile time. 
What it doesn't give you is the ability to write code that is illegal, 
and compile anyway if it is not in the (static) execution path.

I just never run into this situation unless there is a bug.  There is 
one case that I am aware of where this CAN happen, supplying a value for 
digits in a floating point type declaration, or declaring an integer or 
modular type that is too large for the implementation.

Of course, I use GNAT. GNAT now supports IEEE floating-point and 64-bit 
integer, fixed, decimal, and modular types for all versions. That is 
enough for 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

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

[Pascal Obry]

Marin David Condic <nobody@noplace.com> writes:

> The more I think about it the more I want there to be a conditional
> compilation capability that would allow some unlimited set of logical names

I'm not sure I agree with that. Of course it will be a working solution but
this is not a solution I'd like to see all over the place. Such feature will
just encourage people to create messy code!

I still prefer the one-spec and multiple bodies solution. At least the spec is
target/hardware independent. This means that a good design needs to be
done. Once this is done the selection of the right body depending on the
target/hardware is a matter of configuration management.

The argument saying that this solution make too much code duplication is
wrong. It is perfectly possible to use child package/procedure/function for
the one routine that is target/hardware dependant in whole API.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

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

[Pascal Obry]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:

> Given that it should be optional, it would not be your problem ;-)

It's also optional in C/C++ ... and AFAIK this is a problem for everybody :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

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

[Marin David Condic]

Well, there are things that happen at compile time. Perhaps in theory 
they don't *have* to happen at compile time - but in the world we live 
in and for the forseeable future, things are going to be done at compile 
time.

Since different compilers often support (or don't support) different 
declarations, I'd like some way of saying "If I'm on Gnat - compile this 
declaration - if on Aonix, make this the declaration...". I don't know 
how that can happen at runtime. Likewise, when withing packages that may 
be compiler dependent and using statements from them, I'd like some way 
of doing that and I can't imagine how a procedure call of something that 
doesn't get withed is going to sneak past the compiler and get resolved 
at runtime.

Like I've said elsewhere, perhaps you can handle this through various CM 
and build processes, but often this is harder to manage or it has 
pitfalls organizationally and it doesn't provide a *portable* answer 
that I know I can count on in some other environment. Sure, you can 
create yet one more layer of indirection and hide all that stuff under a 
"portable" interface (and you probably should, even if you had 
conditional compilation) but you've just pushed the problem off one 
level. You've got two separate bodies of code that have to be tracked 
and managed and maintained and you don't necessarily have the tools to 
do that easily, nor is it guaranteed to work if you've got to drag it to 
an as yet to be specified environment.

Conditional compilation is not necessarily pretty, but the whole mess of 
trying to maintain a variety of different targets never is under the 
best of circumstances. Conditional compilation would at least provide a 
portable answer.

MDC


Robert I. Eachus wrote:
> 
> 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.)

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

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

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

[Marin David Condic]

O.K. Can you think of *some* way for the *language* to specify 
redirection to an alternate body? That might fix most problems - if not 
all. (What do I do if I want alternative declarations in a spec to 
account for compiler differences?)

I suppose if we had some kind of "conditional with" we could construct a 
few more layers of indirection and provide alternate implementations 
that are picked up by the compiler. Some version of:

with if (condition) Gnat_Solution ;
with if (condition) Aonix_Solution ;

and assuming that Gnat_Solution and Aonix_Solution have an identical 
interface (just different bodies) a similar "conditional use" in the 
right context would let you connect to the right thing. (They might not 
need identical interfaces - you might allow for differences in 
declarations so long as all the right identifiers were visible.)

So then if you had a compiler specific package or some platform 
dependent thing, you'd hide it under some "skin" that provided a common 
interface. Withing and using the right "skin" would give you a portable 
way of handling the building of a system for two or more targets. 
(Assuming that the compiler didn't need to compile something 
conditionally withed just to be able to ignore the with.)

MDC

Pascal Obry wrote:
> 
> I'm not sure I agree with that. Of course it will be a working solution but
> this is not a solution I'd like to see all over the place. Such feature will
> just encourage people to create messy code!
> 
> I still prefer the one-spec and multiple bodies solution. At least the spec is
> target/hardware independent. This means that a good design needs to be
> done. Once this is done the selection of the right body depending on the
> target/hardware is a matter of configuration management.
> 
> The argument saying that this solution make too much code duplication is
> wrong. It is perfectly possible to use child package/procedure/function for
> the one routine that is target/hardware dependant in whole API.
> 
> Pascal.
> 


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

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

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

[Marin David Condic]

That works for some things, but it still will barf when a statement is 
compileable for one target but not for another. I'm thinking of a case 
where (for example) you can get one size of float for one target, but 
for another target that size is not allowed. Hiding it in a 
discriminated record isn't going to help if the compiler pukes all over 
the alternative you're not going to use. Perhaps the compiler should be 
smarter - but if I keep waiting for compilers to be smarter, I won't get 
my job done & I'll be forced to resort to C. ;-) If you don't like the 
floating point example ("You ought to be using digits & attributes, you 
fool!" :-) then think "representation clause" and start imagining all 
the target/compiler variations on that.

Its an interesting proposition and might provide some usefulness. 
Certainly there are characteristics that can be toggled at runtime and 
this might be of some help. (Like I said, the runtime stuff I already 
could have handled with my own package.) Its just that usually the point 
where I get hung out to dry is when I can't get something past the 
compiler because it is compiler-dependent or there's something 
platform/target dependent that makes the compiler choke.

MDC


Robert I. Eachus wrote:
> 
> Today you can write code that says:
> 
> if Configuration.OS = "TOPS 10"
> then
>   <some collection of executable Ada code>
> else
>   <some other collection of excutable Ada code>
> end if;
> 
> And your compiler should eliminate the code not executed if 
> Configuration.OS is a static string constant.  That is available now.
> 
> What about declarations?  Then you have two choices.  The first is 
> variant parts:
> 
> type Foo(Choice: Boolean) is record
>   case Choice is
>     when True =>
>        Tops_10_Component: Float;
>     when False =>
>         ...
>   end case;
> end record;
> 
> Or you can do:
> 
> if Configuration.OS = "TOPS 10"
> then
>   declare
>      Tops_10_Only: Integer := ...;
>   begin
>      <some collection of executable Ada code>
>   end;
> else
>   declare
>      Some_Other_Declaration: Some_Record_Type;
>   begin
>      <some other collection of excutable Ada code>
>   end;
> end if;
> 
> Also you can make a static Boolean constant:
> 
> Tops_10: constant Boolean := Configuration.OS = TOPS 10";
> 
> If you want or need to, I usually do.   Oh, one other neat trick.  Look 
> at Foo above.  When creating all those objects of type Foo, you don't 
> want to have to remember to specify the correct constraint.  So just say:
> 
> subtype Foob is Foo(Tops_10);
> 
> If you forget and declare an object of type Foo, the compiler will tell 
> you.  (Unless of course you give it an initial value, but then you don't 
> really have a bug anyway, since the value has the right discriminant.)
> 
> If you are generating decent floating point code for x86 processors 
> right now you can end up with a LARGE enumeration type and case 
> statements. (Actually, combining the cases so the right one is available 
> on each system is a non-trivial exercise.  And once I get it working, I 
> often leave the intended static constants as variables and set them at 
> install-time or run-time.  I need that to make testing survivable, so 
> why not let people use it that way. ;-)
> 
> So right now, these features are a usable part of the language.  Not 
> heavily used, but they can be.  Which is why I think that "fixing" 
> System and explaining why would be a big help.
> 
> 
> 


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

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

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

[Marin David Condic]

Maybe its just you. :-) I don't run into it every day - its just that 
when you run into it, its like hitting a brick wall at 100mph.

Code can be 100% totally legal and not compile. I can write you 
representation clauses all day long that are 100% pure Ada and will just 
make the compiler puke all over the place. (Or perhaps not give you what 
you want - which may be even worse). Compiler X may support the 
statement but Compiler Y may not. Worse, Compiler X for Target A may 
consider it legal but Compiler X for Target B does not. When you run 
into it, you end up pulling out your hair wishing you had some means of 
making the compiler ignore the version of the statement that you don't 
want for the particular target.

Sometimes its a really, really little thing and you start considering 
another layer of indirection and separate build paths and the potential 
inefficiencies of the extra indirection (for me, that's often an issue) 
and you're going "Damnation! If I just had one little itsy-bitsy, 
insignificant, tiny conditional compilation directive here, I'd save 
myself the massive trouble of having to deal with two separate builds 
and all the headaches that go with it! Curse you, Ada Lovelace!!!" I'd 
rather not have that headache - and sometimes there are prohibitions or 
problems with multiple build paths that make it difficult or impossible. 
So you find some way of suffering under durress and muddling through and 
envying the guys who get to use C. :-)

MDC


Robert I. Eachus wrote:
> 
> Is it just me, or is this really an issue?  Remember it IS static, which 
> means that it does give you contitional compilation at compile time. 
> What it doesn't give you is the ability to write code that is illegal, 
> and compile anyway if it is not in the (static) execution path.
> 
> I just never run into this situation unless there is a bug.  There is 
> one case that I am aware of where this CAN happen, supplying a value for 
> digits in a floating point type declaration, or declaring an integer or 
> modular type that is too large for the implementation.
> 
> Of course, I use GNAT. GNAT now supports IEEE floating-point and 64-bit 
> integer, fixed, decimal, and modular types for all versions. That is 
> enough for me.
> 


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

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

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

[Robert I. Eachus]

Marin David Condic wrote:

> Since different compilers often support (or don't support) different 
> declarations, I'd like some way of saying "If I'm on Gnat - compile this 
> declaration - if on Aonix, make this the declaration...". I don't know 
> how that can happen at runtime. Likewise, when withing packages that may 
> be compiler dependent and using statements from them, I'd like some way 
> of doing that and I can't imagine how a procedure call of something that 
> doesn't get withed is going to sneak past the compiler and get resolved 
> at runtime.

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

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

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

[Robert I. Eachus]

Marin David Condic wrote:

> I suppose if we had some kind of "conditional with" we could construct a 
> few more layers of indirection and provide alternate implementations 
> that are picked up by the compiler. Some version of:
> 
> with if (condition) Gnat_Solution ;
> with if (condition) Aonix_Solution ;
> 
> and assuming that Gnat_Solution and Aonix_Solution have an identical 
> interface (just different bodies) a similar "conditional use" in the 
> right context would let you connect to the right thing.

But again you are trying hard to make things difficult for yourself. 
First, if the interface to Gnat_Solution and Aonix_Solution are 
identical, why do you want to make source that uses the interface 
compiler dependent?  Both the Gnat and Aonix packages should be named 
Solution. ;-)

Now that you have gone that far, you have banished all of the compiler 
dependencies to the body of Solution.  Either use the tricks I 
described, or if the bodies are so different that it makes sense to 
mantain them separately, provide them as separate files, and use 
different makefiles for Aonix and Gnat.  (Gnat likes to dictate the 
names of files, but it does provide facilities for overriding that.)


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

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

[Marin David Condic]

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

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

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

[Robert I. Eachus]

Marin David Condic wrote:

> That works for some things, but it still will barf when a statement is 
> compileable for one target but not for another. I'm thinking of a case 
> where (for example) you can get one size of float for one target, but 
> for another target that size is not allowed...

I'm sorry, but to me this is heresy.  Not that you might want to specify 
a value for digits, I do that all the time.

But when it matters enough to specify it, it is IMPORTANT.  If a 
particular compiler doesn't support that specification, there is no 
point in trying to hide the problem.  The application code I wrote won't 
run in that environment.  End of story.

Well, not exactly end of story.  There are cases where I write code that 
uses IEEE extended precision if available, and when it is not uses IEEE 
double with different algorithms and other methods of maintaining the 
required precision, such as scaled (64-bit) integers.  That code is so 
different there is no point in trying to deal with it using ifdefs or 
whatever.  Two different matrix library bodies for the same 
specification is the best I can do.

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

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

[Marin David Condic]

Robert I. Eachus wrote:
> 
> But again you are trying hard to make things difficult for yourself. 
> First, if the interface to Gnat_Solution and Aonix_Solution are 
> identical, why do you want to make source that uses the interface 
> compiler dependent?  Both the Gnat and Aonix packages should be named 
> Solution. ;-)
> 
They may not be "identical" in all respects - remember rep clauses! I 
can have declarations that *won't* compile on some compiler. However the 
type, object, subprogram, etc. *names* might be identical.

And I'd like a way to make sure I never try to compile/link/run a Gnat 
package body with an Aonix compiler/linker. Maybe I can start with an 
identical spec and two different bodies (maybe!) and how is it I make 
sure the right body gets picked up by the right compiler? That's an 
environmental thing - so I have to figure that one out and come up with 
some scheme for handling that. (makefiles, CVS trees, whatever. It won't 
be portable.)

All you can do is delay the problem with indirection - you can't make it 
go away. Sooner or later, you've got code that compiles for one 
environment and not for another. Now manage it. (Or maybe I could have a 
conditional compile preprocessor and have just *one* set of files to 
deal with? :-)

> Now that you have gone that far, you have banished all of the compiler 
> dependencies to the body of Solution.  Either use the tricks I 
> described, or if the bodies are so different that it makes sense to 
> mantain them separately, provide them as separate files, and use 
> different makefiles for Aonix and Gnat.  (Gnat likes to dictate the 
> names of files, but it does provide facilities for overriding that.)
> 
> 
Yup. I've been saying all along that I *know* I can solve the problem 
with some kind of build process and/or CM. Separate makefiles (if you 
have makefiles) or some other OS/third-party-product dependent answer is 
out there. We've been building different builds of the same thing for a 
long time now and a solution does exist. I have *never* said you 
couldn't find a way to do it with technology that exists today. A 
solution does exist.

Just not a *Portable* solution and one you can count on being there all 
the time. And not always a *simple* solution to a sometimes *simple* 
problem. You're dependent on some kind of 
outside-the-language-can't-count-on-having-it-there patch to deal with 
the fact that compilers and OS's and libraries and targets and 
environments are *not* always identical.

Also, its sometimes "Overkill" to suddenly have to buy into separate 
builds with separate sources and separate CM on them, etc. If you need 
just a small handful of things fixed at some low level, you may not want 
to force your project to forever be doing that extra maintenance effort 
and bookeeping that goes along with handling divergent copies of source 
code.

I'm not saying I can't find a way to live without it. I'm just saying it 
would help simplify a lot of problems if we had something like 
conditional compilation or some other patch to deal with differences 
between environments. I'd like to have a way of *not* having divergent 
copies of source code - or if they must diverge, then give me a 
mechanism for auto-selecting them that I can count on having in any 
place I take the code.

MDC

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

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

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

[tmoran]

>and you're going "Damnation! If I just had one little itsy-bitsy,
>insignificant, tiny conditional compilation directive here, I'd save
   If the preprocessor was limited to something like
--Gnat_Win32     <<code for Gnat on Win32 target>>
--ObjectAda_Linux <<code for ObjectAda, Linux target>>
I would agree that's helpful.  But as soon as the preprocessor gets
non-trivial - nested conditionals, includes, etc - it's just begging for
idiots (and even some otherwise non-idiots) to create a mess.  I've seen C
code from large and well known companies that is nearly impenetrable due
to overuse of the preprocessor.  If they had spent 1/10 the effort on good
design-for-multiple-systems, it would have been maintainable, but it's
much easier to add a (preprocessor) tweak here and there and let the mess
grow.  And the answer "good programmers will not misuse the language"
doesn't fly very well in c.l.a.

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

[Marin David Condic]

Oh yes! Of course! I agree 1000%!

I've *seen* and had to maintain things where the C preprocessor was 
abused to the point where one could spend days trying to decipher macros 
and all that. Let's not even start with #include chains! I absolutely 
don't want something that would turn into an unholy mess.

I think some relatively simple directive(s) that could give you one 
version of something when its Compiler A and another version of 
something if its Compiler B (or likewise for possibly unsupported 
packages, or OS dependencies) that would be enough to minimize the fuss 
when you've got relatively small & trivial things to go fix.

Of course a lot of these things have a nasty habbit of growing along the 
way into something way beyond the original intent.

MDC



tmoran@acm.org wrote:
>>and you're going "Damnation! If I just had one little itsy-bitsy,
>>insignificant, tiny conditional compilation directive here, I'd save
> 
>    If the preprocessor was limited to something like
> --Gnat_Win32     <<code for Gnat on Win32 target>>
> --ObjectAda_Linux <<code for ObjectAda, Linux target>>
> I would agree that's helpful.  But as soon as the preprocessor gets
> non-trivial - nested conditionals, includes, etc - it's just begging for
> idiots (and even some otherwise non-idiots) to create a mess.  I've seen C
> code from large and well known companies that is nearly impenetrable due
> to overuse of the preprocessor.  If they had spent 1/10 the effort on good
> design-for-multiple-systems, it would have been maintainable, but it's
> much easier to add a (preprocessor) tweak here and there and let the mess
> grow.  And the answer "good programmers will not misuse the language"
> doesn't fly very well in c.l.a.


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

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

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

[Robert I. Eachus]

Marin David Condic wrote:

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

Totally agree, which is why I try to do it all in Ada source, with "if 
SSE then..." instead of "#ifdef SSE ..."  The disadvantage of this 
approach is that the code must compile cleanly, even if it will be 
statically eliminated at compile time.

I just haven't found that to be a major hurdle.  I can easily see that 
happening if you are "up against the wall" with a compiler bug.  But 
with GNAT, I have the source, and know how to use it. ;-)

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

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

[Marin David Condic]

Well, I suppose if I assumed Gnat as the compiler (not always possible, 
obviously) then I at least have this work around: Code it up in C with 
#ifdef's and bind to it with Ada. :-)

The problem is, of course, sometimes you can't assume a C compiler is 
around - unless you're coding the whole thing in C and then its a 
non-issue. With C, you clearly can get your conditional compilation (and 
a bunch of things you maybe *didn't* want ;-) That is one reason why a 
lot of developers go with C. It does what they *want* it to do instead 
of having it tell them "You shouldn't *want* to do that!" I think that's 
one thing that makes it difficult to sell Ada sometimes.

MDC

Robert I. Eachus wrote:
> 
> I just haven't found that to be a major hurdle.  I can easily see that 
> happening if you are "up against the wall" with a compiler bug.  But 
> with GNAT, I have the source, and know how to use it. ;-)
> 


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

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

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

[Dmitry A. Kazakov]

On Fri, 23 Jan 2004 12:16:20 -0500, "Warren W. Gay VE3WWG"
<warren@ve3wwg.tk> wrote:

>Dmitry A. Kazakov wrote:
>> On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic
>> <nobody@noplace.com> wrote:
>> 
>>>That's why much as I might find some kind of preprocessing distasteful 
>>>and certainly don't want to watch it degenerate into the unholy mess 
>>>that you have with C, I think we need *some* mechanism for conditional 
>>>compilation.
>>>
>>>Those who argue that it should all be isolated with different package 
>>>bodies have to address the fact that a) this is often difficult or 
>>>impossible
>...
>>>and b) it implies some kind of configuration management or 
>>>build utilities that are totally outside the scope of the language and 
>>>may not exist.
>> 
>> But the language defines the notion of a library. If we could extend
>> it in a way allowing selection of a child units path during
>> compilation, then I believe, it could be 80% of the issue.
>
>Whether the problem is 50% or 20% is not the issue. The problem is
>that even if I have a 2% problem, it is a _royal_pain_(TM). If you
>have to support different implementation defined pragmas, if you have
>to support optional record components (in bindings to OS services
>or to different C libraries like readline), then whether the
>problem is big or small, it is unsolved if it ain't 100% solved.

Mmm, you know, we are happily working with a finite subset of rational
numbers, which represent 0% of all reals.

>>>I'd like to be able to hand off a collection of source code and say 
>>>"This is the main program - just compile it from there on your 
>>>machine..." If it involves different bodies, I've got to provide you 
>>>with detailed build instructions and can't assume you've got the same 
>>>tools as I do. All that gets fixed automagically if I could put some 
>>>conditional compilation statements into the code that indicate which way 
>>>to go based on some kind of directive to the compiler. (I don't trust 
>>>something in the package System to be sufficient - that at best can only 
>>>tell you about the compiler, but not necessarily about the external 
>>>platform and its potential variations.)
>> 
>> If we could limit variations to compilation units, I think we could,
>> then there might be a better way than preprocessing.
>
>As soon as you start splitting code into different parallel "files",
>you are denormalizing and decentralizing your code. This is
>maintenance hell.  If you find a bug in one of these "portability"
>unique files, then you have to edit several files to effect the
>same fix. It also much more difficult to view the impact to
>other "platforms" for such a fix.

No, this is why instead of loose conditional withs, I would like to
see abstract packages defining an interface for a path to implement.
Then a portable program will be developed in terms of that abstract
package interface. This would be, so to speak, a "package-wide"
program. Fixing a bug there will do it for all paths. A bug fixed in a
path (implementation) will by no means affect other paths.

Already in Ada one could write:

generic
   type File is limited private;
   with procedure Read (...) is <>;
   with procedure Write (...) is <>;
   ---
package Abstract_OS_Interface is
  -- Nothing here
end Abstract_OS_Interface;

Then:

with Abstract_OS_Interface;
package UNIX is
   type File is ...;
   procedure Read (...);
   procedure Write (...);
   package Interface is new Abstract_OS_Interface (File);
end UNIX;

with Abstract_OS_Interface;
package Win32 is
   type File is ...;
   procedure Read (...);
   procedure Write (...);
   package Interface is new Abstract_OS_Interface (File);
end Win32;

Now what I need is just to conditionally with/use *.Interface and,
importantly, to have a way to ensure that nothing else from the
enclosing package be visible.

The technique above works fine with subroutines having defaults. But
it becomes awkward with types and values. Worse is that one cannot
hide implementations in private:

package Win32 is
   type File is limited private;
   procedure Read (...);
   procedure Write (...);
   package Interface is new Abstract_OS_Interface (File);
      -- Error, a premature use of File!
private
   type File is limited record
      ... -- Do want them see it
   end record;
end Win32;

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

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

[Ole-Hjalmar Kristensen]

>>>>> "MDC" == Marin David Condic <nobody@noplace.com> writes:

    MDC> O.K.  Can  you think  of  *some* way  for  the  *language* to  specify
    MDC> redirection to  an alternate body? That  might fix most  problems - if
    MDC> not all. (What do I do if I want alternative declarations in a spec to
    MDC> account for compiler differences?)

What about allowing specialization of generic packages? Then you could
have multiple bodies, the right one selected by the arguments to the
generic instantiation.


    MDC> I suppose if we had some kind of "conditional with" we could construct
    MDC> a few more layers of indirection and provide alternate implementations
    MDC> that are picked up by the compiler. Some version of:


    MDC> with if (condition) Gnat_Solution ;
    MDC> with if (condition) Aonix_Solution ;

    MDC> and assuming  that Gnat_Solution and Aonix_Solution  have an identical
    MDC> interface (just  different bodies) a similar "conditional  use" in the
    MDC> right context  would let you connect  to the right  thing. (They might
    MDC> not need  identical interfaces  - you might  allow for  differences in
    MDC> declarations so long as all the right identifiers were visible.)


    MDC> So  then if  you  had a  compiler  specific package  or some  platform
    MDC> dependent  thing, you'd  hide it  under  some "skin"  that provided  a
    MDC> common interface. Withing and using  the right "skin" would give you a
    MDC> portable way  of handling  the building  of a system  for two  or more
    MDC> targets. (Assuming that the  compiler didn't need to compile something
    MDC> conditionally withed just to be able to ignore the with.)


    MDC> MDC

    MDC> Pascal Obry wrote:
    >> I'm  not sure I  agree with  that. Of  course it  will be  a working
    >> solution but

    >> this is not a solution I'd like to see all over the place. Such feature will
    >> just encourage people to create messy code!
    >> I still prefer  the one-spec and multiple bodies  solution. At least
    >> the spec is

    >> target/hardware independent. This means that a good design needs to be
    >> done. Once this is done the selection of the right body depending on the
    >> target/hardware is a matter of configuration management.
    >> The  argument   saying  that  this  solution  make   too  much  code
    >> duplication is

    >> wrong. It is perfectly possible to use child package/procedure/function for
    >> the one routine that is target/hardware dependant in whole API.
    >> Pascal.

    >> 



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

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

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

    MDC>          --  Al Bundy

    MDC> ======================================================================


-- 
   C++: The power, elegance and simplicity of a hand grenade.

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

[Marin David Condic]

I don't know what that would look like. Would you see it as somehow able 
to select a body to compile based on some kind of switch or condition 
settable by the compiler? It *feels* a little cumbersome, but I'd have 
to see an example of how it would work to say for sure.

MDC

Ole-Hjalmar Kristensen wrote:
> 
> What about allowing specialization of generic packages? Then you could
> have multiple bodies, the right one selected by the arguments to the
> generic instantiation.
> 

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

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

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

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:
> Warren W. Gay VE3WWG wrote:
>> Jeffrey Carter wrote:
>>> C with preprocessor directives is also Maintenance Hell. I don't see 
>>> that it's a better Hell.
>>
>> Given that it should be optional, it would not be your problem ;-)
> 
> So, I'll never have to look at poorly written SW again in my life? Where 
> do I sign up?

You of course, with tongue in cheek, read too much into that ;-)

But this last statement of yours seems to imply:

   "conditionally compiled code = poorly written SW"

If so, I would have to simply disagree.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Having to maintain something that works on more than one environment is 
> always some version of Hell. Given that we don't have one single 
> computer architecture and one single OS and one single compiler, etc., 
> there is *some* form of Hell we'll have to deal with. Conditional 
> compilation may just be the least painful version of Hell in some 
> circumstances.
> 
> MDC
> 
> Warren W. Gay VE3WWG wrote:
>> Jeffrey Carter wrote:
>>
>>> C with preprocessor directives is also Maintenance Hell. I don't see 
>>> that it's a better Hell.
>>
>> Given that it should be optional, it would not be your problem ;-)

I would tend to agree. There is no "pure" way to make non-trivial
code portable.

If we go back to the "non-normalized database" metaphore, keeping
separate versions of code for purity sake (to avoid conditional
compilation), is like having to update a customer name in a
database in 12 different tables. This potentially leads to
leaving one instance of that name wrong, or left unchanged.

Whereas, centralizing the affected code in one place (ugly or not),
requires only one update to get it changed (like changing a name
in a database in one centralized place).

Again, I am not saying it has to be "preprocessing" because that is
an implementation detail.

I am also saying that it need not look like C's preprocessor #ifs.
Choose something more elegant.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Pascal Obry wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:
> 
>>Given that it should be optional, it would not be your problem ;-)
> 
> It's also optional in C/C++ ... and AFAIK this is a problem for everybody :)
> 
> Pascal.

You have to go out of your way to turn it off in a C/C++
compile. In that sense, it is not optional.

Another factor that gets into the way of optional use in
C/C++, is the fact that the standard and system include
files all *require* that preprocessing takes place.

So in the normal C/C++ use, preprocessing is _not_
optional. But you knew that already ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:QEcQb.20015$cQ6.817492@news20.bellglobal.com...
> 
>>Dmitry A. Kazakov wrote:
>>
>>>>I'd like to be able to hand off a collection of source code and say
>>>
>>>If we could limit variations to compilation units, I think we could,
>>>then there might be a better way than preprocessing.
>>
>>As soon as you start splitting code into different parallel "files",
>>you are denormalizing and decentralizing your code. This is
>>maintenance hell.  If you find a bug in one of these "portability"
>>unique files, then you have to edit several files to effect the
>>same fix. It also much more difficult to view the impact to
>>other "platforms" for such a fix.
> 
> I have to agree with Dmitry. This is a configuration management problem, and
> an editor problem, not a language problem. There's no need to mess with the
> language here.

I would settle for a standard "precompiler tool", if one doesn't
want to tinker with the language. For me, this matter is all moot
anyway, because all that I am likely to use is gnatprep, lacking
any other standard tool.

However, having said that, there may be some advantages to integrating
conditional compilation into the language. One of the problems that
C/C++ has, is that you cannot do things like:

   #if sizeof(int) == 16
   ...
   #else
   ...
   #endif

This is just one example. Another might be to test the offset
of a structure member, and add padding where necessary.

The problem is that the preprocessor does not have the ability to
evaluate size expressions.

Ada projects may also have similar needs and more. Having
a conditional compilation integrated into the language might
provide some advanced portability features. Certainly
integration like this would be an improvement in capability
over other languages beginning with C ;-)

And what I find amusing is that except for a few that
appreciate this issue, we've heard of every ugly
work-around possible, rather than face the issue
square in the eye. This is just my opinion mind you,
and perhaps small things amuse me ;-)

It seems like a large number of people have this "Ada
doesn't do it this way" attitude (otherwise known as
"not invented here syndrome"). It kind of reminds me
of the differences between Linux developers vs the
*BSD ones. Both sides can learn from the other, but
one side tends to look down on the other, and thus
limits their thinking. (I won't say who ;-)

As Ada stands now, it only serves the less portable
embedded environment. If people truly do want to see
wide-spread adoption of Ada, you will need to
improve the portability to a level that competes
well with C/C++.

As for me, based upon what I have seen in this group,
I'll just go on using gnatprep like I always have. The
fact that ACT created this tool, and the fact that I
and others use it, demonstrates a need that is not yet
satisfied by the standard.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Marin David Condic wrote:
>> Most of what's in System seems to be useful only at run time. By then, 
>> I could have easily solved the problem for myself by having some kind 
>> of app-defined configuration file or similar thing I read in and use 
>> to determine which calls to make. So any solution has to happen at 
>> compile time or it really doesn't do any good.
> 
> 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.

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

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:onk910pmf41et1uai45hc6mfqhasdkmi8c@4ax.com...
...
> The technique above works fine with subroutines having defaults. But
> it becomes awkward with types and values. Worse is that one cannot
> hide implementations in private:
>
> package Win32 is
>    type File is limited private;
>    procedure Read (...);
>    procedure Write (...);
>    package Interface is new Abstract_OS_Interface (File);
>       -- Error, a premature use of File!
> private
>    type File is limited record
>       ... -- Do want them see it
>    end record;
> end Win32;

There is an AI on this problem. Dunno if it will get solved, though - the
proposed solutions have not picked up much support...

              Randy.

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

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Warren W. Gay VE3WWG [mailto:warren@ve3wwg.tk]
...
| >>
| >>> C with preprocessor directives is also Maintenance Hell. 
| I don't see 
| >>> that it's a better Hell.
| >>
| >> Given that it should be optional, it would not be your problem ;-)
| 
| I would tend to agree. There is no "pure" way to make non-trivial
| code portable.
| 
| If we go back to the "non-normalized database" metaphore, keeping
| separate versions of code for purity sake (to avoid conditional
| compilation), is like having to update a customer name in a
| database in 12 different tables. This potentially leads to
| leaving one instance of that name wrong, or left unchanged.

A good design allows to separate common and customized code in a pretty
sharp way.
There is no free lunch, and you need some more code and design.
Method template and Strategy patterns are useful here.
It is possible (and not so hard) to get a software with no embedded dead
code, and with almost no possible source confusion, that is, with the whole
configuration defined in one source.

Lets consider two OS interfaces (not compiled code) :

----------------------------------------------------------
package OS_Interface is
  procedure Open_File (Name ...
                       ...);
  ...
  -- etc.

private
  type Abstract_Interface is abstract ...
  procedure Open_File (Abstract_Interface ...
                       Name ...
                       ...) is abstract;
  ...

  procedure Register_As_Concrete (Abstract_Interface'class'Access...); 
  -- used by child interfaces to register themself 

end OS_Interface;

----------------------------------------------------------
package body OS_Interface is

   Concrete : ... -- pointer to the concrete Interface, 
   -- set by Register_As_Concrete 

 
   procedure Open_File (Name ...
                        ...) is
   begin
      Open_File (Concrete,
                 Name ...); -- let's dispatch to the concrete
                            -- Interface
   end Open_File;

   ...   

end OS_Interface;
   


----------------------------------------------------------
package OS_Interface.Windows is
   type Windows_Interface is new Abstract_Interface ...
   -- define abstract operations
   -- redefine some of the concrete operations.
   ...

   procedure Register;
   -- register this one as the concrete interface 
   -- by calling Register_As_Concrete with 
   -- a local dummy instance of Windows_Interface

end OS_Interface.Windows;


For the configuration, you need some separate configuration procedure :

----------------------------------------------------------
separate (Main)
procedure Configure is
begin
   OS_Interface.Windows.Register;
end Configure;


But this is the only compilation unit provided in several versions, the only
one that you need to manage carefully in your configuration system. 
As for conditional compilation systems, some external configuration is
pretty unavoidable.

Note also that calls to (for example) a specific Linux thin binding will be
hidden into the OS_Interface.Linux package : Register is the only operation
in OS_Interface child specification, so if you don't "with" it within the
Configure operation, this code is not included in the executable.

Another advantage is that you don't touch common code when adding or
modifying some specific implementation. You don't cause useless
recompilations or regression testing.

For user code, the whole stuff is hidden : it just call 
OS_Interface.Open_File (Name, ...);
as usual. 

One drawback of this template respect to conditional compilation is an added
indirection and dispatching hidden into OS_Interface body. 
But if someone care of performance at this point, he is in a desperate
situation.

Another drawback is the difficulty to compare implementations, but it's not
that useful, neither that  difficult to do with your favorite environment.

-- 
Lionel Draghi

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

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:PMcQb.20017$cQ6.818801@news20.bellglobal.com...
> 
>>How do you solve the issues involved with different curses
>>libraries?
>>
>>  - UNIX/*BSD curses library?
>>  - GNU/Linux curses library?
>>  - PDcurses?
> 
> You use a thick curses binding, of course. 

Of course, and just what do you think the binding has to
worry about? ;-)

> And if the bodies need to be
> different, then there are different bodies. So what?

The "so what" is that 90% of the code will be in common.
So why would I duplicate 90% to manage the 10% in 3+
cases?

Centralized maintenance is what I am after. As soon as
you decentralize it, someone is going to forget, bungle
or neglect to update the fix in one of the other n
bodies. This does not a good solution make.

> There are a number of parts of Claw that have different bodies (and in a few
> cases, specs of private packages) for different compilers. It would be nice
> if there was an automated way to keep the common parts of those in sync, but
> that's a tools issue, not a language issue.

That is just narrow thinking. Only you are saying it
"must be tools". I am suggesting that perhaps another
more natural solution is possible.

> Similarly, the bodies for Claw-less sockets will be completely different
> between the Windows version and the GNAT sockets version (and I think, the
> Linux version, if we ever do that). (This is closer to your situation.)
> There isn't much point in trying to share the code; far too little can be
> shared. Conditional compilation only makes sense when you can share large
> parts of the code -- but in those cases, careful use of subunits can again
> put the differences all into a single body that might as well be handled
> separately.
> 
>                    Randy.

I am not suggesting for a minute that the whole world needs to
release software in the same manner. It doesn't seem to bother
you to maintain multiple instances of similar code. I personally
hate it and would much rather have it centralized. We can disagree
on the preference.

Can we agree on having a choice at least?
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Robert A Duff]

Lionel.DRAGHI@fr.thalesgroup.com writes:

The approach you outlined is a good one, in many cases, but:

> One drawback of this template respect to conditional compilation is an added
> indirection and dispatching hidden into OS_Interface body. 
> But if someone care of performance at this point, he is in a desperate
> situation.

I have sometimes needed static constants that depend on the
configuration, either for efficiency reasons, or so I could use
them in places where Ada requires static expressions.

- Bob

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

[Robert I. Eachus]

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

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

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> I am not suggesting for a minute that the whole world needs to
> release software in the same manner. It doesn't seem to bother
> you to maintain multiple instances of similar code. I personally
> hate it and would much rather have it centralized. We can disagree
> on the preference.

As long as you understand that the people arguing on both sides here 
actually know what they are talking about.  Right now I don't do much 
embedded work. Randy's work with CLAW is probably among the goriest 
cases of a thick binding dealing with multiple environments around.

> Can we agree on having a choice at least?

Sure, you have that choice.  There are several good pre-processors for 
Ada.  Go, get one, use it.  Pretty soon you will join Randy and I on the 
other side of the fence.  Don't get me wrong, the GNAT pre-processor 
facilities are great, much better than cpp.  But when you really try to 
use it you end up in self protection migrating as much pre-processor 
stuff as possible into one unit.  Then once you start planning out the 
code you want for some change to that unit, then figuring out where to 
stick it in the middle of all the preprocessor directives, you will 
agree that multiple bodies are easier to maintain. ;-)

(Incidently, there is an intermediate position you go through, and which 
  works nicely for some units.  The bodies of subprograms in the unit 
each turns into a case statement on the processor or compiler.  But when 
I reach that point, I use Ada instead of the pre-processor for the case 
statements.)
-- 
                                           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

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

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

>> And if the bodies need to be
>> different, then there are different bodies. So what?
> 
> The "so what" is that 90% of the code will be in common.
> So why would I duplicate 90% to manage the 10% in 3+
> cases?

There's no code in common if you do it right.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

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

[Marin David Condic]

Just about any language feature can be abused. What about 
Unchecked_Conversion? What about address clauses to achieve overlays? 
What about rep clauses in general? Any of these things (and more!) could 
be criticized as leading to "Bad Software Engineering" - but they serve 
a useful purpose and the developer is advised to use them judiciously.

Anyone who spatters his code all over with conditional compilation 
directives isn't working to a proper design. But how would that be 
different than spattering the code all over with direct calls to an OS? 
Given that such style leads to lack of portability, should we disallow 
such a capability? Or perhaps we trust that the wise developer will 
isolate the OS dependencies down at some low level that is relatively 
easily replaced should the code move or OS change? Same with conditional 
compilation - trust that the wise developer will use it judiciously 
where it makes sense.

MDC



Warren W. Gay VE3WWG wrote:
> 
> But this last statement of yours seems to imply:
> 
>   "conditionally compiled code = poorly written SW"
> 
> If so, I would have to simply disagree.
> 


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

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

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

[Marin David Condic]

Someone might come up with a tool that makes this relatively easy to 
manage and unlikely to get missed. I've not seen a tool that makes it 
totally painless or without the possibility of error. In any event, if 
such a tool did exist and managing separate source files was free (or 
really cheap) and it was damned near impossible to miss updating all the 
versions of the source, it would *still* not be an answer that the Ada 
developer could count on being in place everywhere he might send his code.

In the days of "Open Source" - that ought to be a concern.

MDC


Warren W. Gay VE3WWG wrote:
> 
> If we go back to the "non-normalized database" metaphore, keeping
> separate versions of code for purity sake (to avoid conditional
> compilation), is like having to update a customer name in a
> database in 12 different tables. This potentially leads to
> leaving one instance of that name wrong, or left unchanged.
> 

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

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

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

[Marin David Condic]

Warren W. Gay VE3WWG wrote:
> 
> And what I find amusing is that except for a few that
> appreciate this issue, we've heard of every ugly
> work-around possible, rather than face the issue
> square in the eye. This is just my opinion mind you,
> and perhaps small things amuse me ;-)
> 
Perhaps it starts from noble intentions. There are certainly a large 
number of cases where a C programmer might dive into conditional 
compilation when a more "pure" approach might yield an answer that is 
more elegant and less subject to errors. But having decided from such 
examples that "Conditional Compilation = Evil" we then see increasingly 
complex, difficult to implement and (often) non-portable and inefficient 
schemes to try to work around not having it. After a while you start 
wondering "what was it I was trying to avoid with all these gyrations 
and was it really so bad???"

> 
> As Ada stands now, it only serves the less portable
> embedded environment. If people truly do want to see
> wide-spread adoption of Ada, you will need to
> improve the portability to a level that competes
> well with C/C++.
> 
Remember that when it comes to embedded systems, "Ada" ranks below 
"Other" in choice of programming language. Somehow, Ada failed to pay 
attention to the embedded customer and got profoundly ignored in return. 
So having blown that market - probably permanently - it should likely 
not worry so much about that market and concentrate on others.

Having said that, I'd dispute that embeded computing has any less need 
for portability than any other area. Perhaps at times even more need for 
portability. You're often trying to write code that will work with 
off-line simulations, prototype boards, different variants of production 
boards, multiple versions of RTOS's, etc. Further, because these systems 
might hang around for many generations of hardware, they have to be 
adaptable to change. So yes, I get to worry a whole lot about 
portability of code. ;-)


> As for me, based upon what I have seen in this group,
> I'll just go on using gnatprep like I always have. The
> fact that ACT created this tool, and the fact that I
> and others use it, demonstrates a need that is not yet
> satisfied by the standard.

Since tools *are* invented to do this sort of thing regularly, it would 
be nice to have a *standard* set of tools one could count on having in 
place. People find a way of getting what they want. Sometimes its done 
by switching languages.

MDC

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

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

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

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

OK, understood now.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Warren W. Gay VE3WWG wrote:
...
>> Can we agree on having a choice at least?
> 
> Sure, you have that choice.  There are several good pre-processors for 
> Ada.  Go, get one, use it.  

I've been using one for quite some time. But remember,
the request was for a *standard* one. ;-)

> Pretty soon you will join Randy and I on the 
> other side of the fence.  

Until systems start all looking the same (not likely),
and userland APIs (shared libraries) all start being
consistent (there will always be different versions),
I'll always have to be adapting Ada code to these
messy differences. Until the day comes when I don't
need to write bindings to C and C++ code, I'll
always be using gnatprep, as I have from the beginning.

Until I get Ada bindings for all the C stuff out there,
I will always be in need for "conditional compilation".
Read my lips ;-)

> Don't get me wrong, the GNAT pre-processor 
> facilities are great, much better than cpp.  But when you really try to 
> use it you end up in self protection migrating as much pre-processor 
> stuff as possible into one unit.  Then once you start planning out the 
> code you want for some change to that unit, then figuring out where to 
> stick it in the middle of all the preprocessor directives, you will 
> agree that multiple bodies are easier to maintain. ;-)
> 
> (Incidently, there is an intermediate position you go through, and which 
>  works nicely for some units.  The bodies of subprograms in the unit 
> each turns into a case statement on the processor or compiler.  But when 
> I reach that point, I use Ada instead of the pre-processor for the case 
> statements.)

I am _not_ saying that gnatprep _is_ the solution. But some
carefully designed conditional compilation needs to be
considered. It should be available and optional.

That is all.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Jacob Sparre Andersen]

Marin David Condic wrote:

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

Would a pragma in the package specification declaring which file the
package body should be read from depending on some compilation
parameters (compiler, operating system, etc.) do the job?

Something like this, where the body is grabbed from the file named by
the first "Body_Source_File" pragma with a matching condition.  If no
"Body_Source_File" pragma has a matching condition, the compiler just
uses its default routine for finding the source code for the package
body.

with System;
with System.Compiler_Flags;

package Hiding_Compiler_Specific_Details is
   pragma Body_Source_File
     (Condition => System.Compiler_Name = "GNAT",
      File      => "GNAT/HCSD.ada_body");
   pragma Body_Source_File
     (Condition => System.Compiler_Flags.Set ("--with-gnu-gettext"),
      File      => "GNU-Gettext/HCSD.ada_body");
   pragma Body_Source_File
     (Condition => True,
      File      => "default_implementations/HCSD.ada_body");

   ...
end Hiding_Compiler_Specific_Details;

This would limit the language handling of conditional compilation to
selecting package/unit bodies, but I think it would solve most of the
problems mentioned in this discussion, without risking the whole
preprocessing hell seen in too many C programs.

Greetings,

Jacob
-- 
�But you have to be a bit wary of a ship that collects
 snowflakes.�                                  -- Diziet Sma

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

[Marin David Condic]

That might be an answer. It at least goes a long way towards alleviating 
most of the problems. I'd have some concerns about mentioning actual 
filenames in the pragma because that can be incredibly system dependent 
and all you have to do is move some directory tree and the whole thing 
collapses. I've seen that problem show up in C and would prefer not to 
have it show up in any Ada code.

If, OTOH, it let me use some kind of symbolic name in much the same way 
as I already do with a package name, then you can at least figure that 
each compiler or platform has some mechanism for finding a body already 
and now it just does so with a different name. (On Gnat, it looks for an 
appropriately named file. On Aonix, it looks in its compilation database 
for the right unit to associate. On ??? - it uses whatever means it has 
natively.)

Maybe its something like this:

with Some_Package ;
if (some_condition) then
     for Some_Package'Body use GNAT_Some_Package ;
else
     for Some_Package'Body use AONIX_Some_Package ;
end if ;

I'm not saying it would have to be this syntax or that a pragma wouldn't 
be better. Just saying that I want the compiler to apply its normal 
interpretation rules to find "GNAT_Some_Package" and pretend that its 
name is "Some_Package".

Something like that might work.

MDC

Jacob Sparre Andersen wrote:
> 
> Would a pragma in the package specification declaring which file the
> package body should be read from depending on some compilation
> parameters (compiler, operating system, etc.) do the job?
> 
> Something like this, where the body is grabbed from the file named by
> the first "Body_Source_File" pragma with a matching condition.  If no
> "Body_Source_File" pragma has a matching condition, the compiler just
> uses its default routine for finding the source code for the package
> body.
> 
> with System;
> with System.Compiler_Flags;
> 
> package Hiding_Compiler_Specific_Details is
>    pragma Body_Source_File
>      (Condition => System.Compiler_Name = "GNAT",
>       File      => "GNAT/HCSD.ada_body");
>    pragma Body_Source_File
>      (Condition => System.Compiler_Flags.Set ("--with-gnu-gettext"),
>       File      => "GNU-Gettext/HCSD.ada_body");
>    pragma Body_Source_File
>      (Condition => True,
>       File      => "default_implementations/HCSD.ada_body");
> 
>    ...
> end Hiding_Compiler_Specific_Details;
> 
> This would limit the language handling of conditional compilation to
> selecting package/unit bodies, but I think it would solve most of the
> problems mentioned in this discussion, without risking the whole
> preprocessing hell seen in too many C programs.
> 
> Greetings,
> 
> Jacob


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

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

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> That works for some things, but it still will barf when a statement is 
> compileable for one target but not for another. I'm thinking of a case 
> where (for example) you can get one size of float for one target, but 
> for another target that size is not allowed. Hiding it in a 
> discriminated record isn't going to help if the compiler pukes all over 
> the alternative you're not going to use. 

Agreed.

The same is true if an API function xyzzy() is only available
in a Linux setting but not in an HPUX setting. If may compile,
but it will never link. To work around this, you'd then have
to link with a bunch of stub functions under HPUX, just to
make the link phase successful. This is a very ugly solution
for something that is "engineered", IMHO. It is also potentially
dangerous, unless of course you pepper all of your stubs with
"raise Program_Error" or some such.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Marin David Condic wrote:
> 
>> That works for some things, but it still will barf when a statement is 
>> compileable for one target but not for another. I'm thinking of a case 
>> where (for example) you can get one size of float for one target, but 
>> for another target that size is not allowed...
> 
> I'm sorry, but to me this is heresy.  Not that you might want to specify 
> a value for digits, I do that all the time.
> 
> But when it matters enough to specify it, it is IMPORTANT.  If a 
> particular compiler doesn't support that specification, there is no 
> point in trying to hide the problem.  The application code I wrote won't 
> run in that environment.  End of story.
> 
> Well, not exactly end of story.  There are cases where I write code that 
> uses IEEE extended precision if available, and when it is not uses IEEE 
> double with different algorithms and other methods of maintaining the 
> required precision, such as scaled (64-bit) integers.  That code is so 
> different there is no point in trying to deal with it using ifdefs or 
> whatever.  Two different matrix library bodies for the same 
> specification is the best I can do.

Ah, but when you are writing code that must interface with
3rd party software, where at one version it uses a 16-bit
value, and on other versions 32-bits etc., then you must
make your Ada code match _it_.

You look at the world as if everything conforms to your
view within Ada. I'll agree, that this is the best way to
have it.

But when writing code that must compile against what the
user has installed, whether it be a kernel release, or a
shared library or version of a DLL, you must match what
_they_have_ -- not what you'd like it to be. This is one
area where trouble sets in.

And what is even worse, you can configure your interface
with the pragma Import(), and it will compile and link
successfully. However, at _run_ time, you'll get undefined
behavior if things don't agree. This is the impedance
mismatch that you get between Ada and C (for example),
and obviously something you try to minimize.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> Ah, but when you are writing code that must interface with
> 3rd party software, where at one version it uses a 16-bit
> value, and on other versions 32-bits etc., then you must
> make your Ada code match _it_.

Hmmm.  I won't say that this is not a potentially killer problem.  Just 
that the issue has nothing to do with configuration clauses.

First let me deal with the different size issue.  I have code that 
interfaces to the two different versions of the subprogram, and code 
that checks a (local static variable) defining which interface is used. 
  My code is written with an if or case statement and multiple calls:

procedure Thick_Binding (I: in out Integer) is
begin
   if OS.Name = Solaris then
     declare
       Local: Int_16;
     begin
       Local := Int_16(I);
       C_Routine(Local);
     exception
       when Constraint_Error => ...
     end;
   elsif OS.Name = Windows then
     Different_C_Routine(I);
   end if;
end Thick_Binding;

The code is all legal Ada except that I have left out the thin C binding 
part) and the fact that there may be all sorts of trouble if C_Routine 
is called with a 16-bit value on Windows (or maybe not).

As I said, the thin bindings part may compile on the "wrong" system or 
may not.  But I deal with that problem in the thin bindings themselves.

Why all the dire words up above?  We used to call it "version skew."  If 
your project depends on components and tools from more than three 
vendors or from the same vendor with different update schedules, you can 
have the problem that there may never be a consistant set of all three 
that works together.  That is a problem outside the ability of anyone 
here to fix.  All you can do is to choose the components that your 
project DEPENDs on, and keep that list small.

In fact, you can partition the code into two separately compiled and 
mantained subsystems to mitigate the version skew effects.  One thing 
that almost jumps out at you from this is something that is almost 
normal practice in the industry.  If you have a system that depends on 
web protocols AND a database, you need to partition the two as well as 
you can.  You may or may not have separate front ends for IE and 
Netscape/Mozilla, you may use ASPs or generate HTML, etc.  But if you 
want to avoid headaches, the portion of the application that is database 
dependent (schemas, data integrity, etc.) is separate from the 
webserving front end.

> And what is even worse, you can configure your interface
> with the pragma Import(), and it will compile and link
> successfully. However, at _run_ time, you'll get undefined
> behavior if things don't agree. This is the impedance
> mismatch that you get between Ada and C (for example),
> and obviously something you try to minimize.

Exactly, I use Ada to choose the right version of the interface for the 
actual system.  But more important, as I said above, I try to partition 
the system as much as possible so that different 
subsystems/partitions/whatever can be updated separately, with only Ada 
interfaces maintained as part of the project in common.


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

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Ah, but when you are writing code that must interface with
>> 3rd party software, where at one version it uses a 16-bit
>> value, and on other versions 32-bits etc., then you must
>> make your Ada code match _it_.
> 
> Hmmm.  I won't say that this is not a potentially killer problem.  Just 
> that the issue has nothing to do with configuration clauses.

That statement is rather strong. This kind of thing is
handled in the C/C++ world all the time as a configuration
item. Now we could argue whether it should or not, but
I don't want to beat on that dead horse here.

> First let me deal with the different size issue.  I have code that 
> interfaces to the two different versions of the subprogram, and code 
> that checks a (local static variable) defining which interface is used. 
>  My code is written with an if or case statement and multiple calls:
> 
> procedure Thick_Binding (I: in out Integer) is
> begin
>   if OS.Name = Solaris then
>     declare
>       Local: Int_16;
>     begin
>       Local := Int_16(I);
>       C_Routine(Local);
>     exception
>       when Constraint_Error => ...
>     end;
>   elsif OS.Name = Windows then
>     Different_C_Routine(I);
>   end if;
> end Thick_Binding;
> 
> The code is all legal Ada except that I have left out the thin C binding 
> part) and the fact that there may be all sorts of trouble if C_Routine 
> is called with a 16-bit value on Windows (or maybe not).

This does work I suppose, if you add the different pragma Imports
to do the mappings between C_Routine and Different_C_Routine to
the same C function xyz().

But this type of a solution can explode
if the variations to the different versions of OS kernels is
added. Linux for example has gone through many revisions, and
so IMO, it is much simpler to define pid_t as a particular type,
once and for all, once you know what it should be. If you
had to code for these variances everywhere a pid_t was
involved, it would be much more ugly than the
conditional compiled solution.

But, that is _opinion_, and I expect that we'll disagree
about that.

...
> Why all the dire words up above?  We used to call it "version skew."  If 
> your project depends on components and tools from more than three 
> vendors or from the same vendor with different update schedules, you can 
> have the problem that there may never be a consistant set of all three 
> that works together.  That is a problem outside the ability of anyone 
> here to fix.  All you can do is to choose the components that your 
> project DEPENDs on, and keep that list small.

But this was my original point: if this is done successfully in C/C++
every day, then why can we not provide the same capability
(albiet in a better way) to compete at this same level?
Because of the conditional compilation bias, people want
to explain away the need for it.

Right now, it is _difficult_ to write Open Sourced projects
that compete with C/C++ ones. You might not care about that,
but it is close to my heart. So while I am running short
of energy for further discussion of this apparently futile
idea, it was my hope to spark some good ideas for some
solution(s).

> In fact, you can partition the code into two separately compiled 

Partitioning works good for smaller "works". Once the
number of variables rise, this becomes impractical.

Remember, you are trying to write something that will
compile on the most "user hosted platforms" as possible.
You cannot dictate the version of their kernel, the
version of the other software non-Ada libraries they
are using. You might dictate that your project is only
supportable with certain version restrictions, but you
want to reduce the number of those limitations to the
minimum practicable.

You will _never_ be able to compile all variations
yourself either, nor will you be able to test them
yourself. Some source code "alternatives" are safer
in the "untested" realm.

You cannot every hope to code for all of the possibilities.
As ugly as it is, C/C++ has managed to deal with this
problem sucessfully. And I am not suggesting for a
minute that we copy their approach, but they are doing
_something_ right.

Anyway, I have said my piece on this subject. I have
no energy to flog this dead horse even more. I already
know what I have to do ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:
> Robert I. Eachus wrote:

>> Hmmm.  I won't say that this is not a potentially killer problem.  
>> Just that the issue has nothing to do with configuration clauses.
> 
> 
> That statement is rather strong. This kind of thing is
> handled in the C/C++ world all the time as a configuration
> item. Now we could argue whether it should or not, but
> I don't want to beat on that dead horse here.
> 
>> First let me deal with the different size issue... 

> This does work I suppose, if you add the different pragma Imports
> to do the mappings between C_Routine and Different_C_Routine to
> the same C function xyz().

Yep, I left that part out as obvious.  I still think we are violently 
agreeing.  I have no objection to using a preprocessor with Ada when 
needed, and I expect that good compilers will provide one.

> But this type of a solution can explode
> if the variations to the different versions of OS kernels is
> added. Linux for example has gone through many revisions, and
> so IMO, it is much simpler to define pid_t as a particular type,
> once and for all, once you know what it should be. If you
> had to code for these variances everywhere a pid_t was
> involved, it would be much more ugly than the
> conditional compiled solution.
> 
> But, that is _opinion_, and I expect that we'll disagree
> about that.

No, if it makes sense to export pid_t as an abstract data type, then do 
it, and the Linux version dependencies are all in that package.  If you 
only use pid_t in one or two places, then that is a waste of effort. 
Each time we work on a project, both you and I will make hundreds of 
such decisions.  I don't think it is right to force anyone to do 
something in only one "Ada approved" way.

>> Why all the dire words up above?  We used to call it "version skew."  
>> If your project depends on components and tools from more than three 
>> vendors or from the same vendor with different update schedules, you 
>> can have the problem that there may never be a consistant set of all 
>> three that works together.  That is a problem outside the ability of 
>> anyone here to fix.  All you can do is to choose the components that 
>> your project DEPENDs on, and keep that list small.
>  
> But this was my original point: if this is done successfully in C/C++
> every day, then why can we not provide the same capability
> (albiet in a better way) to compete at this same level?
> Because of the conditional compilation bias, people want
> to explain away the need for it.

I have seen many projects killed by version skew.  I could go so far as 
to say it is the number one killer of all projects, and all open source 
projects.  As you depend on more external applications/systems the 
number of potential version skew problems goes up as N(N-1)/2.  If your 
code only depends on say, GNAT, no version skew.  (Or from another 
project's point of view, one opportunity for version skew, since your 
project may not work with all versions of GNAT.

But when you have a system that depends on the OS, the compiler, a 
graphics package, a database, and a browser, N is five.  The number of 
potential mismatches is 10.  That can be dealt with in an embedded 
development project--choose a set of versions that work together and 
never change any of them.  But for an open source project you can't do that.

And that is why bringing other standards into the language and compiler 
is a win.  Every standard that becomes explicitly part of the language 
or implicitly through support by most compilers means that the compiler 
developers deal with the version skew, and you don't have to.

> Anyway, I have said my piece on this subject. I have
> no energy to flog this dead horse even more. I already
> know what I have to do ;-)

Same here.  I can't slay the version skew monster, but I can try to 
minimize the number of cases it comes up.  Where we differ is on which 
is the best way to do that.  I want to bring as many "standard" 
interfaces inside the Ada boundary as possible, you want to standardize 
the preprocessor.  As I have said before, I have no objection to that, 
as long as you don't expect the ARG to do it.

Expecting WG9 to do it is another issue, and I don't have a strong 
opinion on that, other than a PRG or whatever should be created instead 
of assigning the problem to the ARG.  Remember that in several cases 
issues have been treated exactly this way, only to eventually end up in 
the Ada standard.  For example, there was an awful lot of work done by 
the NUMWG and the NRG on math packages for Ada.  I participated a small 
bit mostly as a liason with the ARG to explain why some particular 
proposals caused other issues in the language.  Other such groups 
include the CRG (character sets) and the work done on information 
systems that eventually ended up as Annex F and decimal types.


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

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Warren W. Gay VE3WWG wrote:
>> Robert I. Eachus wrote:
...
> I have seen many projects killed by version skew.  I could go so far as 
> to say it is the number one killer of all projects, and all open source 
> projects.  As you depend on more external applications/systems the 
> number of potential version skew problems goes up as N(N-1)/2.  If your 
> code only depends on say, GNAT, no version skew.  (Or from another 
> project's point of view, one opportunity for version skew, since your 
> project may not work with all versions of GNAT.

I won't disagree with this..

> But when you have a system that depends on the OS, the compiler, a 
> graphics package, a database, and a browser, N is five.  The number of 
> potential mismatches is 10.  That can be dealt with in an embedded 
> development project--choose a set of versions that work together and 
> never change any of them.  But for an open source project you can't do 
> that.

Which is precisely the challenge. If you want to write some
package X (some killer app), then obviously end users will
all want it to run with what they have installed. In fact,
this may in part be mandated by _other_ package requirements,
where version conflicts may force a choice of one.

So the challenge is to use the best technology (Ada) and
yet be capable of accomodating a large range of "environments".

> And that is why bringing other standards into the language and compiler 
> is a win.  Every standard that becomes explicitly part of the language 
> or implicitly through support by most compilers means that the compiler 
> developers deal with the version skew, and you don't have to.

Yes: I fully support the notion of standards. They simplify
life in so many ways.  But if I look at all the shared libraries
that are available for use under Linux, and the number of
Ada "bindings", what is immediately available to me is
rather restricted.  If I need that functionality, the onus
is now on me to solve that problem (rewrite, bind or otherwise
adapt).

I think because of the targeted end user, Open Sourced
projects have a special "need", compared to perhaps the
"typical" Ada project (whatever that is ;-)

So forgive me if my needs are slanted a bit differently ;-)

>> Anyway, I have said my piece on this subject. I have
>> no energy to flog this dead horse even more. I already
>> know what I have to do ;-)
> 
> Same here.  I can't slay the version skew monster, but I can try to 
> minimize the number of cases it comes up.  Where we differ is on which 
> is the best way to do that.  I want to bring as many "standard" 
> interfaces inside the Ada boundary as possible, you want to standardize 
> the preprocessor.  As I have said before, I have no objection to that, 
> as long as you don't expect the ARG to do it.

I never suggested that someone should just plop it into
the ARG's lap without doing homework/whatever. All I
can do is speak for myself here, and say that I just
wanted to have an open discussion on the merits of
some sort of conditional compilation.

The result of this discussion seems to suggest that most
are resisting the idea, for different reasons. So
be it. Maybe with time, resistance to the idea will fade
as more people try to address the practical problems that
Open Sourced projects face in Ada. One can hope ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[Marin David Condic]

Unfortunately, the resistance typically "fades" in the form of "Its just 
too hard for me to get my job done with Ada so I'll go switch to XYZ..." 
I think Ada tends to suffer from the mindset of "If the world doesn't 
want to fit into my software development theories, then so much the 
worse for the world." Everyone wants to avoid making Ada a messy 
hodgepodge of 'features' like one finds with C, but a little more focus 
on practical help to the average developer out there might go a long way.

MDC

Warren W. Gay VE3WWG wrote:
> 
> The result of this discussion seems to suggest that most
> are resisting the idea, for different reasons. So
> be it. Maybe with time, resistance to the idea will fade
> as more people try to address the practical problems that
> Open Sourced projects face in Ada. One can hope ;-)
> 


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

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

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Unfortunately, the resistance typically "fades" in the form of "Its just 
> too hard for me to get my job done with Ada so I'll go switch to XYZ..." 
> I think Ada tends to suffer from the mindset of "If the world doesn't 
> want to fit into my software development theories, then so much the 
> worse for the world." Everyone wants to avoid making Ada a messy 
> hodgepodge of 'features' like one finds with C, but a little more focus 
> on practical help to the average developer out there might go a long way.
> 
> MDC

I couldn't agree more ;-)

> Warren W. Gay VE3WWG wrote:
>> The result of this discussion seems to suggest that most
>> are resisting the idea, for different reasons. So
>> be it. Maybe with time, resistance to the idea will fade
>> as more people try to address the practical problems that
>> Open Sourced projects face in Ada. One can hope ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk