why ada is so unpopular ?

why ada is so unpopular ?

[Szymon Guz]

Hi,
I'd like to know how ada is popular ? And i which countries. I'm asking 
because I live in Poland and here I couldn't find any firm that use it.

szymon guz

Re: why ada is so unpopular ?

[Martin Dowie]

"Szymon Guz" <alpha@skynetSMIECI.VONorg.NOJUSZpl> wrote in message
news:bub5n8$kf5$1@atlantis.news.tpi.pl...
> Hi,
> I'd like to know how ada is popular ? And i which countries. I'm asking
> because I live in Poland and here I couldn't find any firm that use it.

Check your local military suppliers. We certainly sell Ada-based products
to Poland.

Re: why ada is so unpopular ?

[Dmytry Lavrov]

Military uses. It's answer to question why unpopular.

Re: why ada is so unpopular ?

[Szymon Guz]

Dmytry Lavrov wrote:
> Military uses. It's answer to question why unpopular.

I see. But I'd like to know if it is worth learning. I'd like to write a 
program and maybe in future earn on that and I still don't know what to 
choose ada or C++.

Re: why ada is so unpopular ?

[Adrian Knoth]

Szymon Guz <alpha@skynetSMIECI.VONorg.NOJUSZpl> wrote:

>> Military uses. It's answer to question why unpopular.
> program and maybe in future earn on that and I still don't know what to 
> choose ada or C++.

If your program solves the problem then your clients won't ask which
language do you've used.

If you're more common with C++, then use C++. If you need some
libraries only available for C++, use C++. If you think you might
get serious problems in quality when using C++, use Ada. ;)

And never forget: While the Ada-guys go out for lunch the C++-devision
is still using the debugger ;) [don't remember the exact quote]

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Kosmetik ist die Kunst aus der Not eine Jugend zu machen!

Re: why ada is so unpopular ?

[Szymon Guz]

Adrian Knoth wrote:

> Szymon Guz <alpha@skynetSMIECI.VONorg.NOJUSZpl> wrote:
> 
> 
>>>Military uses. It's answer to question why unpopular.
>>
>>program and maybe in future earn on that and I still don't know what to 
>>choose ada or C++.
> 
> 
> If your program solves the problem then your clients won't ask which
> language do you've used.
> 
> If you're more common with C++, then use C++. If you need some
> libraries only available for C++, use C++. If you think you might
> get serious problems in quality when using C++, use Ada. ;)
> 
> And never forget: While the Ada-guys go out for lunch the C++-devision
> is still using the debugger ;) [don't remember the exact quote]
> 

well.. I know that, but my problem is a little bit different. I don't 
have money for sth like Builder or Kylix or Visual but I think that my 
program really needs to operate on some windows. I don't want to write 
that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good 
for me and WinApi is terrible. I wanted to use wxWindows. It is written 
in C++, that's why I still don't know what to choose. Mix wxWindows(C++) 
with Ada or just use C++.

Re: why ada is so unpopular ?

[Luke A. Guest]

On Sun, 18 Jan 2004 10:21:16 +0100, Szymon Guz wrote:

> well.. I know that, but my problem is a little bit different. I don't 
> have money for sth like Builder or Kylix or Visual but I think that my 
> program really needs to operate on some windows. I don't want to write 
> that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good 
> for me and WinApi is terrible. I wanted to use wxWindows. It is written 
> in C++, that's why I still don't know what to choose. Mix wxWindows(C++) 
> with Ada or just use C++.

Hmm, I asked this on the wxWindows list the other day, the reply was that
the easiest way to do it would be to add an Ada backend to SWIG and use
the code from wxPython.

I can't be bothered as I haven't got the time.

Luke.

Re:was: why ada is so unpopular ?

[Ronald Dauster]

Luke A. Guest wrote:

> On Sun, 18 Jan 2004 10:21:16 +0100, Szymon Guz wrote:
> 
> 
>>well.. I know that, but my problem is a little bit different. I don't 
>>have money for sth like Builder or Kylix or Visual but I think that my 
>>program really needs to operate on some windows. I don't want to write 
>>that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good 
>>for me and WinApi is terrible. I wanted to use wxWindows. It is written 
>>in C++, that's why I still don't know what to choose. Mix wxWindows(C++) 
>>with Ada or just use C++.
> 
> 
> Hmm, I asked this on the wxWindows list the other day, the reply was that
> the easiest way to do it would be to add an Ada backend to SWIG and use
> the code from wxPython.
> 

Writing a language backend for SWIG is by no means trivial.  In
addition, the SWIG mappings for different languages have very
different capabilities.  That means, to get a clean Ada interface
the wxPython interface will need a lot of tweaking.

Re: why ada is so unpopular ?

[Ronald Dauster]

Szymon Guz wrote:

> 
> well.. I know that, but my problem is a little bit different. I don't 
> have money for sth like Builder or Kylix or Visual but I think that my 
> program really needs to operate on some windows. I don't want to write 
> that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good 

The Gtk and Qt licenses are substantially different. GTK is under
LGPL and I do not see, where this creates a problem. Qt, of course, 
either requires your application to be licensed under GPL or you have
to buy a commercial license.

> for me and WinApi is terrible. I wanted to use wxWindows. It is written 
> in C++, that's why I still don't know what to choose. Mix wxWindows(C++) 
> with Ada or just use C++.

As far as I know, there is no Ada binding to wxWindows and, given the
size and programming style of wxWindows, it will be a _lot_ of work to 
create one.

Re: why ada is so unpopular ?

[Stephane Richard]

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

To what I know too, there's no Ada binding for it....and it would probably
be equal or less work to port the whole library to Ada instead of attempting
to bind to it.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Ronald Dauster" <rpd@gido.remove_this_part.de> wrote in message
news:budvvf$9al$1@online.de...
> Szymon Guz wrote:
>
> >
> > well.. I know that, but my problem is a little bit different. I don't
> > have money for sth like Builder or Kylix or Visual but I think that my
> > program really needs to operate on some windows. I don't want to write
> > that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good
>
> The Gtk and Qt licenses are substantially different. GTK is under
> LGPL and I do not see, where this creates a problem. Qt, of course,
> either requires your application to be licensed under GPL or you have
> to buy a commercial license.
>
> > for me and WinApi is terrible. I wanted to use wxWindows. It is written
> > in C++, that's why I still don't know what to choose. Mix wxWindows(C++)
> > with Ada or just use C++.
>
> As far as I know, there is no Ada binding to wxWindows and, given the
> size and programming style of wxWindows, it will be a _lot_ of work to
> create one.
>
>
>

Re: why ada is so unpopular ?

[Szymon Guz]

Ronald Dauster wrote:

> Szymon Guz wrote:
> 
>>
>> well.. I know that, but my problem is a little bit different. I don't 
>> have money for sth like Builder or Kylix or Visual but I think that my 
>> program really needs to operate on some windows. I don't want to write 
>> that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good 
> 
> 
> The Gtk and Qt licenses are substantially different. GTK is under
> LGPL and I do not see, where this creates a problem. Qt, of course, 
> either requires your application to be licensed under GPL or you have
> to buy a commercial license.
> 

well...
I wrote that thinking that GTK is licenced under GPL, I'll check that 
because I'm not sure how it really is.
The commercial licence of Qt is too expensive for me and the GPL licence 
means that my program have to licensed under GPL and I want to avoid that.

>> for me and WinApi is terrible. I wanted to use wxWindows. It is 
>> written in C++, that's why I still don't know what to choose. Mix 
>> wxWindows(C++) with Ada or just use C++.
> 
> 
> As far as I know, there is no Ada binding to wxWindows and, given the
> size and programming style of wxWindows, it will be a _lot_ of work to 
> create one.
> 

so does that all mean that I should use C++ for that ?

Re: why ada is so unpopular ?

[Marin David Condic]

My understanding of Gtk - at least in its Ada incarnation GtkAda - was 
that it is licensed such that an application that calls it is not 
subject to the GPL license. Should one modify the library itself, those 
changes would naturally be covered by the GPL, but to simply use it as a 
GUI interface would not require you to put your app under the GPL. Am I 
wrong about this?

MDC

Szymon Guz wrote:
> 
> well...
> I wrote that thinking that GTK is licenced under GPL, I'll check that 
> because I'm not sure how it really is.
> The commercial licence of Qt is too expensive for me and the GPL licence 
> means that my program have to licensed under GPL and I want to avoid that.
> 

-- 
======================================================================
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: why ada is so unpopular ?

[Szymon Guz]

Marin David Condic wrote:
> My understanding of Gtk - at least in its Ada incarnation GtkAda - was 
> that it is licensed such that an application that calls it is not 
> subject to the GPL license. Should one modify the library itself, those 
> changes would naturally be covered by the GPL, but to simply use it as a 
> GUI interface would not require you to put your app under the GPL. Am I 
> wrong about this?
> 
> MDC
> 

yea, you're right.. I've checked that and for suer it the LGPL licence:

"GTK+ is free software and part of the GNU Project. However, the 
licensing terms for GTK+, the GNU LGPL, allow it to be used by all 
developers, including those developing proprietary software, without any 
license fees or royalties."
http://gtk.org/faq/#AEN81

Re: why ada is so unpopular ?

[Jeffrey Carter]

Szymon Guz wrote:

> yea, you're right.. I've checked that and for suer it the LGPL licence:
> 
> "GTK+ is free software and part of the GNU Project. However, the 
> licensing terms for GTK+, the GNU LGPL, allow it to be used by all 
> developers, including those developing proprietary software, without any 
> license fees or royalties."
> http://gtk.org/faq/#AEN81

GtkAda, the Ada binding to GTK+, is under the GNAT-Modified GPL (GMGPL), 
so Ada programs using GTK through GtkAda can be proprietary if the 
developer desires.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: why ada is so unpopular ?

[Preben Randhol]

On 2004-01-18, Marin David Condic <nobody@noplace.com> wrote:
> My understanding of Gtk - at least in its Ada incarnation GtkAda - was 
> that it is licensed such that an application that calls it is not 
> subject to the GPL license. Should one modify the library itself, those 
> changes would naturally be covered by the GPL, but to simply use it as a 
> GUI interface would not require you to put your app under the GPL. Am I 
> wrong about this?

Nope.

The GtkAda license:

License

This package is distributed under the GPL license, slightly modified so
that you can create proprietary software with this toolkit. The license
is actually the same as the GNAT library itself. You should also read
the Gtk license itself if you intend to do proprietary software based on
gtk and GtkAda. 


-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: why ada is so unpopular ?

[Marin David Condic]

I don't know about the Gtk license itself or why GtkAda would have to 
modify it slightly to enable the writing of proprietary software. What I 
gathered by looking at the GtkAda license at least was that one could 
develop an entirely proprietary app that made the Gtk calls through the 
GtkAda binding. If one was doing a Gtk based interface, GtkAda seems 
like the only logical choice (unless one needs Gtk capabilities that 
aren't supported in GtkAda - a problem that all such bindings have and 
an argument as to why Ada ought to have its own GUI.)

It seems the best choice for a semi-portable interface if that is the 
requirement. GPL "infection" does not seem to be an issue AFAICS.

MDC

Preben Randhol wrote:
> 
> This package is distributed under the GPL license, slightly modified so
> that you can create proprietary software with this toolkit. The license
> is actually the same as the GNAT library itself. You should also read
> the Gtk license itself if you intend to do proprietary software based on
> gtk and GtkAda. 
> 
> 


-- 
======================================================================
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: why ada is so unpopular ?

[Preben Randhol]

On 2004-01-19, Marin David Condic <nobody@noplace.com> wrote:
> I don't know about the Gtk license itself or why GtkAda would have to 
> modify it slightly to enable the writing of proprietary software.

Gtk usees LGPL
GtkAda uses GMGPL

as simple as that.

> aren't supported in GtkAda - a problem that all such bindings have and 
> an argument as to why Ada ought to have its own GUI.)

Well if you look at Java you see that the GUI isn't the same in all
platforms and IMHO the GUI is butt-ugly.

The only benifit of a special Ada GUI would be portability and not
having to use C library.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: why ada is so unpopular ?

[Marin David Condic]

Preben Randhol wrote:
> 
> Well if you look at Java you see that the GUI isn't the same in all
> platforms and IMHO the GUI is butt-ugly.
> 
Java's GUI may or may not be butt-ugly. But one thing it is: It's 
_Java's_ GUI and as it evolves, Java users pretty much get full access 
to whatever new features are added without having to wait for some 
binding to catch up.


> The only benifit of a special Ada GUI would be portability and not
> having to use C library.
> 

Portability would be one thing, but not the only thing. "Product 
Distinction" would be another: An Ada GUI could go its own way and do 
things "The Ada Way" from the programmer's perspective and might even 
provide a unique "Look & Feel" to Ada apps. (People might then actually 
*care* that their apps were done with Ada, eh?) You'd also benefit from 
the fact that (as observed above for Java) it would be _Ada's_ GUI and 
there would be no waiting around for some binding to catch up. It goes 
its own direction, develops its own look-and-feel and might start 
developing features that user's of other languages would wish *they* had 
available to them. (Hint: Switch to Ada and you can have them.)

I've tinkered with GtkAda and - while it is a good and useful thing - I 
can observe that there seem to be some features that Gtk has (under 
Gnome?) that are simply not available through GtkAda. One might want to 
use those features - but its either roll your own, wait for GtkAda to 
catch up or go use C/C++ like the entire rest of the world does. What do 
you suppose most programmers do? (Hint: Look at the relative popularity 
of C/C++ to that of Ada.)

This is always the problem that Ada has with bindings, etc. It's playing 
the "Me Too!!!!" catch-up game. The best you can hope for then is to 
come in second-place. That's why Ada ought to be developing a library of 
its own to supply a GUI and the other things that seem to come along for 
the ride with C++ or Java.

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: why ada is so unpopular ?

[Preben Randhol]

On 2004-01-19, Marin David Condic <nobody@noplace.com> wrote:
> Java's GUI may or may not be butt-ugly. But one thing it is: It's 
> _Java's_ GUI and as it evolves, Java users pretty much get full access 
> to whatever new features are added without having to wait for some 
> binding to catch up.

Well, who would be in charge of an Ada GUI and develop it actively and
not every 10-15 years ?

> Portability would be one thing, but not the only thing. "Product 
> Distinction" would be another: An Ada GUI could go its own way and do 
> things "The Ada Way" from the programmer's perspective and might even 
> provide a unique "Look & Feel" to Ada apps. (People might then actually 
> *care* that their apps were done with Ada, eh?)

Sure, but there are other things that the GUI to show that. My problem
is that there are X GUIs and Y OSes out there already.

> I've tinkered with GtkAda and - while it is a good and useful thing -
> I can observe that there seem to be some features that Gtk has (under
> Gnome?) that are simply not available through GtkAda. One might want
> to use those features - but its either roll your own, wait for GtkAda
> to catch up or go use C/C++ like the entire rest of the world does.
> What do you suppose most programmers do? (Hint: Look at the relative
> popularity of C/C++ to that of Ada.)

Well if you look at the timespan for developing Gtk you'll see it isn't
a trivial task. Making a binding is, however, much more trivial.

> This is always the problem that Ada has with bindings, etc. It's
> playing the "Me Too!!!!" catch-up game. The best you can hope for then
> is to come in second-place. That's why Ada ought to be developing a
> library of its own to supply a GUI and the other things that seem to
> come along for the ride with C++ or Java.

Yes I agree. But I want a container library +++ first.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: why ada is so unpopular ?

[Marin David Condic]

Preben Randhol wrote:
> 
> Well, who would be in charge of an Ada GUI and develop it actively and
> not every 10-15 years ?
> 
Who's in charge of Java's GUI? Do they update it only every 10 to 15 
years? Why is it that Java can do it but Ada can't? (Besides lack of 
will.) Here's the point: Java can find a way to react quickly to a 
changing world and provide developers with tools to help them do their 
jobs with greater speed. Ada can't because of lack of will to do so. Who 
wins? (Hint: the answer is Java. ;-)


> 
> Sure, but there are other things that the GUI to show that. My problem
> is that there are X GUIs and Y OSes out there already.
> 
How did Java manage to get a GUI that seems to be useful across a number 
of platforms? How did it succeed in something that looks so hopeless? 
Realistically, a GUI needs to support Windows and X-Windows (across a 
few different flavors of Unix) and it can cover 90% of the market. The 
rest? You say "Here is the GUI library in source - go make it work for 
yourself if you have to use something off-the-wall..."

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.



> 
> Well if you look at the timespan for developing Gtk you'll see it isn't
> a trivial task. Making a binding is, however, much more trivial.
> 
I never said a GUI was a trivial task. What I said was that the C 
programmers are always going to get it *first* and its going to look the 
way *C programmers* want it to look. The Ada programmers will always get 
it later and will have to struggle with the usual C metaphors. As long 
as Ada depends on bindings for this sort of thing, Ada programmers are 
sucking hind tit. Developers ask themselves "Do I want to suck hind 
tit?" Generally the answer is "No!" and they go develop in C/C++ or 
Java. So long as Ada is in that ugly position, developers will stay away 
from it in droves. They'll go where they can get the most bang for the 
buck - and for the most part, that's not Ada.


> 
> Yes I agree. But I want a container library +++ first.
> 
I have absolutely no objection to a container library. However, we 
barely see any real will to get even *that* as a standard with the 
vendors lacking the leadership to get in front of the problem and say 
"Here's the answer that everyone should start to agree on..." I suppose 
if they want to lose the compiler-wars, that's up to them. 
Realistically, developers can look at Java and (to some extent) C++ and 
see that they are getting a whole lot more leverage by way of a library 
than they do with Ada.

Your average uncommitted developer is going to see all that leverage and 
ask "So why is it I should go with some obscure, niche programming 
language that offers me less in the way of tools and I have to struggle 
by being incompatible with the whole rest of the universe? What do I get 
for this? An unquantified cost savings in maintenance ten years down the 
line and a few less bugs? My software doesn't live that long and I can 
tolerate a few bugs and what I gain in development leverage will easily 
outweigh the cost of fixing the bugs if I really need to." Its basically 
a no-brainer that is consistently demonstrated over and over again by 
the fact that developers are using languages other than Ada.

The question is simple: "Do you want Ada to be around in ten years with 
a healthy, large user base?" If you'll settle for Ada being some niche 
language used in a few antique projects (like Jovial?) then it certainly 
can have that much strength. But if you want Ada to be a "Player" in the 
language market, then Ada had better start finding a way to offer *more* 
leverage to the developer than does its competitors.

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]

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

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: 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.)

"native and/or CYGWIN" is a distinction that IMO amounts to saying
"not portable and/or portable", at least for your average C command
line tool or X11 program. How would you compile a Unix program
not using one of the Unix libraries/services provided with or for
Windows?

No preprocessor can help here, unless it magically provides
a mapping from a cooperating sequence of API calls found in the
Unix world to a cooperating sequence of APIs calls found
in the Windows world.

Or are you saying that Ada code shoud use #ifs all over the place,
neglecting language features?  IMHO, a program is portable if it
uses *abstraction*, for example a good separation a la MVC.
Abstraction is more easily expressed in a Ada than in CYGWIN's
perceived "standard" language, I think. A program is
not portable in this sense if it is a Unix command line tool and
happens to run on top of a Unix layer, or if it is an X11 program
and runs in the presence of an X server that has been ported to
Windows.

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

How could #ifs or text substitutions make any difference?
If the maintenance has to happen in my head so to speak, that is
if I have to know which #if surround what specialisation, I'd
rather stay with my language and use what is provided for
expressing a difference in a type's components say. Example

struct _gna {
  int x;
  int y;
#if defined(__S1__)
  int z;
#else
  short z;
#endif
} *S;

I don't see the advantage, even if the distinction appears
"centralised" (?).

: In other cases,
: it may mean enhancements involve maintenance of several parallel
: modules, instead of one centralized location.

Why not use language means to check modules for compliance
with the common requirements?
"display help on topic_abc_123 in a dialogue window" could well be
mapped to an abstract operation.
 

-- Georg

Re: Standard Ada Preprocessor

[Peter Richtmyer]

I have not read the entire thread. Bottom lines for me:
    1) too bad Ada does not have a preprocessor
    2) I needed one, so I created one

It has served me well for 4 years on Win2000, Solaris, HP/UX,
and LynxOS. Not elegant but very useful to me, to take code
home at night, develop/test on Win2000, then back to work with the
same source code (preparsed) to continue to develop/test on Solaris 
(or other). 

I have included some files:

   PreProcess.pm    -- the preprocessor
   PreCheck.pm      -- checks for conditionals
   and some sample DOS batch files

Use if you like, ignore otherwise           :-)
I hope it will help someone out there.

Peter

======================== PreProcess.pm ==========================
#!/usr/bin/perl -s

package Devel::PreProcess;
#IO:   use IO::File;
#use vars qw( $Conditionals $StripPreserve $StripDelete );
#use vars qw( $CMNT $CNDT $GenAda $fh $fhout $to_file $line_number );

$RETURN_CODE = 0;    # code returned to system or caller
#              0  -  OK  
#             -1  -  Command Line option error.
#             -2  -  Could not open the input file or none specified.
#             -3  -  Could not open the output file or none specified.

goto PAST_HELP;  #### We put 'HELP' up here so you can see it easily. 
:-)

PRINT_HELP:
   print <<"END_HELP";

                            Devel::PreProcess
                            v  1.7   01/25/04
            Generate conditional compile code for source code   

From a command line,

    sh> perl -s Devel/PreProcess.pm -Flags sourcefile > targetfile
  or
    sh> perl -s Devel/PreProcess.pm -Flags sourcefile  [targetfile]
    
Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile [, $targetfile]  );

DESCRIPTION

This package processes source files and outputs a modified version
according to several user-setable option flags, as detailed below.

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

Option -Conditionals 

  (True is the default)
  (Use Noconditionals to turn it off)

  If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

  The "elsif" line is optional, and there may be more than one such
line.
  The "else" line is optional.

  The provided Perl expression (expr1) is evaluated, and unless it is
true,
  everything up to the next conditional declaration is made into
special comment
  lines ("--#"). If "false" then sucessive elsif conditionals, if
preset, are
  evaluated as in any "if ... elsif  ... else ... endif" logic. 
 
  In addition, a single line may be conditional'd using the following
format:

   --#{expr3} source code first line here;
   some more source code on second line; --#{expr4}

  When these expressions (expr3 and expr4) are evaluated, when True
then the line
  will be output in the format of the second line above so that the
Ada code is
  active. When an expression is False, then the output will be in the
format of
  the second above. 

  For example, lines below were preprocessed with "-demo" on command
line:
     -- TESTING: this is demo line   --#{$demo}
     --#{!$demo}    -- TESTING: not a demo line  

  WARNING: This does not work correctly in some environments unless
there are
  spaces after the "}" and/or before the "--#" when at the end of a
line.

  The conditional functionality can be combined with Perl's -s switch,
  which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm  -Switch filter.test

  You can use any name for your switch, and the matching scalar
variable
  will be set true; the following code will only be used if you supply
  the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  If the Switch variable (entered on the command line as in the
example above)
  is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Thus, the two Ada lines of code will be compiled.
  If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Since the "if" and "elsif" conditions are Perl conditionals, they
can
  be compound conditionals. Use "&&" for AND, "||" for OR, etc. And
use
  the "!" for NOT. For example:

    --#__COND__ if ($green && ! ($apple || $pear))

  In addition, the "if ... endif" blocks can be nested.

  In reality, it is legal to have white-space between the "--#" and
the "__COND__"
  portions of a conditional statement.

  It should be noted that one of the strengths of this preprocessor is
that the
  output from one "run" can be used as the input to the next run. For
example, if
  code is being developed on two different computing environments
(e.g. home and
  work), then the code can be generated using a "-home" switch. The
code would be
  developed and tested some at home, with changes made. Then the code
would be
  run through with the "-work" switch set, and development and test
would continue
  on the same source code at work.  


Option -StripPreserve

  This option will cause all lines beginning with the Conditional
Comment prefix
  ("--#"  or its replacement using option "CMNT" described below) on
the output
  side of the logic to be replaced with a blank line in the output
stream.

Option -StripDelete

  This option will cause all lines beginning with the Conditional
Comment prefix
  ("--#"  or its replacement) on the output side of the logic to be
deleted, that
  is, not written to the output stream.

Option -CMNT="comment-string"

  This option will replace the Conditional Comment string "--#" with
the
  "comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
  conditional comment string for Ada, while  -CMNT="#*#*" could be
used to
  specify a conditional comment string when preparsing Perl source
code.

Option -CNDT="conditional-string"

  This option will replace the Conditional string "__COND__" with the 
  "conditional-string" provided. This is the string that comes after
the CMNT
  string to specify a line with "if", "elsif", "else" and "endif"
statements.

Option -LEFT="left-side"

  This option will replace the "{" as the string on the left side of a
single-line
  conditional with "left-side"

Option -RIGHT="right-side"

  This option will replace the "}" as the string on the right side of
a single-line
  conditional with "right-side"

  So, if entered " -LEFT="{{"  -RIGHT="}}" then the single-line
conditionals
  would be similar to:  --#{{expr5}}

  Care must be taken, certain special charaters need to be "escaped".
For example,
  a left paren by itself will not work (you will get a program error).
 So:
        -LEFT="("  will not work,  use  -LEFT="\("

BUGS AND CAVEATS

Option Flags -CMNT and -CNDT msy not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

END_HELP
    exit ($RETURN_CODE);
################3############## Change History
#################################

# ver    date                           description
# ---  --------  ---------------------------------------------------------------
# 1.7  01/25/04  Editorial changes only
# 1.6  07/10/03  Minor pattern-matching change
# 1.5  03/26/01  If the output is a directory, then use the same
filename
#                as the input, for writing to the output directory.
# 1.4b 11/07/00  Some clean-up, comments, deleted code, ... 
# 1.4a  9/26/00  Corrected "help"
# 1.4  09/25/00  Had to make changes to work with perl5 on HP.
# 1.3a  9/25/00  Documentation update only. No CODE changes.
# 1.3  03/06/00  Adding the single-line conditional.     --#{$test}
# 1.2  02/28/00  Clean up.
#
# 1.1 02/27/00  Commenting out the "IO::File" logic with #IO:  prefix
and
#               replacing it with old-style I/O so I can run for now
on systems
#               that do not have the IO package.
#
# 1.0 02/26/00  Original
PAST_HELP:
#
# Change the variables below to change the "syntax" of the
conditionals:
#
$CMNT         = "--#";
$CNDT         = "__COND__";
$LEFT         = "{";
$RIGHT        = "}";
#
$Conditionals = 1;   

# @psuedo_INC - directories to search for modules
#use vars qw( @psuedo_INC );

# really constants below - is there better way of making constants in
Perl 5?
#use vars qw( $EOF $ELSIF $ELSE $ENDIF );
     $EOF    = 1;
     $ELSIF  = 2;
     $ELSE   = 3;
     $ENDIF  = 4;

# %Importers - maps file inclusion keywords to their import methods
#use vars qw( %Importers );
#%Importers = (
#  'require' => '',
#  'use' => 'import',
#  'no' => 'unimport',
#);

# Devel::PreProcessor->import( 'StripPreserve', 'Conditionals', ... );
sub import {

  my $package = shift;
  foreach ( @_ ) {
    if ( m/Conditionals/i )        {
      $Conditionals = 1;
    } elsif ( m/Noconditionals/i ) {   ### PMR not tested yet
      $Conditionals = 0;               ### PMR not tested yet
    } elsif ( m/h/i )  {
      goto PRINT_HELP;
    } elsif ( m/help/i )  {
      goto PRINT_HELP;
    } elsif ( m/StripPreserve/i )  {
      $StripPreserve = 1;
    } elsif ( m/StripDelete/i )    {
      $StripDelete = 1;
    } elsif ( m/LibPath:(.*)/i )   {
      @INC = split(/\:/, $1);
    } elsif ( m/CMNT=(.*)/)        {   ### PMR not tested yet
      $CMNT = $1;                      ### PMR not tested yet
    } elsif ( m/CNDT=(.*)/)        {   ### PMR not tested yet
      $CNDT = $1;                      ### PMR not tested yet
    } elsif ( m/RIGHT=(.*)/)       {
      $RIGHT = $1;    
    } elsif ( m/LEFT=(.*)/)        {
      $LEFT = $1;       
    } else                         {
      die "unkown import";
    }
  }
}

# If we're being run from the command line, look for certain options 
# on the command line after program name.
unless ( caller ) {

  goto PRINT_HELP                          if ( $main::help ||
$main::h ) ;
  goto PRINT_HELP                          if ( $main::Help ||
$main::H ) ;
  $Conditionals    = 0                     if ( $main::Noconditionals
);
  $Conditionals  ||= $main::Conditionals;
  $StripPreserve ||= $main::StripPreserve;
  $StripDelete   ||= $main::StripDelete;
  $CMNT            = $main::CMNT           if ($main::CMNT);
  $CNDT            = $main::CNDT           if ($main::CNDT);
  $LEFT            = $main::LEFT           if ($main::LEFT);
  $RIGHT           = $main::RIGHT          if ($main::RIGHT);
  my $in_source    = shift @ARGV;       # input filename
  my $out_source   = shift @ARGV;       # output filename

  parse_file ( $in_source,  $out_source  );
} 
# ------------------------------ parse_file
------------------------------------
#
# Calling:   parse_file ( $infilename [,  $outfilename] );
#
# This routine is called by the mainline above. But it can also be
called
# by an external program.
#
sub parse_file {
    #
    # before doing much, let's make sure that any overrides to
conditional
    # matching variables are legal.
    #
## NEED to get this to work, and one for the {$test}

    if ( eval ("$line =~ /$CMNT\s*$CNDT/") )  {
        print "ERROR: You entered an illegal string for CMNT or CNDT
\n";
        print "       CMNT='$CMNT', CNDT='$CNDT' \n";
        print "       Use a backslash '\\' before certain special
characters. \n";
        die   "Try Again";
    }

    my $infilename  = shift;                       # the file to
preparse
    #IO:  $fh     = IO::File->new($infilename);          # global
inputfile handle
    open ( INPUT, $infilename )  ||  die "Unable to open input file
$infilename";
            
    my $outfilename = shift;                       # the file to write
to
    if ($outfilename) {                            # if output file
specified
        # -----------------------------------------------------------
        # if the output filename is a directory, just use it and 
        # the input filename for the complete output name.
        # -----------------------------------------------------------
        if (-d $outfilename) {
        
          @inparts = split(/[\\\/]/, $infilename);   # split into
parts separated by "\" or "/"
          $fname = $inparts[$#inparts];              # the last part
is the input file name
          $outfilename .= "/$fname"; 
        }
        
        #IO:   $fhout  = IO::File->new("> $outfilename"); #     open
output file
        open ( OUTPUT, "> $outfilename" )  ||  die  "Unable to open
output file $outfilename" ;
        $to_file = 1;                              #     "writing to
file"
    } else {                                       # else
        $to_file = 0;                              #     "writing to
stdout"
    }
    
    
    my $top_eof = parse_block ( 1, 1 );      # parse entire file 
    die "Program terminating before End-of-File - too many endif's ? "
 if ($top_eof != $EOF);
}
# ------------------------------ parse_block
-------------------------------------
#
#  $rtn = parse_block ( $level, $GenAda );
#
# Parses a "block" of code. If "$level" = 1, then this "block" is the
entire file.
# Since we always want to generate Ada for the file-level, $GenAda = 1
for level = 1.
# While parsing lines in a block, if we find a "conditional if", then
that is
# the start of an embedded block, and this routine is called
recursively to parse
# that block. 
#
# $rtn - these are the values that can be passed back from
parse_block, and they
#        tell you why we returned from the routine. If not "EOF", then
$_ has the
#        line of source code with the Conditional Commented statement,
and it has
#        not been printed yet.
#           $EOF    = 1;
#           $ELSIF  = 2;
#           $ELSE   = 3;
#           $ENDIF  = 4;
#
sub parse_block {

    my $level  = shift;   # What level of recursion (1 = outermost)
    my $GenAda = shift;   # Whether it is OK to generate Ada
                          #   out of cond-commented code

    LINE: 
    while( 1 ) {
      # 
      # Get a new line of code. If we hit eof, then return EOF.
      #
      #IO:  return ($EOF) if (! defined ($_ = $fh->getline) ); 
      return ($EOF) if (! ($_ = <INPUT>) );       
   
      $line_number ++;
      #
      # if this is a COND "endif", "elsif", or "else" then
      #    return to previous block with the code for this line
      #
      return ($ENDIF) if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*endif/i );  
      return ($ELSIF) if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*elsif\s+/i );  
      return ($ELSE)  if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*else\s+/i );
      #
      # If this line is a special conditional "if"
      #     evaluate the conditional that is on the 'if'
      #     write it if writeing cond comments
      #     call this routine recursively with level nbr and
conditional results
      #
      if ( $Conditionals && /^\s*$CMNT\s*$CNDT\s?(.*)$/i ) {
          my $conditional = $1;
          if ( $conditional =~ s/^if //i ) {

              write_if ("$_");               # write cond "if" line
"as-is" (unless stripping)
              my $This_GenAda = eval "package main;\n$conditional";
              my $We_Had_GenAda = 0;
              #
              # Why $We_Had_GenAda ?
              # If this "if block" turns out ot be a complex block
such as "if-elsif-else"
              # Then we need to keep track of whether or not we have
had one "true"
              # sub-block within it. After one true sub-block, all
others must be false.
              # Once we have had that "true" sub-block, $We_Had_GenAda
will = true.
              #
              SUB_BLOCK:
              while ( 1 ) {
                 my $eob = parse_block ( ($level + 1), ($This_GenAda
&& $GenAda && (not $We_Had_GenAda ))  );
                 $We_Had_GenAda  = ($This_GenAda && $GenAda) || 
$We_Had_GenAda;
                 die "End-of-File reached while in a Conditional
Compile block" if ($eof);
                 write_if ("$_"); # write line that ended block /
sub-block
                 
                 next LINE       if ($eob == $ENDIF);  # done with
entire block

                 if ($eob == $ELSE) {
                     $This_GenAda = ! $We_Had_GenAda;    # set up this
block GenAda
                     #$This_GenAda = not $We_Had_GenAda;    # set up
this block GenAda
                     next SUB_BLOCK;                       # parse the
"else" subblock
                 }
                 die "Program error - bad EOB" if ($eob != $ELSIF);
                 
                 # Parse the "condition" part out of line and evaluate
it true / false
                 /^\s*$CMNT\s*$CNDT\s?elsif(.*)$/i;
                 $conditional = "$1";
                 $This_GenAda = eval "package main;\n$conditional";
                 # will loop back to SUB_BLOCK and parse this "elsif"
sub-block.
              }      
          } else {
              print "$_";
              die "conditional above is out of place";
          }
      }  
      # look for a single line conditional.
      local ($SCOND) = "";
      local ($SLINE) = "";
 
      if ( /^(\s*$CMNT\s*$LEFT.*$RIGHT)(.*)$/ ) {
         #print "TEMP found $1 in --#\${LEFT}xxxx\$RIGHT} line and $2
after it\n";
         $SCOND = $1;
         $SLINE = $2;
      }
      if ( /^(.*)($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) {
         #print "TEMP found '$1' before '$2' \n"; 
         $SCOND = $2;
         chomp($SCOND);
         $SLINE = $1;
      }
      if (  $SCOND  )  {
          $SCOND =~ /$CMNT\s*$LEFT(.*)$RIGHT/;
          if ( eval "package main;\n$1" )  {
              &write_if ("$SLINE $SCOND\n");          
          } else {
              &write_if ("$SCOND $SLINE\n");
          }
          next LINE;
      }
      #
      # If we are in the outer level (not within a COND block), then
we do not even
      # have to look at the line of code. Just write it (if..)
      #
      if ($level == 1) {
          #
          # We could make a check here for a "--$COMM" line. That
would be a straggler,
          # outside of a conditional, so we could alert the officials
about it.
          # 
          write_if ("$_");    # local routine to write if OK to write
          next LINE;
      }
      #
      # $GenAda can only be true if we are processing conditionals and
we found
      # a conditional that evaluated True.
      #
      ##print "                            \$GenAda = $GenAda \n";
      if ($GenAda)   {
          #          
          # This line must NOT be a COND comment. If it is now, 
          # then remove the COND part.
          #
          if ( /^\s*$CMNT(.*)$/i ) {
              write_if ("$1\n");
          } else {
              write_if ("$_");
          }                 
          next LINE;
      } 
      #
      # If we are processing conditionals and this line should be
commented out,
      # then make sure that it is a conditional comment before calling
write routine.
      # 
      #if ($Conditionals && not $GenAda) {
      if ($Conditionals && ! $GenAda) {
          if ( /^\s*$CMNT/ ) {
              write_if ("$_");
          } else {
              write_if ("$CMNT$_");
          } 
          next LINE;                
      }         
      die "We found a condition that this humble programmer did not
anticipate.";
  } # end loop  

}  # end sub parse_block

# ---------------------------------------------------------------------------------------
#sub write_if ($line);
#
#  write the line unless the "StripPreserve" or "StripDelete" flag is
set
#  and this is a conditional comment. 
#
sub write_if {

   $_ = shift;                            #
   if ( /^\s*$CMNT/ ) {                   # if a cond commment
      return if ($StripDelete);           #     delete the line if we
are strip-deleting.
      if ($StripPreserve) {               #     if strip-replacing
with blank line
          write_line ("\n");              #         substitute a blank
line
          return;                         #
      }                                   #
   }
   # If this is NOT a comment, but has the "one-line" conditional at
the right end
   # and we are stripping comments, Then we want to keep the line
except for the
   # conditional at the right end.
   #   
   if ( /^(.*) ($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) {
       if ( $StripDelete  ||  $StripPreserve ) {
          write_line ("$1\n");
          return;
       }
   }
   write_line ("$_");                     # write the line as-is
}
# ---------------------------------------------------------------------------------------
#
# Write it to stdout or the file (if specified).
#
sub write_line {

    my $line = shift;
    if ( $to_file ) {
       #IO:  $fhout->print ($line);
       print OUTPUT "$line";
    } else {
       print "$line";
    }
}
#-----------

1;

__END__

=head1 NAME

Devel::PreProcess -  Source code preprocessing.

=head1 SYNOPSIS

From a command line,

    sh> perl Devel/PreProcess.pm -Flags sourcefile > targetfile
  or
    sh> perl Devel/PreProcess.pm -Flags sourcefile  [targetfile]

Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile [, $targetfile]  );

=head1 DESCRIPTION

This package processes source files and outputs a modified version
according to several user-setable option flags, as detailed below.

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

=over 4

=item Conditionals 

(True is the default)
(Use Noconditionals to turn it off)

If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

The "elsif" line is optional, and there may be more than one such
line.
The "else" line is optional.

The provided Perl expression (expr1) is evaluated, and unless it is
true,
everything up to the next conditional declaration is made into comment
lines. If "false" then sucessive elsif conditionals, if preset, are
evaluated
as in any "if ... elsif  ... else ... endif" logic. 

The conditional functionality can be combined with Perl's C<-s>
switch,
which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm -Conditionals -Switch filter.test

You can use any name for your switch, and the matching scalar variable
will be set true; the following code will only be used if you supply
the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

If the Switch variable is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Thus, the two Ada lines of code will be compiled.
If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Since the "if" and "elsif" conditions are Perl conditionals, they can 
be a compound conditional. Use "&&" for AND, "||" for OR, etc. For
example:

    --#__COND__ if ($green && ($apple || $pear))

In addition, the "if ... endif" blocks can be nested.

In reality, it is legal to have white-space between the "--#" and the
"__COND__"
portions of a conditional statement.

=item StripPreserve

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
replaced with
a blank line in the output stream.

=item StripDelete

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
deleted, that
is, not written to the output stream.

=item CMNT="comment-string"

This option will replace the Conditional Comment string "--#" with the
"comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
conditional comment string for Ada, while  -CMNT="#*#*" could be used
to
specify a conditional comment string when preparsing Perl source code.

=item CNDT="conditional-string"

This option will replace the Conditional string "__COND__" with the 
"conditional-string" provided. This is the string that comes after the
CMNT
string to specify a line with "if", "elsif", "else" and "endif"
statements.


=back

=head1 EXAMPLES


=head1 BUGS AND CAVEATS

Option Flags -CMNT and -CNDT may not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

=head1 PREREQUISITES

This package should run on standard Perl 5 installations, but 
may not run on earliest Perl 5 releases or incomplete installations.

=head1 STATUS AND SUPPORT

This release of Devel::PreProcess is intended primarily for limited
private
use. Not all options (especially "caller" options) have been tested.

=head1 AUTHORS AND COPYRIGHT

This program was adapted from a Devel::PreProcessor.pm from 
Evolution Online Systems, Inc. E<lt>www.evolution.comE<gt>, which had
Copyright restrictions on it. It is felt that the changes to it are 
significant enought that the Copyright is not applicable.
Nevertheless,
credit is given to them for the basic program structure. Also, an
email from them said it is OK to use it in this way. 

The modifications were made by Peter Richtmyer, RISYS, Portsmouth, RI.
Others may use and modify it, just don't sell it or package it for
sale.

============================= PreCheck.pm
===============================
#!/usr/local/bin/perl -s

package Devel::PreCheck;
#IO:   use IO::File;
#use vars qw( $Conditionals $StripPreserve $StripDelete );
#use vars qw( $CMNT $CNDT $GenAda $fh $fhout $to_file $line_number );

$RETURN_CODE = 0;    # code returned to system or caller
#              0  -  OK  
#             -1  -  Command Line option error.
#             -2  -  Could not open the input file or none specified.
#             -3  -  Could not open the output file or none specified.

goto PAST_HELP;  #### We put 'HELP' up here so you can see it easily. 
:-)

PRINT_HELP:
   print <<"END_HELP";

                            Devel::PreCheck
                                 v  2.1
              Check for conditional compile code in source code   

From a command line,

    sh> perl -s Devel/PreCheck.pm -Flags sourcefile 
    
Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile );

DESCRIPTION

This package processes source files and outputs a 
   0 - no conditional statements found
   1 - found 

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

Option -Conditionals 

  (True is the default)
  (Use Noconditionals to turn it off)

  If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

  The "elsif" line is optional, and there may be more than one such
line.
  The "else" line is optional.

  The provided Perl expression (expr1) is evaluated, and unless it is
true,
  everything up to the next conditional declaration is made into
special comment
  lines ("--#"). If "false" then sucessive elsif conditionals, if
preset, are
  evaluated as in any "if ... elsif  ... else ... endif" logic. 
 
  In addition, a single line may be conditional'd using the following
format:

   --#{expr3} source code first line here;
   some more source code on second line; --#{expr4}

  When these expressions (expr3 and expr4) are evaluated, when True
then the line
  will be output in the format of the second line above so that the
Ada code is
  active. When an expression is False, then the output will be in the
format of
  the second above. 

  For example, lines below were preprocessed with "-demo" on command
line:
     -- TESTING: this is demo line   --#{$demo}
     --#{!$demo}    -- TESTING: not a demo line  

  WARNING: This does not work correctly in some environments unless
there are
  spaces after the "}" and/or before the "--#" when at the end of a
line.

  The conditional functionality can be combined with Perl's -s switch,
  which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm  -Switch filter.test

  You can use any name for your switch, and the matching scalar
variable
  will be set true; the following code will only be used if you supply
  the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  If the Switch variable (entered on the command line as in the
example above)
  is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Thus, the two Ada lines of code will be compiled.
  If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Since the "if" and "elsif" conditions are Perl conditionals, they
can
  be compound conditionals. Use "&&" for AND, "||" for OR, etc. And
use
  the "!" for NOT. For example:

    --#__COND__ if ($green && ! ($apple || $pear))

  In addition, the "if ... endif" blocks can be nested.

  In reality, it is legal to have white-space between the "--#" and
the "__COND__"
  portions of a conditional statement.

  It should be noted that one of the strengths of this preprocessor is
that the
  output from one "run" can be used as the input to the next run. For
example, if
  code is being developed on two different computing environments
(e.g. home and
  work), then the code can be generated using a "-home" switch. The
code would be
  developed and tested some at home, with changes made. Then the code
would be
  run through with the "-work" switch set, and development and test
would continue
  on the same source code at work.  


Option -CMNT="comment-string"

  This option will replace the Conditional Comment string "--#" with
the
  "comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
  conditional comment string for Ada, while  -CMNT="#*#*" could be
used to
  specify a conditional comment string when preparsing Perl source
code.

Option -CNDT="conditional-string"

  This option will replace the Conditional string "__COND__" with the 
  "conditional-string" provided. This is the string that comes after
the CMNT
  string to specify a line with "if", "elsif", "else" and "endif"
statements.

Option -LEFT="left-side"

  This option will replace the "{" as the string on the left side of a
single-line
  conditional with "left-side"

Option -RIGHT="right-side"

  This option will replace the "}" as the string on the right side of
a single-line
  conditional with "right-side"

  So, if entered " -LEFT="{{"  -RIGHT="}}" then the single-line
conditionals
  would be similar to:  --#{{expr5}}

  Care must be taken, certain special charaters need to be "escaped".
For example,
  a left paren by itself will not work (you will get a program error).
 So:
        -LEFT="("  will not work,  use  -LEFT="\("

BUGS AND CAVEATS

Option Flags -CMNT and -CNDT msy not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

END_HELP
    exit ($RETURN_CODE);
################3############## Change History
#################################

# ver    date                           description
# ---  --------  -----------------------------------------------------------------
# 1.0 03/26/00  Original, copied from PreProcess.pm
# 2.0 06/08/03  In addition to looking for a string like "--#__COND__"
#               at the beginning of a line, must also look for a 
#               string like "--#{...}" at the beginning or end of a
line.
# 2.1 07/10/03  Minor pattern-matching change

PAST_HELP:
#
# Change the variables below to change the "syntax" of the
conditionals:
#
$CMNT         = "--#";
$CNDT         = "__COND__";
$LEFT         = "{";
$RIGHT        = "}";
#
$Conditionals = 1;   

# @psuedo_INC - directories to search for modules
#use vars qw( @psuedo_INC );

# %Importers - maps file inclusion keywords to their import methods
#use vars qw( %Importers );
#%Importers = (
#  'require' => '',
#  'use' => 'import',
#  'no' => 'unimport',
#);

# Devel::PreProcessor->import( 'StripPreserve', 'Conditionals', ... );
sub import {

  my $package = shift;
  foreach ( @_ ) {
    if ( m/Conditionals/i )        {
      $Conditionals = 1;
    } elsif ( m/Noconditionals/i ) {   ### PMR not tested yet
      $Conditionals = 0;               ### PMR not tested yet
    } elsif ( m/h/i )  {
      goto PRINT_HELP;
    } elsif ( m/help/i )  {
      goto PRINT_HELP;
    } elsif ( m/LibPath:(.*)/i )   {
      @INC = split(/\:/, $1);
    } elsif ( m/CMNT=(.*)/)        {   ### PMR not tested yet
      $CMNT = $1;                      ### PMR not tested yet
    } elsif ( m/CNDT=(.*)/)        {   ### PMR not tested yet
      $CNDT = $1;                      ### PMR not tested yet
    } elsif ( m/RIGHT=(.*)/)       {
      $RIGHT = $1;    
    } elsif ( m/LEFT=(.*)/)        {
      $LEFT = $1;       
    } else                         {
      die "unkown import";
    }
  }
}

# If we're being run from the command line, look for certain options 
# on the command line after program name.
unless ( caller ) {

  goto PRINT_HELP                          if ( $main::help ||
$main::h ) ;
  goto PRINT_HELP                          if ( $main::Help ||
$main::H ) ;
  $Conditionals    = 0                     if ( $main::Noconditionals
);
  $Conditionals  ||= $main::Conditionals;
  $CMNT            = $main::CMNT           if ($main::CMNT);
  $CNDT            = $main::CNDT           if ($main::CNDT);
  $LEFT            = $main::LEFT           if ($main::LEFT);
  $RIGHT           = $main::RIGHT          if ($main::RIGHT);
  my $in_source    = shift @ARGV;       # input filename

  parse_file ( $in_source  );
} 
# ------------------------------ parse_file
------------------------------------
#
# Calling:   parse_file ( $infilename );
#
# This routine is called by the mainline above. But it can also be
called
# by an external program.
#
sub parse_file {
    #
    # before doing much, let's make sure that any overrides to
conditional
    # matching variables are legal.
    #
## NEED to get this to work, and one for the {$test}

    if ( eval ("$line =~ /$CMNT\s*$CNDT/") )  {
        print "ERROR: You entered an illegal string for CMNT or CNDT
\n";
        print "       CMNT='$CMNT', CNDT='$CNDT' \n";
        print "       Use a backslash '\\' before certain special
characters. \n";
        die   "Try Again";
    }

    my $infilename  = shift;                       # the file to
preparse
    #IO:  $fh     = IO::File->new($infilename);          # global
inputfile handle
    #print ("open ( INPUT, $infilename ) \n"); 
    open ( INPUT, $infilename )  ||  die "Unable to open input file
$infilename";
            

    while (<INPUT>) {
      
      # print "looking for $CMNT$CNDT in: $_\n";
      
      if (  /^\s*$CMNT\s*$CNDT/i ) {
         print "Found conditional in: file $infilename \n";
         close (INPUT);
         exit 1;          # found conditional 
      } 
  
      # print "looking for $CMNT$LEFT...$RIGHT at beginning of: $_\n";
    
      if ( /^(\s*$CMNT\s*$LEFT.*$RIGHT)(.*)$/ ) {
         print "Found conditional in: file $infilename \n";
         close (INPUT);
         exit 1;          # found conditional 
      } 

        print "looking for $CMNT$LEFT...$RIGHT at end of: $_\n";

      if ( /^(.*)($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) {
         print "Found conditional in: file $infilename \n";
         close (INPUT);
         exit 1;          # found conditional 
      } 

    }
    print "DID NOT FIND CONDITIONAL in FILE: $infilename \n";
    close (INPUT);
    exit 0;               # no conditionals found
}
#-----------

1;

__END__

=head1 NAME

Devel::PreProcess -  Source code preprocessing.

=head1 SYNOPSIS

From a command line,

    sh> perl Devel/PreProcess.pm -Flags sourcefile > targetfile
  or
    sh> perl Devel/PreProcess.pm -Flags sourcefile  [targetfile]

Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile [, $targetfile]  );

=head1 DESCRIPTION

This package processes source files and outputs a modified version
according to several user-setable option flags, as detailed below.

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

=over 4

=item Conditionals 

(True is the default)
(Use Noconditionals to turn it off)

If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

The "elsif" line is optional, and there may be more than one such
line.
The "else" line is optional.

The provided Perl expression (expr1) is evaluated, and unless it is
true,
everything up to the next conditional declaration is made into comment
lines. If "false" then sucessive elsif conditionals, if preset, are
evaluated
as in any "if ... elsif  ... else ... endif" logic. 

The conditional functionality can be combined with Perl's C<-s>
switch,
which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm -Conditionals -Switch filter.test

You can use any name for your switch, and the matching scalar variable
will be set true; the following code will only be used if you supply
the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

If the Switch variable is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Thus, the two Ada lines of code will be compiled.
If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Since the "if" and "elsif" conditions are Perl conditionals, they can 
be a compound conditional. Use "&&" for AND, "||" for OR, etc. For
example:

    --#__COND__ if ($green && ($apple || $pear))

In addition, the "if ... endif" blocks can be nested.

In reality, it is legal to have white-space between the "--#" and the
"__COND__"
portions of a conditional statement.

=item StripPreserve

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
replaced with
a blank line in the output stream.

=item StripDelete

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
deleted, that
is, not written to the output stream.

=item CMNT="comment-string"

This option will replace the Conditional Comment string "--#" with the
"comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
conditional comment string for Ada, while  -CMNT="#*#*" could be used
to
specify a conditional comment string when preparsing Perl source code.

=item CNDT="conditional-string"

This option will replace the Conditional string "__COND__" with the 
"conditional-string" provided. This is the string that comes after the
CMNT
string to specify a line with "if", "elsif", "else" and "endif"
statements.


=back

=head1 EXAMPLES


=head1 BUGS AND CAVEATS

Option Flags -CMNT and -CNDT msy not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

=head1 PREREQUISITES

This package should run on standard Perl 5 installations, but 
may not run on earliest Perl 5 releases or incomplete installations.

=head1 STATUS AND SUPPORT

This release of Devel::PreProcess is intended primarily for limited
private
use. Not all options (especially "caller" options) have been tested.


=head1 AUTHORS AND COPYRIGHT

This program was adapted from a Devel::PreProcessor.pm from 
Evolution Online Systems, Inc. E<lt>www.evolution.comE<gt>, which had
Copyright restrictions on it. It is felt that the changes to it are 
significant enought that the Copyright is not applicable.
Nevertheless,
credit is given to them for the basic program structure. Also, an
email from them said it is OK to use it in this way. 

The modifications were made by Peter Richtmyer, RISYS, Portsmouth, RI.
Others may use and modify it, just don't sell it or package it for
sale.

============================ BAT_PREP.BAT
================================
 echo off
 REM   BAT_PREP.BAT
 REM   03/26/01
 REM   04/12/01 added .txt files for help template
 REM   11/07/01 added logic to create output dir if needed
 REM   06/08/03 chgd ".scr" to ".script"
 REM
 REM   need to call this with at least two parameters:
 REM
 REM     1 = sending directory
 REM     2 = receiving directory
 REM     3 - 9 = (optional) the Perl variable names for preprocessing.
 REM
 REM  for example:
 REM
 REM     bat_prep  D:\my_dir  D:\my_dir2  -demo   -gnat
 REM 
 REM   remember we do not WANT TO COPY .BAT FILES
 
if not exist %1 echo #### ERROR in BAT_PREP.BAT, the Sending dir does
not exist: %1 ####
if not exist %1 pause
call CREATE_DIR_IF_NEEDED %2

echo   ABOUT TO COPY ALL .ada, .adb, .ads, .script, .txt gnat.* FROM
%1 TO %2  CTL-C to QUIT
pause

 rem the options like "-demo" must have a dash before them
 rem from %1 to %2 with booleans: %3 %4 %5 %6 %7 %8 %9

 rem ARE YOU SURE?  BACK UP FIRST?????


 rem echo about to copy all %1\*.txt   to   %2
 rem pause
 copy %1\*.txt                 %2 

 rem echo about to copy all %1\*.script   to   %2
 rem pause
 copy %1\*.script              %2  

 rem echo about to copy all %1\gnat.*   to   %2
 rem pause
 copy %1\gnat.*                %2 

 PAUSE                    

 for %%f in (%1\*.ada %1\*.ads %1\*.adb) do call bat_chk_convert.bat
%%f  %2   %3 %4 %5 %6 %7 %8 %9

 pause                                  -- check results

========================= BAT_CHK_CONVERT.BAT
==========================
 echo off
 REM   BAT_CHK_CONVERT.BAT
 REM   03/26/01
 REM
 REM   need to call this with at least two parameters:
 REM
 REM     1 = sending directory
 REM     2 = receiving directory
 REM     3 - 9 = (optional) the Perl variable names for preprocessing.
 REM
 REM  for example:
 REM
 REM     bat_chk_convert  D:\my_dir  D:\my_dir2  -demo   -gnat
 REM 
 rem the options like "-demo" must have a dash before them
 rem from %1 to %2 with booleans: %3 %4 %5 %6 %7 %8 %9
 rem Note that we only want to preprocess if we have to.
 rem otherwise we use a "copy" command so the file date does not
change.
 
 rem pause
  
  rem first see if there are any conditionals ("--#") in the file

  rem echo    calling PreCheck.pm %3 %4 %5 %6 %7 %8 %9   %1
  perl -s C:\perl\bin\PreCheck.pm %3 %4 %5 %6 %7 %8 %9   %1    

  if not errorlevel 1 goto copyfile

 rem  echo           PreProcess.pm  %3 %4 %5 %6 %7 %8 %9   %1     %2

 perl -s C:\perl\bin\PreProcess.pm  %3 %4 %5 %6 %7 %8 %9   %1     %2

 goto end

:copyfile 

 copy %1  %2  

:end

rem pause
======================= CREATE_DIR_IF_NEEDED.BAT
=======================
echo off
 REM   CREATE_DIR_IF_NEEDED.BAT
 REM
 REM   11/07/01 new
 REM
 REM   need to call this with parameters
 REM
 REM     1 = directory to check, and add if it does not exist
 REM
 REM  for example:
 REM
 REM    call  CREATE_DIR_IF_NEEDED  D:\my_dir  
 REM 
 
if not exist %1 echo Creating the output dir: %1
if not exist %1 mkdir %1
if not exist %1 echo #### ERROR: could not create output dir: %1 ####
if not exist %1 pause

Re: Standard Ada Preprocessor

[tmoran]

>Lines: 1496
  While appreciating the offer of the program, I really do prefer not
to have exceedingly large ( > 100 line, say) newsgroup messages.  Better
to just post a link to a web site.

Re: Standard Ada Preprocessor

[Marin David Condic]

Well, there you go. Ada doesn't provide a "standard" way to do it - 
perhaps out of some sense of technical purity. People still find it an 
attractive way to fix the problems they have maintaining things for two 
or more platforms. What do they do? They home-grow an answer that solves 
their problem (while not being portable) - or they go use a language 
that gives them what they want.

MDC


Peter Richtmyer wrote:
> I have not read the entire thread. Bottom lines for me:
>     1) too bad Ada does not have a preprocessor
>     2) I needed one, so I created one
> 
> It has served me well for 4 years on Win2000, Solaris, HP/UX,
> and LynxOS. Not elegant but very useful to me, to take code
> home at night, develop/test on Win2000, then back to work with the
> same source code (preparsed) to continue to develop/test on Solaris 
> (or other). 
> 

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

[Mark]

late to the party and jumping in the middle of discussion [sorry]
  please see:

 http://www.digitalmars.com/d/index.html
   look for The C Preprocessor Versus D

  for a different approach to getting rid of the preprocessor but
maintaining some of the primary usage.

Re: Standard Ada Preprocessor

[Frank J. Lhota]

"Mark" <prenom_nomus@yahoo.com> wrote in message
news:c5b88987.0402010709.1d27a8a3@posting.google.com...
> late to the party and jumping in the middle of discussion [sorry]
>   please see:
>
>  http://www.digitalmars.com/d/index.html
>    look for The C Preprocessor Versus D
>
>   for a different approach to getting rid of the preprocessor but
> maintaining some of the primary usage.

It's interesting to see the Ada concepts that have made it into D, including
the use of in / out / in out parameter modes.

Re: Standard Ada Preprocessor

[Martin Krischik]

Frank J. Lhota wrote:

> "Mark" <prenom_nomus@yahoo.com> wrote in message
> news:c5b88987.0402010709.1d27a8a3@posting.google.com...
>> late to the party and jumping in the middle of discussion [sorry]
>>   please see:
>>
>>  http://www.digitalmars.com/d/index.html
>>    look for The C Preprocessor Versus D
>>
>>   for a different approach to getting rid of the preprocessor but
>> maintaining some of the primary usage.
> 
> It's interesting to see the Ada concepts that have made it into D,
> including the use of in / out / in out parameter modes.

But the sad point is that D hasn't got ranges.

With Regards


Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Ada Preprocessor

[Frank J. Lhota]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1113821.JAX30lkfSv@linux1.krischik.com...
> But the sad point is that D hasn't got ranges.

... but it does have array slices.

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

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: 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.

But then this is not an issue of program portability, but of
compiler differences or compiler bugs. To some extent Source Code Versioning
software and branches can help.

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

I'd prefer a conditional build process. IMHO, there should be a
declarative language for build processes, integrated with one
or more "source languages". ACE files (Eiffel), Project files (Ada),
VCS integration/awareness etc.
 
: Naturally that has risks and can lead to all sorts of abuse.

If you keep the #ifs out of the code, and instead declare the
target/compiler dependences in documents of their own right,
to be processed by a configuration preprocessor, that risk isn't
there, I think.


-- Georg

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]

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

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: 
: 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.

(Interestingly, Controlled types disallow overlays ;-)

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

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

>   #if sizeof(int) == 16

Ah, yes, 128-bit integers. Of course, this is not an issue in Ada, since 
we declare appropriate numeric types.

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

As someone who has faced the issue and never used a preprocessor, but 
has had to read code that does, I find a good design that hides the 
dependencies to be far more readable. Eachus has also faced the issue 
without using a preprocessor, with similar results. As the ARM says, Ada 
emphasizes "program readability over ease of writing". Preprocessors do 
the opposite.

Preprocessors are a coder's solution; information hiding is a software 
engineer's solution. Perhaps to the question, "Do you like debugging?" 
which is very accurate at distinguishing coders from software engineers, 
we should add, "Do you like preprocessors?"

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:
> Warren W. Gay VE3WWG wrote:
> 
>>   #if sizeof(int) == 16
> 
> Ah, yes, 128-bit integers. Of course, this is not an issue in Ada, since 
> we declare appropriate numeric types.

Oops! Substitute 4 or 8 for 16!

>> 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 ;-)
> 
> As someone who has faced the issue and never used a preprocessor, but 
> has had to read code that does, I find a good design that hides the 
> dependencies to be far more readable. 

Of course this is to be "preferred".

> Eachus has also faced the issue 
> without using a preprocessor, with similar results. As the ARM says, Ada 
> emphasizes "program readability over ease of writing". Preprocessors do 
> the opposite.

And two people's experience does not equate to
"everyone's" ;-)

> Preprocessors are a coder's solution; information hiding is a software 
> engineer's solution. Perhaps to the question, "Do you like debugging?" 
> which is very accurate at distinguishing coders from software engineers, 
> we should add, "Do you like preprocessors?"

As said before, I prefer a portable platform neutral code
as much as the next guy. But when you start writing bindings
and such that must bind to _many_ different situations,
this simply becomes impractical.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> As said before, I prefer a portable platform neutral code
> as much as the next guy. But when you start writing bindings
> and such that must bind to _many_ different situations,
> this simply becomes impractical.

I feel here like I am being castigated for something I have never said. 
  (No, I am not saying Warren is attacking me, just that I have the 
feeling that I am not getting my point across.)

The problem is that there is an underlying philosophical difference, and 
until and unless you accept the "Ada" philosophy you will be 
uncomfortable programming in Ada.  Once you "get it" Ada becomes as 
comfortable as well broken-in shoe.  There are still some minor lumps 
and bumps--but you don't notice them.

For a second assume that there are things that do require a preprocessor 
to do in Ada.  Now look at the long debate here, from the point of view 
that one group uses preprocessor directives in with clauses and the 
public part of packages, while I argue that this is poor programming 
practice and that all preprocessor directives belong in unit bodies 
where possible, and as few such bodies as possible.

And actually that IS the way I feel.  With one minor exception.  When 
you do the necessary work to collect all of the pre-processor decorated 
code in one spot, surprise!  There isn't any left.

But there is really a trick to this, and it is important to understand. 
  In the military the problem is known as micro-management.  Problems 
and issues should be addressed at the right level, without solutions 
imposed from above which may not be appropriate in a particular situation.

In Ada where this often comes up is in representation clauses.  You 
either tell the compiler to "do it right" with alignment directives, or 
lay things out bit-by-bit with rep clauses.  If there is an 
implementation INdependent format you have to follow, sometimes because 
you are interfacing directly to some special-purpose hardware.  Fine, 
use static layouts.  But these are, by their nature not compiler 
dependent in any way.  The hardware you interface with, or the other 
computer system you interface with, or whatever, specifies the layout. 
If some compiler can't support those rep clauses, it is not time for 
preprocessor directives, it is time to either fix the compiler or get a 
new one.  The bits MUST look exactly like that, it is not an option.

The second case is where you want the bits laid out a certain way for 
efficiency.  Fine, no problem...and no rep clause required or needed. 
That is the compiler's job.  You may use alignment clauses and specify 
that some components are aliased, but the compiler will take all that 
into account when it lays out the record.  If two compilers do it 
differently on different hardware because, say, Integer is a different 
size?  Not a problem.  If you needed the records to be identical on 
different hardware, you would have specified things that way.

So as far as I am concerned, the case of rep specs that compile on one 
compiler and not on another is almost uninteresting.  If you care, it is 
a big problem.  But it has to be fixed by fixing (or replacing) one 
compiler.  A pre-processor CAN'T help.  If you are trying to use 
pre-processor directives to force efficient layouts on each different 
platform, you are micro-managing.  Let each compiler choose the layout 
it thinks is best.

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> As said before, I prefer a portable platform neutral code
>> as much as the next guy. But when you start writing bindings
>> and such that must bind to _many_ different situations,
>> this simply becomes impractical.
> 
> I feel here like I am being castigated for something I have never said. 
>  (No, I am not saying Warren is attacking me, just that I have the 
> feeling that I am not getting my point across.)

It could be argued that MDC, lurkers and I are not getting
our point across ;-)

> The problem is that there is an underlying philosophical difference, and 
> until and unless you accept the "Ada" philosophy you will be 
> uncomfortable programming in Ada.  Once you "get it" Ada becomes as 
> comfortable as well broken-in shoe.  There are still some minor lumps 
> and bumps--but you don't notice them.

The "Ada phylosophy" works until you start interfacing to many
foreign components (normally C ones) that cannot be relied upon
to be the same. You cannot even rely on the same API to be
available, in some cases. This is where things get real ugly.

The practical side of many bindings, requires me to deal
with portability issues in a "C wrapper". This may not always
be entirely possible to avoid because of C macros, but I
would like to put more code into Ada than into C. But I
can't, because Ada cannot deal with the portability issues.
That is, unless I resort to processes outside of the language
(like gnatprep and code generation).

I would just like people to look at some of the "practical"
issues without resorting to quoting "ivory tower" notions.
Again, all of this would be _optional_ anyway. The military
can outlaw it for all I care, but for general purpose
computing, it needs to be addressed.

> For a second assume that there are things that do require a preprocessor 
> to do in Ada.  Now look at the long debate here, from the point of view 
> that one group uses preprocessor directives in with clauses and the 
> public part of packages, while I argue that this is poor programming 
> practice and that all preprocessor directives belong in unit bodies 
> where possible, and as few such bodies as possible.

I am not against any of these techniques. What I am against
is the notion that "no, we don't do it that way because it
might get abused". There is a need for it in the GP case,
perhaps not in the military and embedded case. But if you're
only going to do the later, than why add an Annex to deal
with COBOL interfaces and features?

> And actually that IS the way I feel.  With one minor exception.  When 
> you do the necessary work to collect all of the pre-processor decorated 
> code in one spot, surprise!  There isn't any left.

Point to some major open sourced work, where it can be
compiled and installed on Win32, Linux and many flavours
of *NIX, and I might believe this. Why is it that large
portions of Florist is generated code? I know that C macros
demand this, but what about the API issues? This says
preprocessing all over it.

> But there is really a trick to this, and it is important to understand. 
>  In the military the problem is known as micro-management.  Problems and 
> issues should be addressed at the right level, without solutions imposed 
> from above which may not be appropriate in a particular situation.

The military can make its own rules and enforce them. But again,
*sigh*, in the general purpose world, things need to be a bit
more flexible.

> In Ada where this often comes up is in representation clauses.  You 
> either tell the compiler to "do it right" with alignment directives, or 
> lay things out bit-by-bit with rep clauses.  If there is an 
> implementation INdependent format you have to follow, sometimes because 
> you are interfacing directly to some special-purpose hardware.  Fine, 
> use static layouts.  But these are, by their nature not compiler 
> dependent in any way.  The hardware you interface with, or the other 
> computer system you interface with, or whatever, specifies the layout. 
> If some compiler can't support those rep clauses, it is not time for 
> preprocessor directives, it is time to either fix the compiler or get a 
> new one.  The bits MUST look exactly like that, it is not an option.

If you are binding to an API that returns a structure, and on
one platform you get 3 members back, and on another you get 5,
then just how is any Ada construct going to address this? What
if the order of member placement is different? These are the
kind of portability issues that Ada programmers must wrestle
with when binding to existing code.

> The second case is where you want the bits laid out a certain way for 
> efficiency.  Fine, no problem...and no rep clause required or needed. 
> That is the compiler's job.  You may use alignment clauses and specify 
> that some components are aliased, but the compiler will take all that 
> into account when it lays out the record.  If two compilers do it 
> differently on different hardware because, say, Integer is a different 
> size?  Not a problem.  If you needed the records to be identical on 
> different hardware, you would have specified things that way.

Again, you look at the simple cases where everything is the
same. When dealing with portability issues, you are looking
at representation issues where the interfaces are DIFFERENT.

> So as far as I am concerned, the case of rep specs that compile on one 
> compiler and not on another is almost uninteresting.  If you care, it is 
> a big problem.  But it has to be fixed by fixing (or replacing) one 
> compiler.  A pre-processor CAN'T help.  If you are trying to use 
> pre-processor directives to force efficient layouts on each different 
> platform, you are micro-managing.  Let each compiler choose the layout 
> it thinks is best.

Your examples _are_ uninteresting. The interesting ones are the
ones that differ according to platform, platform version, and
the choice of library(ies) used.

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

Re: Standard Ada Preprocessor

[Robert A Duff]

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

> The "Ada phylosophy" works until...

I'm rather skeptical of talk about "Ada philosophy".  I agree with you
and MDC that the issue is a very practical one.  It's all well and good
to recommend encapsulating system dependencies in package bodies and so
forth.  But you still need some mechanism to select which body to use in
each case.  I don't see any advantage to using make-file hackery for
that, over using #ifdef's.

The fact that some C programs are ugly due to overuse of #ifdefs is not
a good reason to outlaw preprocessors.  First of all, scattering #ifdefs
all over the place is not necessary, even in C, given a good design.
Second, if Ada had a preprocessor, it wouldn't be used as in C: to
define enumeration types, to write pragma-inline functions, to write
generics.  It would be used sparingly.

> I would just like people to look at some of the "practical"
> issues without resorting to quoting "ivory tower" notions.

I agree.

> I am not against any of these techniques. What I am against
> is the notion that "no, we don't do it that way because it
> might get abused".

I agree.  The language designer's job is to prevent mistakes,
not to prevent deliberate abuse.

- Bob

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Robert A Duff wrote:

> I'm rather skeptical of talk about "Ada philosophy".  I agree with you
> and MDC that the issue is a very practical one.  It's all well and good
> to recommend encapsulating system dependencies in package bodies and so
> forth.  But you still need some mechanism to select which body to use in
> each case.  I don't see any advantage to using make-file hackery for
> that, over using #ifdef's.

I completely and totally agree.  One of the things I love about Ada is 
the ability to avoid messing around with makefiles.

But this again totally misses what I keep saying about Ada 
pre-processors.  I don't avoid them intentionally.  It is just that if I 
get to the body of one of these implementation dependent packages, I 
usually write it using ifs and case statements planning to convert to 
#ifdefs later if needed.

This allows me to use one Ada compiler to (compile-time) debug the Ada 
code completely.  But once it compiles cleanly I don't switch to 
pre-processor directives for the fun of it.  I wait until I need it. 
I'm still waiting...

If your experience is different, fine.  But why are we arguing?  I never 
said that Ada compilers shouldn't support pre-processors, or that they 
shouldn't be used.  I just suggested waiting until it is needed.

I'm going to get back to work on some Ada code I hope to post soon. 
Again, if it needs a pre-processor to make it portable, I'll use one. 
But I don't expect it to happen.

Now if you think there should be a STANDARD Ada pre-processor, that is 
fine with me as well.  Just don't expect the ARG to develop the 
standard, form a PRG or whatever instead.  The ARG already has enough to do.

>>I am not against any of these techniques. What I am against
>>is the notion that "no, we don't do it that way because it
>>might get abused".

Definitely not my position.  I am the typical engineer.  I work very 
hard at being lazy.  So I will use whatever tools make my life easier. 
In this case, my "ivory tower notion" is that if I can do it in Ada, or 
with a pre-processor, I'll do it in Ada, even if it takes a little more 
design effort up front.  I know that when I am deep into schedule 
pressure and design changes I will thank myself.


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

[Marin David Condic]

The hiding of system/target/compiler dependent stuff in a body is all 
well and good. (I'm not convinced that it can *always* be hidden in a 
body and even if it can, that's another layer of indirection that 
sometimes starts posing unnecessary overhead for applications that might 
care about that.)

Sure, isolate it in a body. Write a monograph about how to hide 
compiler, target, OS, and other platform dependencies in a body. I'll 
try to follow it. Now give me a way to select *which* body I want via 
some standard compiler mechanism that I can count on having available. 
Shell scripts, makefiles or other build process mechanisms are simply 
pushing *that* problem off in another layer of indirection - and its a 
non-portable, uncertain layer at that.

MDC



Robert A Duff wrote:
> 
> I'm rather skeptical of talk about "Ada philosophy".  I agree with you
> and MDC that the issue is a very practical one.  It's all well and good
> to recommend encapsulating system dependencies in package bodies and so
> forth.  But you still need some mechanism to select which body to use in
> each case.  I don't see any advantage to using make-file hackery for
> that, over using #ifdef's.
> 



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

[Simon Wright]

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

> Sure, isolate it in a body. Write a monograph about how to hide
> compiler, target, OS, and other platform dependencies in a
> body. I'll try to follow it. Now give me a way to select *which*
> body I want via some standard compiler mechanism that I can count on
> having available. Shell scripts, makefiles or other build process
> mechanisms are simply pushing *that* problem off in another layer of
> indirection - and its a non-portable, uncertain layer at that.

I'm probably missing the point here, but as I recall the C side of
things has a humungous incomprehensible heap of autoconf, m4, shell
scripts, GNU make only, imake .. people are happy enough with that,
where's the problem on the Ada side in selecting the right source file
variant?

I've just added support for arrays to my UML-to-Ada generator, under
pressure. I _know_ I'm going to regret it, people are just bound to
decide to (eg) implement their own associations using them rather than
rely on the built-ins .. if you give people a bad feature they will
use it badly. Of course the market rules here, shame really ..

-- 
Simon Wright                               100% Ada, no bugs.

Re: Standard Ada Preprocessor

[Marin David Condic]

Well, let's sum it up this way: Its possible to have a given statement 
that works in environment A but not in B. For B you need an alternate 
statement. The decision has to be made at compile time because its the 
compiler that rejects the statement, so you can't wait until runtime and 
look at some configuration parameter to decide which statement to use. 
That leaves you with these choices:

1) Have the two alternate lines in the same file & let the compiler 
decide (based on some condition) which to actually read & interpret.

2) Build your own pre-processor because the compiler writers won't do 
the job in a standard way for you - but this is really no different than 
having the compiler decide. Its still indicating in the source code 
which line to compile.

2) Have the two alternate lines in two alternate files and let the build 
process decide which to actually send to the compiler. (Substitute the 
word "line" for "file" and you see the problem is identical - just using 
different mechanisms for which line to let the compiler try to interpret.)

You aren't fundamentally changing the problem - just where it will be 
dealt with. If the argument against conditional compilation is that it 
will make ugly, incomprehensible code, then that same argument goes 
against the build process. It is, after all, some set of instructions 
that will be obeyed by the computer and hence a kind of programming 
language, so giving *it* the responsibility is just going to result in 
ugly, incomprehensible code at the build level. Only it won't be 
portable and you can't count on it being there and someone who doesn't 
know what's going on with the different bodies of code is likely to 
bugger it up. Not to mention the other related maintenance problems such 
as not having all the code relating to one specific conceptual function 
in one place - the "unnormalized database" situation described (I think) 
by Warren.

So worrying about adding a feature that has the potential to be abused 
is, in my mind, a non-starter. The feature *will* be added *somewhere* 
so long as people have to manage code that must work in more than one 
environment. One camp says "Your life will be so much better if only you 
push that problem off to the build process level rather than the source 
code level." Another camp says "I've been there and done that and I 
think that at least some of the time, I'd rather deal with that problem 
at the source code level".

The problem is inherently unpleasant no matter which way you go. But you 
*will* have to deal with it and IMHO, *sometimes* I want to deal with it 
at the source code level because it creates the fewest headaches for me. 
The fact that someone might abuse it is also a non-starter. People can 
abuse *anything* in a programming language. (Look at the religious wars 
over using something like the predefined type "Integer" - some think its 
handy and convenient and others think it is apostasy and should never be 
used at all under any circumstances. Yet its in the language and Ada 
programs are probably still better built on average than those in some 
other languages. Life goes on in an imperfect world.)

MDC



Simon Wright wrote:
> 
> I'm probably missing the point here, but as I recall the C side of
> things has a humungous incomprehensible heap of autoconf, m4, shell
> scripts, GNU make only, imake .. people are happy enough with that,
> where's the problem on the Ada side in selecting the right source file
> variant?
> 
> I've just added support for arrays to my UML-to-Ada generator, under
> pressure. I _know_ I'm going to regret it, people are just bound to
> decide to (eg) implement their own associations using them rather than
> rely on the built-ins .. if you give people a bad feature they will
> use it badly. Of course the market rules here, shame really ..
> 


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

[Jeffrey Carter]

Marin David Condic wrote:

> You aren't fundamentally changing the problem - just where it will be 
> dealt with. If the argument against conditional compilation is that it 
> will make ugly, incomprehensible code, then that same argument goes 
> against the build process. It is, after all, some set of instructions 
> that will be obeyed by the computer and hence a kind of programming 
> language, so giving *it* the responsibility is just going to result in 
> ugly, incomprehensible code at the build level. 

There's a general SW engineering principle called localization. You 
don't lump your code for dealing with a 4-line LCD display in with the 
code for dealing with a temperature sensor just because they're both 
hardware. Similarly, you shouldn't want your code for doing something 
platform dependent on one platform lumped in with your code for another 
platform, nor your code for doing things lumped in with your code for 
deciding which code to use for this build.

Separating concerns this way makes everything easier to understand. I 
can look at the code for dealing with a VMS file system without having 
to understand the code for selecting a VMS file system; I can look at 
the code for selecting the file system without having to look at the 
code for dealing with file systems.

That said, it would be nice to have a standard, portable way to select 
different bodies for a build, but even without it, the advantages of 
separating these independent concerns seem clear.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Standard Ada Preprocessor

[Marin David Condic]

I don't think I've ever said that it was "bad" to localize dependencies 
and try to isolate this stuff. Quite the contrary. But if you could 
scatter system dependencies all over the code or scatter conditional 
compilation all over the code, why couldn't it be done all over the 
whole system, just at the file level? Why couldn't a project of 100 
files have 50 for one system and 50 for another system and not have 
anything "localized" in that sense? So my contention is that it can be 
abused no matter where you push the problem.

Often system dependencies are *not* isolated - people write code all the 
time that works for only one system. Good, bad or somewhere in between - 
its still done. Offering some kind of conditional compilation doesn't 
really change that much.

That said, I'd be inclined to agree that perhaps the problem could be 
solved with some portable means of selecting different bodies for a 
build. Its a reasonable compromise that at least tends to encourage 
isolation of dependencies at some appropriate level. I don't know that 
it solves *every* problem, but it probably fixes enough of them that the 
rest wouldn't matter much.

Remember that one of the big strengths of Ada is its assistance on 
making *portable* code by providing strong *standard* mechanisims for 
dealing with system dependencies. Everything from specifying numeric 
accuracy up through tasking is an attempt to say "If the implementation 
is compliant to the standard, you go compile for the platform and your 
code will work." Providing a mechanism for dealing with compile-time 
dependencies is just going down that same path a little further.


MDC

Jeffrey Carter wrote:
> 
> There's a general SW engineering principle called localization. You 
> don't lump your code for dealing with a 4-line LCD display in with the 
> code for dealing with a temperature sensor just because they're both 
> hardware. Similarly, you shouldn't want your code for doing something 
> platform dependent on one platform lumped in with your code for another 
> platform, nor your code for doing things lumped in with your code for 
> deciding which code to use for this build.
> 
> Separating concerns this way makes everything easier to understand. I 
> can look at the code for dealing with a VMS file system without having 
> to understand the code for selecting a VMS file system; I can look at 
> the code for selecting the file system without having to look at the 
> code for dealing with file systems.
> 
> That said, it would be nice to have a standard, portable way to select 
> different bodies for a build, but even without it, the advantages of 
> separating these independent concerns seem clear.
> 


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

[Simon Wright]

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

> 1) Have the two alternate lines in the same file & let the compiler
> decide (based on some condition) which to actually read & interpret.

The point I was fumbling towards is that you now have _two_
complicated things, probably:

* the external autoconf or whatever setup that decides from the
  environment whether some feature is present and sets the result in
  environment variables, a config.h or a makefile;

* and the source code that uses the condition.

-S

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7visiufpr5.fsf@smaug.pushface.org...
> Marin David Condic <nobody@noplace.com> writes:
>
> > 1) Have the two alternate lines in the same file & let the compiler
> > decide (based on some condition) which to actually read & interpret.
>
> The point I was fumbling towards is that you now have _two_
> complicated things, probably:
>
> * the external autoconf or whatever setup that decides from the
>   environment whether some feature is present and sets the result in
>   environment variables, a config.h or a makefile;
>
> * and the source code that uses the condition.

Right. There is no such thing as a compile-time solution that doesn't change
some code or management artifact like build scripts. If you're using
conditional compilation, you have to set the choice of which to use
somewhere. You're going to have to manage that code or scripts with some
form of configuration management per configuration. You cannot avoid this
part of the problem on anything but the tiniest one-person projects (where
you might actually be able to remember a bucket of special command-line
switches - but as I get older, I find I can't even do that anymore...). So,
given that you have a solution to the managment of separate code/build
scripts, why would you not apply it to managing separate specs and bodies?
And clearly, separate implementation-dependent code is always preferable
(and don't forget that subunits also can be used to keep
implementation-dependent stuff separate).

There are cases where Ada's existing conditional compilation doesn't work
(or makes the code much harder to read), but they're rare enough that going
further is a very tough sell.

                          Randy.

Re: Standard Ada Preprocessor

[Marin David Condic]

That's a fair point. No matter what you do, you'll have to have some 
kind of "outside the language" mechanism for specifying which path you 
want to go down and that isn't under the control of the language.

But do consider this: Something like "gnatmake" has pretty much 
eliminated for me needing to worry about build scripts in most 
situations. The *language* goes out and figures out what is out of date 
and what needs to be included in the build. So long as I can point to a 
single pile of files and say "there's a build in there somewhere - you 
go figure it out...", Ada does a marvelous job with it. Compared to C, 
this is a major improvement in many respects.

So it might not be that much of a stretch to ask something like gnatmake 
to go decide which way to branch in selecting files from two or more 
alternate paths within that pile of files. Something as simple as saying 
'gnatmake -buildstring="Go Down Path A"' might be sufficient so long as 
there was some way of picking up the "Path A" variants of files via some 
language mechanism so that I knew I could take the same pile of files 
and hand them off to Janus Ada or Aonix or any other compliant compiler 
and know that someone with little familiarity with my pile of code could 
use minimal instructions and direct an appropriate build for his platform.

It all goes to enhancing Ada's ability to be "The Portability Language". 
It already does so much in that respect that I think its a shame it 
can't seem to find a way to get around the fact that no two compilers or 
environments are ever going to be identical. "Outside The Language" 
solutions exist - but then we're no better than C (or other languages) 
in that regard. In some ways worse since at least C provides a (maybe at 
times ugly) way of directing the compiler down alternate paths.

MDC

Randy Brukardt wrote:
> 
> Right. There is no such thing as a compile-time solution that doesn't change
> some code or management artifact like build scripts. If you're using
> conditional compilation, you have to set the choice of which to use
> somewhere. You're going to have to manage that code or scripts with some
> form of configuration management per configuration. You cannot avoid this
> part of the problem on anything but the tiniest one-person projects (where
> you might actually be able to remember a bucket of special command-line
> switches - but as I get older, I find I can't even do that anymore...). So,
> given that you have a solution to the managment of separate code/build
> scripts, why would you not apply it to managing separate specs and bodies?
> And clearly, separate implementation-dependent code is always preferable
> (and don't forget that subunits also can be used to keep
> implementation-dependent stuff separate).
> 
> There are cases where Ada's existing conditional compilation doesn't work
> (or makes the code much harder to read), but they're rare enough that going
> further is a very tough sell.
> 
>                           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

[Jeffrey Carter]

Marin David Condic wrote:

> So it might not be that much of a stretch to ask something like gnatmake 
> to go decide which way to branch in selecting files from two or more 
> alternate paths within that pile of files. Something as simple as saying 
> 'gnatmake -buildstring="Go Down Path A"' might be sufficient so long as 
> there was some way of picking up the "Path A" variants of files via some 
> language mechanism so that I knew I could take the same pile of files 
> and hand them off to Janus Ada or Aonix or any other compliant compiler 
> and know that someone with little familiarity with my pile of code could 
> use minimal instructions and direct an appropriate build for his platform.

There was a posting on gnatlist today about the -X switch to GNAT and 
the use of project files to accomplish this. One can declare different 
lists of source directories, each associated with a meaningful 
identifier. One can then specify an identifier to -X and GNAT will use 
that list of source directories.

This is not portable, but it may serve as a good basis for defining 
something that could become standard.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Standard Ada Preprocessor

[Marin David Condic]

That there is an implemented answer at least gives people something to 
try and then throw stones at. I kind of like the fact that Gnat seems to 
not be afraid to experiment with practical solutions & see how well or 
poorly they operate in the real world. It might even be a place to 
implement some kind of conditional compilation within files and test it 
out. :-)

MDC

Jeffrey Carter wrote:
> 
> There was a posting on gnatlist today about the -X switch to GNAT and 
> the use of project files to accomplish this. One can declare different 
> lists of source directories, each associated with a meaningful 
> identifier. One can then specify an identifier to -X and GNAT will use 
> that list of source directories.
> 
> This is not portable, but it may serve as a good basis for defining 
> something that could become standard.
> 


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

[Marin David Condic]

I never said it was pretty. :-) I just said that the problem of dealing 
with compiler dependencies, environment dependencies and system 
dependencies is real and that we don't seem to have a really good 
portable answer to it sometimes. I'm suggesting there might be something 
the language could do to make dealing with that easier - if not 
prettier. I'm open to suggestions.

MDC

Simon Wright wrote:
> 
> The point I was fumbling towards is that you now have _two_
> complicated things, probably:
> 
> * the external autoconf or whatever setup that decides from the
>   environment whether some feature is present and sets the result in
>   environment variables, a config.h or a makefile;
> 
> * and the source code that uses the condition.
> 
> -S


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

[Pascal Obry]

Marin,

> The hiding of system/target/compiler dependent stuff in a body is all well
> and good. (I'm not convinced that it can *always* be hidden in a body and
> even if it can, that's another layer of indirection that sometimes starts
> posing unnecessary overhead for applications that might care about that.)

Pragma Inline could be used to avoid that.

> Sure, isolate it in a body. Write a monograph about how to hide compiler,
> target, OS, and other platform dependencies in a body. I'll try to follow
> it. Now give me a way to select *which* body I want via some standard
> compiler mechanism that I can count on having available.

:) You know that this is not portable. Ada has nothing to do with file system
and configuration management.

> Shell scripts, makefiles or other build process mechanisms are simply
> pushing *that* problem off in another layer of indirection - and its a
> non-portable, uncertain layer at that.

I do this with a makefile, lot of GNU software are doing that from a configure
script. Using ClearCase you can use a specific view for the target/OS/hardward
whatever you want the view to me... But I repeat this is not a compiler issue
but a Configuration Management one. Use the on that best fits for your
project.

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

[Marin David Condic]

You mean like when the compiler is supposed to detect that a 
specification is out of date and recompile whatever depends on it? :-)

Let's be practical. Ada specifies things that require some kind of 
"Outside The Source File" action to take place. Its not technically 
impossible or outside the bounds of a language standard to do that. You 
could write a rule that said some logical name or function would exist 
that an implementation is required to get a string into at compile time 
and that the string could be used for conditional compilation via a 
pragma or some other mechanism. There could be ways of specifying within 
the language how to connect different filenames to different packages 
just like there's a mechanism to associate an Ada logical package name 
with some actual file right now.

The exact details of how a user does it from the outside might not be 
portable - but then neither is the means of invoking the Ada compiler on 
some set of files right now.

MDC

Pascal Obry wrote:
> 
> 
> :) You know that this is not portable. Ada has nothing to do with file system
> and configuration management.
> 
> 

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

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:XdxRb.49218$Kg6.359124@news20.bellglobal.com...
...
> The "Ada phylosophy" works until you start interfacing to many
> foreign components (normally C ones) that cannot be relied upon
> to be the same. You cannot even rely on the same API to be
> available, in some cases. This is where things get real ugly.
>
> The practical side of many bindings, requires me to deal
> with portability issues in a "C wrapper". This may not always
> be entirely possible to avoid because of C macros, but I
> would like to put more code into Ada than into C. But I
> can't, because Ada cannot deal with the portability issues.
> That is, unless I resort to processes outside of the language
> (like gnatprep and code generation).

I've always thought that CM really needs to be applied on a per-line basis.
That is, you should be able to branch individual lines of a source file.
Clearly, such a system must be integrated with an editor, and should be able
to cleanly handle multiple versions of a system.

With such a system, you could cleanly manage any sort of differences without
making the source code harder to read. It's unfortunate that such systems
have never appeared in use.

                       Randy.

Re: Standard Ada Preprocessor

[Marin David Condic]

That would be nice. It would be even nicer if it was done in some manner 
that one could expect to exist on at least some wide variety of 
platforms. The thing is that it *isn't* available at the moment - or at 
least not in a practical way. Some kind of conditional compilation is 
not difficult to implement and *could* be available in short order. 
(Doesn't even really need the ARG - just an agreement by most of the 
vendors to use some mechanism like a pragma. The hypothetical line-level 
CM might even work by *generating* the pragma {or whatever} around the 
code.) So we could A) wait around for the world to become perfect or b) 
do something that gets a sub-optimal answer available in a reasonable 
timeframe. You could guess which I'd prefer. :-)

MDC

Randy Brukardt wrote:
> 
> 
> I've always thought that CM really needs to be applied on a per-line basis.
> That is, you should be able to branch individual lines of a source file.
> Clearly, such a system must be integrated with an editor, and should be able
> to cleanly handle multiple versions of a system.
> 
> With such a system, you could cleanly manage any sort of differences without
> making the source code harder to read. It's unfortunate that such systems
> have never appeared in use.
> 
>                        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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

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

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

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

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

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

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

One standard POSIX-Ada binding and one application-specific screen 
control package leaves me with 4 different package bodies to deal with, 
each of which contains code specific to one curses library. The code for 
a specific curses library is in one place, so I don't have to hunt all 
over the code for the bits that deal with that library when I have to 
change something.

If you want to handle those package bodies as one big file that you 
preprocess to get the desired version for a platform, go ahead. The 
payoff was in creating the application-specific package.

The point should always be "what does the application require?", not 
"what does the platform/environment provide?" Once you've done that you 
can always hide the differences behind an application-specific interface.

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

This thread is about a standard preprocessor (see the subject). But as 
someone who has done this kind of thing without a preprocessor and 
prefer the results, I'm convinced that what's needed is a portable way 
to tell the compiler to use the package body from the Win32 directory, 
or from the UNIX directory, or from the VMS directory.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> 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. :(
> 
> One standard POSIX-Ada binding 

Impossible. Some UNIces provide some API structure members,
while others don't, or provide something else again. Yes,
you can dumb it down to a "standard" (or omit non-universal
functionality), but by doing so you throw away functionality.
I find that unacceptable.

> and one application-specific screen 
> control package leaves me with 4 different package bodies to deal with, 
> each of which contains code specific to one curses library. 

Ah, but you cannot assume that the binding for PDcurses,
is going to be the same for all different POSIX platforms!
Going from POSIX, to X Windows, to Win32, will change the
interfaces again. It is not this simple, as the level of
support changes depending upon the platform, and version
of the same (in some cases). Try it in an open sourced
project (as I have), and you'll be a little wiser for it.

> If you want to handle those package bodies as one big file that you 
> preprocess to get the desired version for a platform, go ahead. The 
> payoff was in creating the application-specific package.
> 
> The point should always be "what does the application require?", not 
> "what does the platform/environment provide?" 

When you code "bindings" you have to consider both. Sometimes
you can push the application requirments into the thick
binding, developing some distance from the thin one. But at
some level, you will _still_ have to look at OS and C library
level "requirements". Develop some Open Sourced code in
without gnatprep, and we'll see how portable it is ;-)

> Once you've done that you 
> can always hide the differences behind an application-specific interface.

There is hiding to be sure. But down at the C and OS level,
things get rather ugly when trying to be "portable". The
fault of this is not so much Ada, but trying to interface
to a predominantly non-Ada world.

>> Think "conditional compilation". I see the "how" as an
>> implementation detail, that need _not_ track the C/C++
>> experience.
> 
> This thread is about a standard preprocessor (see the subject). But as 
> someone who has done this kind of thing without a preprocessor and 
> prefer the results, I'm convinced that what's needed is a portable way 
> to tell the compiler to use the package body from the Win32 directory, 
> or from the UNIX directory, or from the VMS directory.

That functionality would help. But there is still a need for
more than that.

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

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:
> Jeffrey Carter wrote:
> 
>> One standard POSIX-Ada binding 
> 
> Impossible. Some UNIces provide some API structure members,
> while others don't, or provide something else again. Yes,
> you can dumb it down to a "standard" (or omit non-universal
> functionality), but by doing so you throw away functionality.
> I find that unacceptable.

There is a standard POSIX-Ada binding (Florist is an implementation of 
this standard) to the POSIX standard. If you want something not in this 
standard, obviously you're going to have to provide it yourself on some 
platforms. If you're on a platform that doesn't provide some of the 
functionality, then it's not a POSIX system. In neither case are you 
dealing with different versions of POSIX.

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

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

>>>>> "JC" == Jeffrey Carter <spam@spam.com> writes:

    JC> Warren W. Gay VE3WWG wrote:
    >> Jeffrey Carter wrote:
    >> 

    >>> One standard POSIX-Ada binding

    >> Impossible. Some UNIces provide some API structure members,

    >> while others don't, or provide something else again. Yes,
    >> you can dumb it down to a "standard" (or omit non-universal
    >> functionality), but by doing so you throw away functionality.
    >> I find that unacceptable.

    JC> There is a standard POSIX-Ada binding (Florist is an implementation of
    JC> this standard)  to the  POSIX standard. If  you want something  not in
    JC> this standard, obviously  you're going to have to  provide it yourself
    JC> on some platforms.  If you're on a platform  that doesn't provide some
    JC> of the  functionality, then it's not  a POSIX system.  In neither case
    JC> are you dealing with different versions of POSIX.

Which does not matter if what you are doing is maintaining a program
which is running on multiple platforms and is compiled with multiple
compilers. The program has to run even if the platform does not
support a standard package like Florist. How many platforms is Florist
really available on, btw.? 

What matters is how do I do this while keeping the code readable and
maintainable.

One way to combat the combinatorial explosion of platforms * compiler
* library is to explicitly test for the features of the environment
you really need to know, not assume something because of a particular
platform/compiler. This is the approach typically used by projects
using the 'configure' tool.

I would really like to have some standard configuration tool which
could take such parameters as input and produce a version of the
system tailored to the environment in which it is to be compiled and
run. 

In absence of this, I have to do the job manually, or use some kind of
preprocessing. Btw., such a configuration tool would have to keep the
exact same information internally as the condtional compilation rules
handled by the preprocessor. The only difference is that with the
preprocessor, the programmer can see the rules as part of the program
text. 


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


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

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
: One way to combat the combinatorial explosion of platforms * compiler
: * library is to explicitly test for the features of the environment
: you really need to know, not assume something because of a particular
: platform/compiler. This is the approach typically used by projects
: using the 'configure' tool.

Only to some extent is this test possible with this approach.
Some GNU software authors must frankly tell you that unless
you use a know combination of compiler (i.e. gcc ;-) and OS (i.e.,
Unix or Wunix),
  "... non-default environments can expose bugs in the system header
   files, crippling compilation in _very_ non-obvious ways.  Because
   of that, we define them only on well-tested architectures where we
   know they will work."
(from wget config-post.h "1.9+cvs-dev")

And promtly como --c --strict lets me translate the source,
but without --remarks, it does not tell me that usleep is not
defined. So for a double argument to usleep which has been
manually range checked, the conversion to long is not done...

The configure approach has always been a nightmare for me the moment
I had to deviate from the assumptions that the configure script
is known to verify.

: I would really like to have some standard configuration tool which
: could take such parameters as input and produce a version of the
: system tailored to the environment in which it is to be compiled and
: run. 

Yes. But do you think it will ever be produced by programmers (who
like to creatively write programs)?
Collegues tell me that CM is tedious, always the same, automatic,
boring, wast of time, etc. etc., they want a DWIM procedure.
And when I answer that configuration
management, installation procedures, installation testing routines
and so one are 50% of software development, I'm on my own.

So the trick will be to turn CM into a programming problem, so
programmers and mathematicians will be instrested in solving it.


-- Georg

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
> : One way to combat the combinatorial explosion of platforms * compiler
> : * library is to explicitly test for the features of the environment
> : you really need to know, not assume something because of a particular
> : platform/compiler. This is the approach typically used by projects
> : using the 'configure' tool.
> 
> Only to some extent is this test possible with this approach.
> Some GNU software authors must frankly tell you that unless
> you use a know combination of compiler (i.e. gcc ;-) and OS (i.e.,
> Unix or Wunix),
>   "... non-default environments can expose bugs in the system header
>    files, crippling compilation in _very_ non-obvious ways.  Because
>    of that, we define them only on well-tested architectures where we
>    know they will work."
> (from wget config-post.h "1.9+cvs-dev")

Yes, you depend very much on how intelligent the configure scripts are, and you
cannot count on it being automatically portable to another platform,
but in my experience it is more portable and more readable then trying to cover
all platform/compiler/os versions explicitly.

This is from experience of developing/maintaining a > 1000 KLOC project on diverse 
platforms, like FreeBSD, Linux, AIX, HP-UX, Solaris, and Windows for several years.

> 
> And promtly como --c --strict lets me translate the source,
> but without --remarks, it does not tell me that usleep is not
> defined. So for a double argument to usleep which has been
> manually range checked, the conversion to long is not done...
> 
> The configure approach has always been a nightmare for me the moment
> I had to deviate from the assumptions that the configure script
> is known to verify.
> 

Yes, of course. As soon as you introduce new kinds of system dependencies, 
you have to revice the configure script. The hard part is figuring out
which part of your code is really system dependent. You usually find it
out by trying to port your system.

Remember the saying about there is no such thing about portable 
software, only software which has been ported :-)

> : I would really like to have some standard configuration tool which
> : could take such parameters as input and produce a version of the
> : system tailored to the environment in which it is to be compiled and
> : run. 
> 
> Yes. But do you think it will ever be produced by programmers (who
> like to creatively write programs)?
> Collegues tell me that CM is tedious, always the same, automatic,
> boring, wast of time, etc. etc., they want a DWIM procedure.
> And when I answer that configuration
> management, installation procedures, installation testing routines
> and so one are 50% of software development, I'm on my own.
> 
> So the trick will be to turn CM into a programming problem, so
> programmers and mathematicians will be instrested in solving it.
> 
> 
> -- Georg

In addition, you need it to be available without too much effort.
Isn't turning CM into a programming problem exactly what you do by using a 
preprocessor?


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

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Georg Bauhaus wrote:


> So the trick will be to turn CM into a programming problem, so
> programmers and mathematicians will be instrested in solving it.

No, I think the right approach is to keep improving Ada for software 
engineers and let programmers use C++.  We are doomed to live in a world 
where most code is poorly designed.  All we can do is try to keep an 
island of sanity, and try to insure that Ada is used where quality is 
critical.  (I am not saying there is no well designed C++ out there. 
There is, but it is the exception, not something you can expect.)
-- 
                                           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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Georg Bauhaus wrote:
>> So the trick will be to turn CM into a programming problem, so
>> programmers and mathematicians will be instrested in solving it.
> 
> No, I think the right approach is to keep improving Ada for software 
> engineers and let programmers use C++.  

OUCH. I can't believe you said that.

Perhaps this is getting to the root of the "real" problem. ;-)

Perhaps we "lowly programmers" need to ditch Ada, and reinvent
our own flavour of the same. After all, only "lowly programmers"
would need to worry about such dirty things as portability.

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

Re: Standard Ada Preprocessor

[David Starner]

On Tue, 27 Jan 2004 13:00:31 -0500, Warren W. Gay VE3WWG wrote:
> Perhaps this is getting to the root of the "real" problem. ;-)
> 
> Perhaps we "lowly programmers" need to ditch Ada, and reinvent
> our own flavour of the same. After all, only "lowly programmers"
> would need to worry about such dirty things as portability.

My feelings too. 15 years ago, someone made a killing by releasing a
Turbo Pascal for under a hundred bucks, and made Pascal a major language.
Free software has helped drop the off-the-shelf price of a complete Un*x
system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
But I still get quoted a price of $700 for an Ada compiler. Maybe that's
fine for ye system engineers, but programmers, especially we student
programmers, don't have a wealth of money to drop on compilers. Perhaps I
need to find a new hammer.

Re: Standard Ada Preprocessor

[Ludovic Brenta]

David Starner <dvdeug@email.ro> writes:

> My feelings too. 15 years ago, someone made a killing by releasing a
> Turbo Pascal for under a hundred bucks, and made Pascal a major language.
> Free software has helped drop the off-the-shelf price of a complete Un*x
> system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
> But I still get quoted a price of $700 for an Ada compiler. Maybe that's
> fine for ye system engineers, but programmers, especially we student
> programmers, don't have a wealth of money to drop on compilers. Perhaps I
> need to find a new hammer.

See my post about Debian GNU/Linux :)

-- 
Ludovic Brenta.

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
 
: Free software has helped drop the off-the-shelf price of a complete Un*x
: system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
: But I still get quoted a price of $700 for an Ada compiler.

Hm. I see one compiler for $0, one for $195, one for EUR 8xx,
and variations on the topic. With each you can get additions,
like libraries for creating GUIs, etc. In all, from the little
I know, these products can be called "professional versions",
even without major "additions".

What do you have to pay if you want the "professional versions"
of Delphi, C++, Lisp? More in most cases.

Marketing.


-- Georg

Re: Standard Ada Preprocessor

[Randy Brukardt]

"David Starner" <dvdeug@email.ro> wrote in message
news:pan.2004.01.27.18.56.15.347278@email.ro...
> On Tue, 27 Jan 2004 13:00:31 -0500, Warren W. Gay VE3WWG wrote:
> ... 15 years ago, someone made a killing by releasing a
> Turbo Pascal for under a hundred bucks, and made Pascal a major language.

About the same time, RRS offers Janus/Ada for $99. It certainly didn't make
Ada more popular... (And it should be remembered that Turbo Pascal was the
third such low priced Pascal. Anybody remember the $29 JRT Pascal that
preceded it? There's more to it than the price...)

> Free software has helped drop the off-the-shelf price of a complete Un*x
> system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
> But I still get quoted a price of $700 for an Ada compiler.

For the record, you can buy Janus/Ada for as little as $195 (with only 90
days of support, and no GUI tools).

> Maybe that's
> fine for ye system engineers, but programmers, especially we student
> programmers, don't have a wealth of money to drop on compilers. Perhaps I
> need to find a new hammer.

Ada doesn't have the sort of sugar daddies that a lot of these other
languages to. So far as I know, all existing Ada compilers are produced by
companies that make substantial portions of their revenue from their Ada
development systems. Giving them away isn't going to improve the bottom
line.

For instance, here at RRS, virtually all of our revenue is from Ada
development tools. If we started to give them away for free, there would be
a number of effects: (1) Support costs would jump dramatically. With far
more users, there would be far more questions to answer and bugs to track
down. We'd have to implement a "triage" system - which is precisely what you
don't like about ACT. (2) Revenue would drop to zero - we have no other
products. We've never sold much support, probably because we answer
questions from anyone with one of our products, supported or not. (3)
Because of (1) and (2), we'd need to find another revenue source. What ever
that is, it would remove most of the resources from the Ada compiler. So the
net effect would be to completely stall development of the Ada compiler.
That's unlikely to help you or anyone else.

Your complaint really seems to boil down to not liking the policies of the
maintainer of GNAT. The obvious solution in the Open Source world is to find
another maintainer. All you have to do is figure how those people will be
funded (or convinced to do a full-time job for free).

                               Randy.

Re: Standard Ada Preprocessor

[Simon Wright]

David Starner <dvdeug@email.ro> writes:

> My feelings too. 15 years ago, someone made a killing by releasing a
> Turbo Pascal for under a hundred bucks, and made Pascal a major
> language.  Free software has helped drop the off-the-shelf price of
> a complete Un*x system with C, C++, Pascal and Lisp compilers to
> under a hundred bucks.  But I still get quoted a price of $700 for
> an Ada compiler. Maybe that's fine for ye system engineers, but
> programmers, especially we student programmers, don't have a wealth
> of money to drop on compilers. Perhaps I need to find a new hammer.

This doesn't make sense.

The latest GCC distribution comes with C, C++, Fortran, Java, Pascal,
Python, Perl, and --- yes --- Ada. All at practically zero cost.

If I want a supported environment for any of those I will have to pay
money. For example, Dr Dobb's is advertising the Intel C++ compiler
for Linux at a special discount price of $378.

The Ada compiler for $700 is probably the Aonix one? They have a free
download too, again not supported (though they do have a mailing
list).

-- 
Simon Wright                               100% Ada, no bugs.

Re: Standard Ada Preprocessor

[David Starner]

On Tue, 27 Jan 2004 22:13:36 +0000, Simon Wright wrote:

> This doesn't make sense.
> 
> The latest GCC distribution comes with C, C++, Fortran, Java, Pascal,
> Python, Perl, and --- yes --- Ada. All at practically zero cost.

You're a bit confused. Python and Perl don't come with GCC, and Pascal
isn't a part of the standard GCC distribution.
 
> If I want a supported environment for any of those I will have to pay
> money.

You see two states: the free level and the supported level. Because of how
I work, I see three: the unsupported (which may cost a pretty penny, but
you won't get much direct support), the professionally supported (I've at
least heard of places where you pay huge bucks and get engineers at your
beck and call) and something in-between that a lot of free software
reaches, maybe call it the casually supported.

If I submit a bug report on the C compiler in GCC, it will get examined,
treated respectfully and it's not even inconceivable that a fix will get
backported in the release branch, either by the GCC maintainers or by the
Debian maintainers. It is high importance to all people working on most of
those compilers that they continue to run in the latest released GCC and
libc. I've submitted a documentation bug on GNAT that has not been dealt
with. There are two GCC frontends in risk of being dropped in the GCC 3.5
release because of large structural changes; Fortran 77, which has no
active maintainers, and Ada. The cumulative effect is that GNAT is
effectively unsupported, where most of the other compilers (Fortran 77
excepted) are casually supported.

As GNAT is the only Ada compiler that is Free software, that has a
negative effect on how Ada is viewed in the world of Free software, and
how a programmer who intends his programs to end up in the world of Free
software should react.

Re: Standard Ada Preprocessor

[Jeffrey Carter]

David Starner wrote:

> If I submit a bug report on the C compiler in GCC, it will get examined,
> treated respectfully and it's not even inconceivable that a fix will get
> backported in the release branch, either by the GCC maintainers or by the
> Debian maintainers. It is high importance to all people working on most of
> those compilers that they continue to run in the latest released GCC and
> libc. I've submitted a documentation bug on GNAT that has not been dealt
> with. There are two GCC frontends in risk of being dropped in the GCC 3.5
> release because of large structural changes; Fortran 77, which has no
> active maintainers, and Ada. The cumulative effect is that GNAT is
> effectively unsupported, where most of the other compilers (Fortran 77
> excepted) are casually supported.

It seems from this and an earlier post that you've submitted bug reports 
for C that were not dealt with, and have submitted bug reports for GNAT 
that were not dealt with. But since you've submitted bug reports for C 
that were dealt with, but have yet to submit a bug report for GNAT that 
has been dealt with, you seem to conclude that support for C is better 
than support for GNAT.

FWIW, I've submitted at least one bug report on a public version of GNAT 
that was dealt with.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
: 
: I've submitted a documentation bug on GNAT that has not been dealt
: with.

Where have you sent them? to report@ or to GCC's bugzilla?
Many of the handful of reports I have sent to both addresses have
been answered, sometimes with most helpful additional comments.
(I'm not a customer. One documentation bug.)
This includes reports sent only recently to GCC's Ada maintainers
via Bugzilla, with answers from people with ACT and non-ACT
addresses.


: There are two GCC frontends in risk of being dropped in the GCC 3.5
: release because of large structural changes; Fortran 77, which has no
: active maintainers, and Ada. The cumulative effect is that GNAT is
: effectively unsupported, where most of the other compilers (Fortran 77
: excepted) are casually supported.

I don't follow. GNAT, ifaik, is the GCC based compiler offered by
ACT. GCC contains an Ada front end which appears rather tightly coupled
with ACT's GNAT sources. You can check this if you look at the
extensive ChangeLog in the gcc/gcc/ada directory.


: As GNAT is the only Ada compiler that is Free software, that has a
: negative effect on how Ada is viewed in the world of Free software, and
: how a programmer who intends his programs to end up in the world of Free
: software should react.

I know of only 2 Free Software C compilers, and of one Free Software
C++ compiler. If these numbers are correct, how should they have the
opposite effect on the views of these popular languages?


--  Georg

Re: Standard Ada Preprocessor

[Stephen Leake]

David Starner <dvdeug@email.ro> writes:

> ... Because of how
> I work, I see three: the unsupported (which may cost a pretty penny, but
> you won't get much direct support), the professionally supported (I've at
> least heard of places where you pay huge bucks and get engineers at your
> beck and call) 

One such place is Ada Core Technologies, the maintainers of GNAT, the
Free Software Gnu Ada compiler.

> and something in-between that a lot of free software reaches, maybe
> call it the casually supported.

Like Lynx OS, VxWorks (not free software; also not very good support).

> If I submit a bug report on the C compiler in GCC, it will get
> examined, treated respectfully and it's not even inconceivable that
> a fix will get backported in the release branch, either by the GCC
> maintainers or by the Debian maintainers. It is high importance to
> all people working on most of those compilers that they continue to
> run in the latest released GCC and libc. I've submitted a
> documentation bug on GNAT that has not been dealt with. 

As a paying customer, I get fast and excellent response from ACT. I
have submitted many bug reports.

> There are two GCC frontends in risk of being dropped in the GCC 3.5
> release because of large structural changes; Fortran 77, which has
> no active maintainers, and Ada. The cumulative effect is that GNAT
> is effectively unsupported, where most of the other compilers
> (Fortran 77 excepted) are casually supported.

I don't know where you get your information; ACT says otherwise. They
are making it a high priority to keep the Ada in the gcc distribution
working and up-to-date. Not as high a priority as satisfying paying
customers, of course. But they see a good Free Software Ada compiler
as excellent advertising for their services. In the past, they have
released public versions of GNAT, usually based on slightly old
versions of gcc. Now, they are trying to keep up with the current gcc
versions, since they see that as even better advertising.

> As GNAT is the only Ada compiler that is Free software, that has a
> negative effect on how Ada is viewed in the world of Free software,
> and how a programmer who intends his programs to end up in the world
> of Free software should react.

Getting the facts is always a good idea ...

-- 
-- Stephe

Re: Standard Ada Preprocessor

[Jeff C,]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.46.1075258237.2270.comp.lang.ada@ada-france.org...
> David Starner <dvdeug@email.ro> writes:
>
>
> > There are two GCC frontends in risk of being dropped in the GCC 3.5
> > release because of large structural changes; Fortran 77, which has
> > no active maintainers, and Ada. The cumulative effect is that GNAT
> > is effectively unsupported, where most of the other compilers
> > (Fortran 77 excepted) are casually supported.
>
> I don't know where you get your information; ACT says otherwise. They
> are making it a high priority to keep the Ada in the gcc distribution
> working and up-to-date. Not as high a priority as satisfying paying
> customers, of course. But they see a good Free Software Ada compiler
> as excellent advertising for their services. In the past, they have
> released public versions of GNAT, usually based on slightly old
> versions of gcc. Now, they are trying to keep up with the current gcc
> versions, since they see that as even better advertising.
>


Actually, he probably gets  his information from the gcc mailing list. It is
indeed true
that there is a chance (probably a good chance) that there will be no Ada
front end in
gcc 3.5 (which may actually be gcc 4.0...but that is a different matter).

That is not to say that Ada would not re-appear in 3.5.1 or 4.1. The issue
is that gcc
is getting ready to fold in a major infrastructure change that requires some
heavy modification
to the front ends. This is a major upgrade to the compiler and currently
creates a compiler
that runs a little slower but produces code that runs a little faster.  The
reason that it is still a "good thing"
is that in theory it will be easier to roll in new optimizations into the
compiler and actually make it much
better in the future.

Even the Ada maintainers on the gcc mailing list have indicated that Ada
support should not be a show
stopper for a 3.5 or 4.0 release. They have also indicated that they would
likely roll in the needed changes
at some point but that it is not a high priority.

So things are not as bad as they sound but certainly not as good as they
could be.

Re: Standard Ada Preprocessor

[David Starner]

On Tue, 27 Jan 2004 21:50:19 -0500, Stephen Leake wrote:

> As a paying customer, I get fast and excellent response from ACT. I
> have submitted many bug reports.

I'm not doubting that. 
 
>> There are two GCC frontends in risk of being dropped in the GCC 3.5
>> release because of large structural changes; Fortran 77, which has
>> no active maintainers, and Ada. The cumulative effect is that GNAT
>> is effectively unsupported, where most of the other compilers
>> (Fortran 77 excepted) are casually supported.
> 
> I don't know where you get your information; ACT says otherwise. 

In <http://gcc.gnu.org/ml/gcc/2004-01/msg00999.html>
Richard Kenner writes:

***
    > As it is today, it is impossible to build an Ada compiler with the
    > branch.

[...]

At some point in the not too distant future, the Ada front end will handle
function-at-a-time and then converting it to using tree-ssa might be
something that the tree-ssa folks can either do or help with, but I don't see
this is a major timing issue: even if we had one release of GCC (say 3.5)
that didn't support Ada, it wouldn't be fatal and should not hold up tree-ssa
if it were ready before the Ada conversion was done.

***

It's a long thread, and Robert Dewar and Richard Kenner restate that basic
point a few times.

> They
> are making it a high priority to keep the Ada in the gcc distribution
> working and up-to-date.

In <http://gcc.gnu.org/ml/gcc/2004-01/msg01970.html>
Arnaud Charlet <charlet at ACT-Europe dot FR> writes

***

[...]
Note that GCC 3.3 contains a pretty bad Ada compiler (possibly
worse than 3.2 which was not very good either), so it is not recommended
to use it for anything else than bootstrapping newer versions as
far as Ada is concerned.

***

GCC 2.95 was the first release of GCC after the EGCS branch became
mainline. There was almost four years between that release and GCC 3.3,
and they have not produced a compiler that runs on the post-EGCS code that
they consider good.

> Getting the facts is always a good idea ...

Yes, it is. 

Re: Standard Ada Preprocessor

[Stephen Leake]

David Starner <dvdeug@email.ro> writes:

> <snip summary of gcc thread>

Ok, thanks for the update. 

This is a typical problem with open source/bazarre development
projects. If one subgroup has significantly different goals than the
general group, they will get left out.

ACT has much higher quality goals than the general gcc group. I prefer
it that way.

-- 
-- Stephe

Re: Standard Ada Preprocessor

[David Starner]

On Wed, 28 Jan 2004 22:03:18 -0500, Stephen Leake wrote:

> This is a typical problem with open source/bazarre development
> projects. If one subgroup has significantly different goals than the
> general group, they will get left out.

I hardly see how this is a problem with open source. If
Microsoft had an Ada frontend to their compiler, and was looking
to replace the middle layer with a all-around superior one, do
you think they'd hesitate to release a new Visual C++ because Visual
Ada wasn't ported to the new middle end?
 
> ACT has much higher quality goals than the general gcc group. 

Any evidence for this, or is this just jingoism?

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
: 
: Any evidence for this, or is this just jingoism?

Users of GNAT 3.15p have been able to work with 3.15p
for quite long. The 3.4 branch (not even released yet) of GCC has
an Ada front end which includes many corrections and improvements.
What is wrong with working with GCC 3.4 compilers if it is better
than 3.15p?

Latest and greatest = highest score in version number?
Versionitis.


Georg

Re: Standard Ada Preprocessor

[David Starner]

On Thu, 29 Jan 2004 11:14:20 +0000, Georg Bauhaus wrote:

> Latest and greatest = highest score in version number?
> Versionitis.

Using the version of the GNAT compiler that comes with my distribution,
and hence the one that matches the latest C compiler has many advantages.
If I have an obscure code generation bug on little endian MIPS or some
other obscure architecture, it's probably not one that C and C++
programmers have already found and got fixed, and it may get fixed without
switching major compiler versions. I'm able to compile on a larger
percentage of the architectures that my C colleagues can, due to people
porting GNAT on GCC-head instead of an ancient branch, and due to the
number of architectures that were added to new GCC. Also, some of the Ada
libraries come precompiled for the GNAT version that comes with my
distribution, and the Ada compiler and debuggers and other programs are
tested against that version of GCC and the distribution. Old versions of
GNAT do not support the libc I'm using, for one thing.

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
: On Thu, 29 Jan 2004 11:14:20 +0000, Georg Bauhaus wrote:
: 
:> Latest and greatest = highest score in version number?
:> Versionitis.
: 
: Using the version of the GNAT compiler that comes with my distribution,
: and hence the one that matches the latest C compiler has many advantages.

I don't understand the "hence".

:  I'm able to compile on a larger
: percentage of the architectures

the ancient obscure ones you mentioned?

: that my C colleagues can, due to people
: porting GNAT on GCC-head instead of an ancient branch, and due to the
: number of architectures that were added to new GCC.

I gather then that this is not a personal computer architecture?
If not, a handheld? A cell phone?
If you will be developing software for sale for one of the
new million sellers, might not some support be very helpful?

: Also, some of the Ada
: libraries come precompiled for the GNAT version that comes with my
: distribution, and the Ada compiler and debuggers and other programs are
: tested against that version of GCC and the distribution. Old versions of
: GNAT do not support the libc I'm using, for one thing.

True. But you aren't saying that GCC 3.4 is old when it is not yet
released or that it is old in a year or so?


-- georg

Re: Standard Ada Preprocessor

[Marin David Condic]

Its odd how the whole "Open Source" movement was supposed to avoid rigid 
heierarchies and "let a hundred flowers bloom" so to speak. Everyone 
would be free to do what they wanted and there would be all sorts of 
variations on software products and everything would be so beautiful. 
But once Open Source products get out there, they rather quickly have to 
re-invent the whole heierarchy and rigid control that quashes individual 
variants. Irony runs rampant! :-)

MDC

Stephen Leake wrote:

> 
> This is a typical problem with open source/bazarre development
> projects. If one subgroup has significantly different goals than the
> general group, they will get left out.



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

[Preben Randhol]

On 2004-01-29, Marin David Condic <nobody@noplace.com> wrote:
> Its odd how the whole "Open Source" movement was supposed to avoid rigid 
> heierarchies and "let a hundred flowers bloom" so to speak. Everyone 

No, it wasn't. You are confusing it with the Bazaar model which is something
else entirely.



-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Preben Randhol wrote:

> No, it wasn't. You are confusing it with the Bazaar model which is something
> else entirely.

And most people who have read "The Cathedral and the Bazaar" prefer the 
Cathedral approach for operating systems kernels (look at Linux) and 
compilers (such as GCC and GNAT).

One person, Linus Torvalds, approves all additions and changes to the 
Linux kernel.  That doesn't mean that the Cathedral model is used fof 
the rest of Linux, in fact there are many developers and teams working 
on the same and different parts of Linux.  But having one kernel chain, 
and controlled releases of new versions allows the rest of Linux to use 
the Bazaar model.

I won't even try to describe the problems with GCC that occured recently 
due to a forking of the compiler development chains, but by the end of 
this year I hope we will all be back to a single gcc chain.

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

[Michael Bode]

Stephen Leake <stephen_leake@acm.org> writes:

> As a paying customer, I get fast and excellent response from ACT. I
> have submitted many bug reports.

Just being curious: roughly what is the price per seat for GNAT
support? I don't want to ask ACT because I'm not likely to become a
paying customer.

-- 
PGP Key: http://home.t-online.de/home/michael_bode/downloads/michael_bode.key

Re: Standard Ada Preprocessor

[Stephen Leake]

Michael Bode <m.g.bode@web.de> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
> 
> > As a paying customer, I get fast and excellent response from ACT. I
> > have submitted many bug reports.
> 
> Just being curious: roughly what is the price per seat for GNAT
> support? 

I'm paying $18k per year for 5 seats. But it varies (a lot) for
different targets and hosts, and for different combinations of products.

-- 
-- Stephe

Re: Standard Ada Preprocessor

[Marin David Condic]

David Starner wrote:
 >
 >
 > My feelings too. 15 years ago, someone made a killing by releasing a
 > Turbo Pascal for under a hundred bucks, and made Pascal a major
 > language.

It was probably more than 15 years ago - Early 1980's?


 > Free software has helped drop the off-the-shelf price of a complete
 > Un*x system with C, C++, Pascal and Lisp compilers to under a hundred
 > bucks. But I still get quoted a price of $700 for an Ada compiler.
 > Maybe that's fine for ye system engineers, but programmers,
 > especially we student programmers, don't have a wealth of money to
 > drop on compilers. Perhaps I need to find a new hammer.

In fairness, something like Gnat has forced the cost of Ada compilers
down too. Gnat is available at no cost and is of reasonable quality for
most work. And there are compilers such as MSVC++ that will come in at a
$700 price tag (or thereabouts - I've not priced it recently) as well.
So Ada is at least in the ballpark.

Where Ada may be weaker than other languages is in the area of what all
surrounds the compiler itself. Things like Java present a more "Total 
Solution" to the potential buyer.

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

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:fGxRb.49248$Kg6.361048@news20.bellglobal.com...
...
> Perhaps we "lowly programmers" need to ditch Ada, and reinvent
> our own flavour of the same. After all, only "lowly programmers"
> would need to worry about such dirty things as portability.

Everyone has to worry about portability. But "software engineers" use CM and
design to manage the problem, rather than trying to sweep it under a rug.
Conditional compilation, if present, would be used in very, very restricted
circumstances.

             Randy.

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Warren W. Gay wrote:

> >> So the trick will be to turn CM into a programming problem, so
> >> programmers and mathematicians will be instrested in solving it.
> > 
> > No, I think the right approach is to keep improving Ada for software 
> > engineers and let programmers use C++.  
>
> OUCH. I can't believe you said that.
But what you expected? It is exactly you who provoked that. You was given
many good explanations, but you continued to insist infinitely on your
viewpoint, without taking a break for consideration of arguments of your
opponent to good depth.

> Perhaps this is getting to the root of the "real" problem. ;-)
Certainly NO.

> Perhaps we "lowly programmers" need to ditch Ada, and reinvent
> our own flavour of the same.
This is simply nonsense. You, and even "we" simply have no skills that are
necessary for reaching anything comparable.

> After all, only "lowly programmers"
> would need to worry about such dirty things as portability.
Oh, perhaps you really need a year of real software engineering practice.
Or get a good friend of that kind. It seems that you should not rely upon your
imagination in this matter.




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

Re: Standard Ada Preprocessor (conclusions)

[Warren W. Gay VE3WWG]

Alexandre E. Kopilovitch wrote:
> Warren W. Gay wrote:
>>>>So the trick will be to turn CM into a programming problem, so
>>>>programmers and mathematicians will be instrested in solving it.
>>>
>>>No, I think the right approach is to keep improving Ada for software 
>>>engineers and let programmers use C++.  
>>
>>OUCH. I can't believe you said that.
> 
> But what you expected? It is exactly you who provoked that. You was given
> many good explanations, but you continued to insist infinitely on your
> viewpoint, without taking a break for consideration of arguments of your
> opponent to good depth.

It seems to me that what this all boils down to is a deeply
entrenched attitude that "we don't do it 'that way', and
never will". And if it is truly that way, then fine. But
let's at least be honest about it.

Looking at the larger question of why "Ada is Unpopular?"
then, I would have to conclude from this thread (and the
original) that this attitude is ONE reason
that Ada has not achieved popular support.  That is a
shame, IMO, because there has been much effort
expended into bringing software into a newer level of
quality and reliability. Much could be learned from the
lessons of Ada.

But IMHO, there needs to be an increased look at the
practical issues (I don't see += as one of them). But
Ada must survive in a predominantly C/C++ world. If
Ada doesn't put the engineer/programmer on a nearly
equal footing with C/C++ programmers, the battle
for marketshare is lost. The issues I presented, were
primarily focused on bindings to this world. An area
where Ada is very weak.

Perhaps a secondary conclusion from this entire discussion
can be that perhaps Ada is not really targeted for
"General Purpose" computing after all, and never will
be. Again, if that be the case, fine, but let's not try
to pretend otherwise.

When networks were being designed there was the holy
ISO model.  This was the "engineered" solution. Today
however, we all use the TCP/IP model, which was designed
from the ground up. Developed in part by practical
experience. I think there is a lesson there, that
Ada can learn from.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor (conclusions)

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: 
: Looking at the larger question of why "Ada is Unpopular?"
: then, I would have to conclude from this thread (and the
: original) that this attitude is ONE reason
: that Ada has not achieved popular support.

Does C# have a preprocessor? Java?


-- Georg

Re: Standard Ada Preprocessor (conclusions)

[Marin David Condic]

I'm afraid I'd have to agree to some extent. Ada *must* pay attention to 
what real-world developers *are* doing and why they are doing it and ask 
"Can I be of some assistance in that area?" It *must* offer more and 
better to the average developer or the average developer will go 
somewhere else.

Complex, arcane, difficult to understand techniques to get around what 
might be perceived as "bad" in what developers are already doing doesn't 
help them much. Offering them a "better" solution that is easy for them 
to grasp and utilize is something that helps make the sale. A good 
example is the whole ability of Ada to handle the "make" job right from 
a single command rather than having to build all sorts of complex, 
arcane, difficult to understand makefiles. The developer has a *better* 
answer with Ada than he does with C in that regard. We don't need to 
blindly mimmic whatever already exists - that would be the "Me Too!" 
answer. But if we can offer them something that does the same job in a 
better way - or offer them everything they've already got and *more* - 
then there's more incentive to use Ada.

Ada should take a look at what the people who *don't* use Ada are doing 
and what it is they need to do their jobs better. If it really offers 
them more leverage and does it in simple ways that they can understand 
and utilize, perhaps they'll start gravitating towards the better mousetrap?

MDC

Warren W. Gay VE3WWG wrote:
> 
> Looking at the larger question of why "Ada is Unpopular?"
> then, I would have to conclude from this thread (and the
> original) that this attitude is ONE reason
> that Ada has not achieved popular support.  That is a
> shame, IMO, because there has been much effort
> expended into bringing software into a newer level of
> quality and reliability. Much could be learned from the
> lessons of Ada.
> 

-- 
======================================================================
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 (conclusions)

[Lutz Donnerhacke]

* Marin David Condic wrote:
> answer. But if we can offer them something that does the same job in a
> better way - or offer them everything they've already got and *more* -
> then there's more incentive to use Ada.

My setup for plattform dependant implementations:
 - There is a source directory containing all portable files.
 - There are plattform dependant directories containing only the
   implementation body (usually as generic instanciation or seperate body)
 - Call: gnatmake -aI"platform"

Re: Standard Ada Preprocessor (conclusions)

[Marin David Condic]

I didn't say you couldn't get there. I said you couldn't get there in a 
way you knew was portable across all compliant Ada compilers. Dragging 
the pile of code over to some other system means someone has to then 
figure out what are all the system dependencies & deal with some 
alternate mechanism for selecting what files go into the build. Also, it 
sometimes seems like overkill to have to manage separate piles of files 
if the problem is rather small & self-contained.

Remember that "Ada /= Gnat" and "Ada_Development_Environment /= Linux" 
and "Ada_Target /= x86" Sometimes there is a lot of variation in where 
the code has to go.

MDC

Lutz Donnerhacke wrote:
> 
> My setup for plattform dependant implementations:
>  - There is a source directory containing all portable files.
>  - There are plattform dependant directories containing only the
>    implementation body (usually as generic instanciation or seperate body)
>  - Call: gnatmake -aI"platform"


-- 
======================================================================
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 (conclusions)

[Lutz Donnerhacke]

* Marin David Condic wrote:
> Remember that "Ada /= Gnat"

Of course. I'd prefer ARM compilant sources.

> and "Ada_Development_Environment /= Linux"

Linux, OSF/1, and NextStep.

> and "Ada_Target /= x86"

x86 (different families), 68k, and alpha.

> Sometimes there is a lot of variation in where the code has to go.

Of course. In this case simply copy the content of the platform directory
into the source directory and call your prefered ada compiler.

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Robert I. Eachus wrote:

> No, I think the right approach is to keep improving Ada for software 
> engineers and let programmers use C++.  We are doomed to live in a world 
> where most code is poorly designed.  All we can do is try to keep an 
> island of sanity, and try to insure that Ada is used where quality is 
> critical.  (I am not saying there is no well designed C++ out there. 
> There is, but it is the exception, not something you can expect.)

What's really needed is to only allow software engineers to choose 
languages and design software. Coders can only write small, well 
specified pieces of code for the designs developed by software engineers.

The problem is distinguishing software engineers from coders and the 
economic pressures for poor quality software.

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

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

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

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

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

Certainly you know all that very well.




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

Re: Standard Ada Preprocessor

[Robert I. Eachus]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> I don't know if you consider SQL, XML, and HTML as a programming 
> languages,
Well, 3 different answers for them:

1) HTML is not a programming language, and any attempt to make it
a programming language is fundamentally wrong;

2) SQL is controversial thing. Personally I don't see it as a programming
language, on similar ground as for RPG. Both are too fixed on purpose (this
and goal-orientation are different things).

3) about XML I'm still not sure. From its popular presentation it does not
seem a programming language; but SAX somehow changes the picture. Probably
the decisive feature is DTD, but it is not clear (at least for me) *what*
is (or may be) programmed within a DTD, and to which limits.

> 2) There is no need for a STANDARD Ada pre-processor, because most of 
> the need for that sort of thing in Ada is better done in Ada.  I'd 
> rather spend my efforts in the standards area on making Ada a 99% 
> solution instead of a 90% solution.
Ok, but there is one thing, which was mentioned by many in this thread (and
perhaps by you also): the need to have multiple bodies for a package and
to choose between them according to particular configuration. This need
certainly does not require preprocessor, but perhaps it will be good to
add some standard language construct for that - which communicates to a
compiler the fact that the body of particular package must be picked from
non-standard place. Nothing more than that - all other information (compiler
option formats etc.) need not and cannot be standardized. Something like

  pragma Remote_Body;

>From other side, I wonder, why - if something like this is really needed -
it was not already added to existing compilers as an implementation-defined
feature. Or it was?



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

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Alexandre E. Kopilovitch <aek@vb1162.spb.edu> wrote:
: 
: 3) about XML I'm still not sure. From its popular presentation it does not
: seem a programming language; but SAX somehow changes the picture.

XML is a well defined term, and the hint it has in its
name is "markup language". SAX stands for Simple API for XML
parsers, not a programming language.



-- Georg

Nature of XML (was: Re: Standard Ada Preprocessor)

[Alexandre E. Kopilovitch]

Georg Bauhaus wrote:

> : 3) about XML I'm still not sure. From its popular presentation it does not
> : seem a programming language; but SAX somehow changes the picture.
>
> XML is a well defined term, and the hint it has in its
> name is "markup language".
Yes, but you did not noticО©╫d the first letter -:)

> SAX stands for Simple API for XML parsers, not a programming language.
Ok, but constructing an input stream for an automaton is also programming -
no less that constructing a transition matrix for it. And SAX produces exactly
that - a stream of events... as far as I know.

Anyway, you excluded DTDs from your consideration, and that is the most
suspicious thing there. DTDs certainly can't be characterized as simply
"markup".




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

Re: Nature of XML (was: Re: Standard Ada Preprocessor)

[Preben Randhol]

On 2004-01-29, Alexandre E. Kopilovitch <aek@VB1162.spb.edu> wrote:
> Ok, but constructing an input stream for an automaton is also programming -
> no less that constructing a transition matrix for it. And SAX produces exactly
> that - a stream of events... as far as I know.

http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Nature of XML (was: Re: Standard Ada Preprocessor)

[Alexandre E. Kopilovitch]

Preben Randhol wrote:

> > constructing an input stream for an automaton is also programming -
> > no less that constructing a transition matrix for it. And SAX produces exactly
> > that - a stream of events... as far as I know.
>
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language

=> "A formal language in which computer programs are written."

Well, good for you. As far as I understand from some your previous postings,
your profession is chemistry, and not programming. Would you be satisfied by
a definition of molecule, from which you are unable to tell reasonably,
whether a crystal is simply a single huge molecule or not?




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

Re: Nature of XML (was: Re: Standard Ada Preprocessor)

[Preben Randhol]

On 2004-01-30, Alexandre E. Kopilovitch <aek@VB1162.spb.edu> wrote:
>>
>> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language
>
>=> "A formal language in which computer programs are written."
>
> Well, good for you. As far as I understand from some your previous postings,
> your profession is chemistry, and not programming. Would you be satisfied by
> a definition of molecule, from which you are unable to tell reasonably,
> whether a crystal is simply a single huge molecule or not?

What on earth are you talking about?

SAX is an API for XML processing. This one is event based. It is
not a transformation tool per se but you can use it to generate XML

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Nature of XML (was: Re: Standard Ada Preprocessor)

[Alexandre E. Kopilovitch]

Preben Randhol wrote:

> >> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?programming+language
> >
> >=> "A formal language in which computer programs are written."
> >
> > Well, good for you. As far as I understand from some your previous postings,
> > your profession is chemistry, and not programming. Would you be satisfied by
> > a definition of molecule, from which you are unable to tell reasonably,
> > whether a crystal is simply a single huge molecule or not?
>
> What on earth are you talking about?

For confusing you even more -:) , let's consider the difference between
Engrus and Ruglish. With Engrus, the English language plays significant role
in thinking, while with Ruglish all thinking goes with Russian only, and
translation occurs immediately before coughing words out.

>-- 
>"Saving keystrokes is the job of the text editor, not the programming
> language."

You may see that as irony, but the most known Ada 83 designer Jean Ichbiah
turned exactly to that - the flagship product of his company aimed to saving
keystrokes: http://www.textware.com .



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

Re: Nature of XML (was: Re: Standard Ada Preprocessor)

[Preben Randhol]

On 2004-01-31, Alexandre E. Kopilovitch <aek@VB1162.spb.edu> wrote:
>>-- 
>>"Saving keystrokes is the job of the text editor, not the programming
>> language."
>
> You may see that as irony, but the most known Ada 83 designer Jean Ichbiah
> turned exactly to that - the flagship product of his company aimed to saving
> keystrokes: http://www.textware.com .

Yes. As I said it is the job of the text editor :-)

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Nature of XML

[Georg Bauhaus]

Alexandre E. Kopilovitch <aek@vb1162.spb.edu> wrote:
: Georg Bauhaus wrote:
: 
:> : 3) about XML I'm still not sure. From its popular presentation it does not
:> : seem a programming language; but SAX somehow changes the picture.
:>
:> XML is a well defined term, and the hint it has in its
:> name is "markup language".
: Yes, but you did not notic?d the first letter -:)

Yes, but that's cheating :-)


:> SAX stands for Simple API for XML parsers, not a programming language.
: Ok, but constructing an input stream for an automaton is also programming -
: no less that constructing a transition matrix for it. And SAX produces exactly
: that - a stream of events... as far as I know.

Does an API produce something?

: Anyway, you excluded DTDs from your consideration, and that is the most
: suspicious thing there. DTDs certainly can't be characterized as simply
: "markup".

"<" followed by "!" starts a declaration, a markup declaration in
SGML reference syntax.  <!>, a comment declaration, is  the smallest
comment possible in SGML. So we have comments for a start.
There are DOCTYPE, ELEMENT, ENTITY, NOTATION, ATTLIST, and some
more kinds of declarations, among them marked sections, which
can be INCLUDED, or IGNORED, so we have conditional "compilation",
and maybe forward branching? :-)
Add some typing in ATTLIST and some constraints by IDREF(S). 
Then there is the treatment of (parameter) entity references.
Does it allow computations on strings? I don't know.

Here is add:

* The DTD

<!ENTITY x "1">
<!ENTITY y "11">

<!ELEMENT result EMPTY>
<!ATTLIST result
   value NMTOKEN #FIXED "&x;&y;">

* the document instance

<?xml version="1.0"?>
<!DOCTYPE result SYSTEM "add.dtd">
<result/>

* a "noncomputing" transformation that just shows the result.

<transform
  xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0">

  <template match="result">
    <value-of select="@value"/>
  </template>

</transform>

(This is not XML at work, but the X you mentioned, in a sense :-)

-- Georg

Re: Nature of XML

[Marius Amado Alves]

Programming languages have semantics. XML does not. Simple, no?

Re: Nature of XML

[Georg Bauhaus]

Marius Amado Alves <maa@liacc.up.pt> wrote:
: Programming languages have semantics. XML does not. Simple, no?

If an IDREF attribute implies that an attribute value must
refer to an element with the corresponding id, is that syntax?

Re: Nature of XML

[Robert I. Eachus]

Georg Bauhaus wrote:

> Marius Amado Alves <maa@liacc.up.pt> wrote:
> : Programming languages have semantics. XML does not. Simple, no?
> 
> If an IDREF attribute implies that an attribute value must
> refer to an element with the corresponding id, is that syntax?

Guys, try not to get carried away!  In the post that started this 
unending thread I said: "I don't know if you consider SQL, XML, and HTML 
as a programming languages, but recently I have written a lot of all three."

Should I have said I don't know ... and I don't care. ;-)  I consider 
writing SQL and HTML as part of a database interface program as 
programming.  The fact that the SQL and HTML may be in quotes inside an 
Ada subprogram is not really relevant. (They count as non-comment source 
lines of code.) On the other hand, if I am creating a static web page in 
HTML I don't consider that activity to be programming.  If you have a 
different definition you use, fine.

-- 
                                           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: Nature of XML (ramblings)

[Marius Amado Alves]

Robert I. Eachus wrote:

 > Georg Bauhaus wrote:
 >
 >> Marius Amado Alves <maa@liacc.up.pt> wrote:
 >> : Programming languages have semantics. XML does not. Simple, no?
 >>
 >> If an IDREF attribute implies that an attribute value must
 >> refer to an element with the corresponding id, is that syntax?
 >
Ok, I stand corrected. I should have said *operational* semantics.

 > Guys, try not to get carried away!  In the post that started this
 > unending thread I said: "I don't know if you consider SQL, XML, and
 > HTML as a programming languages, but recently I have written a lot of
 > all three."
 >
 > Should I have said I don't know ... and I don't care. ;-)  I consider
 > writing SQL and HTML as part of a database interface program as
 > programming.  The fact that the SQL and HTML may be in quotes inside
 > an Ada subprogram is not really relevant. (They count as non-comment
 > source lines of code.) On the other hand, if I am creating a static
 > web page in HTML I don't consider that activity to be programming.  If
 > you have a different definition you use, fine.
 >
Sure. Just rambling now: it's interesting that usualy the somehow most
deep, higher concepts in a domain are the least well defined:
programming, programming languages. In linguistics "semantics" has been
called "the science that does not exist" (Fernando Belo?). And of course
some if not all linguistics semanticists agree but notice that you can
still 'do' semantics even though the term is not defined.

In programming we may be a bit more 'safe'. Ada, SQL, XML, HTML are all
well defined. As is the notion of general purpose language. Of course
Ada is such a thing whereas SQL, XML and HTML are not. SQL has Module
for extending C and Ada with it self. Of course when we use SQL, etc.
strings in an Ada program we're using these languages, but that does not
make them programming languages. We also often use English strings in an
Ada program e.g. for dialog boxes. That is a kind of multilingual
programming, but I would say 'proper' multilingual programming is when
you combine multiple *general purpose*, or 'operational' languages.
Systems often combine Ada and C. I remember writing a system with Ada,
C, Prolog, SQL, CGI (HTTP) and HTML. And of course there are the ORBs.

As I said, just rambling, but sometimes I feel the need to discuss these
higher concepts, to check if something has changed there with the
continuing appearance of new 'technologies'. I guess no changes since
last time I looked. Also, any XML appraisal touches a sensitive button
in me. I used to be attracted to XML. Now I find it horrible. Just today
I got this feeling independently. I was reading a PhD thesis by
Parmentier, where he transforms from BibTeX format to XML for "ease of
processing". He shows an entry in the the two formats side by side. The
contrast in readability is stunning: BiTeX very readable, XML completely
unreadable. And (La)TeX is not usually particularly readable. Also, you
could see right away that an automaton for parsing the BibTeX would be
much simpler to right than for the XML, and I bet more simpler to do it
e.g. in Ada that to write the XSLT for the XML (and assembling and all
the required tools). XML is the major hoax of two millenia.

Re: Nature of XML (ramblings)

[Georg Bauhaus]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
 
: As I said, just rambling, but sometimes I feel the need to discuss these
: higher concepts, to check if something has changed there with the
: continuing appearance of new 'technologies'. I guess no changes since
: last time I looked. Also, any XML appraisal touches a sensitive button
: in me. I used to be attracted to XML. Now I find it horrible. Just today
: I got this feeling independently. I was reading a PhD thesis by
: Parmentier, where he transforms from BibTeX format to XML for "ease of
: processing".

And not ease of reading.

: He shows an entry in the the two formats side by side. The
: contrast in readability is stunning: BiTeX very readable, XML completely
: unreadable. And (La)TeX is not usually particularly readable. Also, you
: could see right away that an automaton for parsing the BibTeX would be
: much simpler to right than for the XML, and I bet more simpler to do it
: e.g. in Ada that to write the XSLT for the XML (and assembling and all
: the required tools). XML is the major hoax of two millenia.

XML is certainly a very much misunderstood language.

(Is a parser for Ada easier than a parser for Oberon?
Should we be writing programs in Oberon for that reason?)
If you read bibliographies without the help of a computer providing
a view suitable for humans, you should at least switch to SGML
with SHORTTAG, and maybe OMITTAG. All this has been known when old
SGML was standardised, XML is in parts a manifest of advances in
editor construction -- users are supposed not to see it.

Re: Nature of XML

[Robert C. Leif]

It depends on what one means as XML. XSL, XSL Fo, and XForms have
methods (subprograms). Therefore, I would consider them to be
rudimentary, specialized programming languages. Since they can work
with schema, they effectively use the equivalent of Ada data-types.
The real trick would be to augment the XML "functions" with in, in
out, out attributes or elements.
Bob Leif 
----------------------------------------------
"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<e4ydnf8STO_5mYbdRVn-hA@comcast.com>...
> Georg Bauhaus wrote:
> 
> > Marius Amado Alves <maa@liacc.up.pt> wrote:
> > : Programming languages have semantics. XML does not. Simple, no?
> > 
> > If an IDREF attribute implies that an attribute value must
> > refer to an element with the corresponding id, is that syntax?
> 
> Guys, try not to get carried away!  In the post that started this 
> unending thread I said: "I don't know if you consider SQL, XML, and HTML 
> as a programming languages, but recently I have written a lot of all three."
> 
> Should I have said I don't know ... and I don't care. ;-)  I consider 
> writing SQL and HTML as part of a database interface program as 
> programming.  The fact that the SQL and HTML may be in quotes inside an 
> Ada subprogram is not really relevant. (They count as non-comment source 
> lines of code.) On the other hand, if I am creating a static web page in 
> HTML I don't consider that activity to be programming.  If you have a 
> different definition you use, fine.

Re: Nature of XML

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:
: It depends on what one means as XML.
: XSL,

o.K.

: XSL Fo,

Is there any kind of programming in specifying formatting objects?

: and XForms

o.K., mostly XPath+  predicates.

: have
: methods (subprograms).
: Therefore, I would consider them to be
: rudimentary, specialized programming languages.

XSL is not exactly rudimentary I think. It is an extensible "functional" 
programming language, i.e. only in mode parameters
(with overloading of function names, BTW).

<template match="foo"                            > ...
<template match="foo"            mode="flavoured"> ...
<template match="foo[@tag='T0']"                 > ...
<template match="foo[@tag='T1']"                 > ...
<template match="foo[@tag='T1']" mode="flavoured"> ...
<template name="foo" >
...

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Ole-Hjalmar Kristensen wrote:

>>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes:
>     JC> Warren W. Gay VE3WWG wrote:
>     >> Jeffrey Carter wrote:
>     >>> One standard POSIX-Ada binding
>     >> Impossible. Some UNIces provide some API structure members,
>     >> while others don't, or provide something else again. Yes,
>     >> you can dumb it down to a "standard" (or omit non-universal
>     >> functionality), but by doing so you throw away functionality.
>     >> I find that unacceptable.
>     JC> There is a standard POSIX-Ada binding (Florist is an implementation of
>     JC> this standard)  to the  POSIX standard. If  you want something  not in
>     JC> this standard, obviously  you're going to have to  provide it yourself
>     JC> on some platforms.  If you're on a platform  that doesn't provide some
>     JC> of the  functionality, then it's not  a POSIX system.  In neither case
>     JC> are you dealing with different versions of POSIX.
> 
> Which does not matter if what you are doing is maintaining a program
> which is running on multiple platforms and is compiled with multiple
> compilers. The program has to run even if the platform does not
> support a standard package like Florist. How many platforms is Florist
> really available on, btw.? 

Listen, C programmers do this thing every day. "If some feature
is available, then do it this way, else do 'it' in a more
inferior way".

Just because you write to "any platform", doesn't mean you
have to dumb down the code for all platforms. If one O/S gives
me an efficient way to do something, and I care to take
advantage of this, then I can do just that with conditional
compilation.

By saying that an Ada program would never do that, has again
condemned it to be inferior in some cases (which, IMO,
is an entirely unnecessary limitation).

> What matters is how do I do this while keeping the code readable and
> maintainable.

Of course! I could argue that conditional compilation may
make it clearer where I'd run into portability problems
on some platforms, because the different offending code
is right in front of me (vs sitting somewhere else,
unexplored).

> One way to combat the combinatorial explosion of platforms * compiler
> * library is to explicitly test for the features of the environment
> you really need to know, not assume something because of a particular
> platform/compiler. This is the approach typically used by projects
> using the 'configure' tool.

Yes, and that ./configure tool generates files that drive
a conditional compile process. But no amount of Ada if
statements can help you with conditionally with-ing certain
packages, and conditional code that have to distinguish
between the code that must work around differences and
limitations, and deal with optional members of records etc.

But this horse has been beaten to death already in this
thread, and I see no reason to expand upon it again.

> I would really like to have some standard configuration tool which
> could take such parameters as input and produce a version of the
> system tailored to the environment in which it is to be compiled and
> run. 

This is just a high level statement of what has already
been discussed. So how are you going to _implement_ this?

   1. Preprocessing?
   2. Conditional compilation?
   3. Generate source code?

The problem with #3 (which is what you seem to be suggesting)
is that when there is a compile time problem, or a maintenance
issue, you end up wanting to work with the generated files. BUT,
you know you have to remember to work with the original INPUT
files, that were used to generate it. #3 actually describes
the gnatprep case, and there are options to make it easier
to work this way (eg. an option that relates the line #
back to the one in the original input file). But every once
in a while, I end up modifying the wrong file by accident.
I hate this. Conditional compilation would be a better
solution for the developer because it is less error prone,
and it is more natural.

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

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
...
> I hate this. Conditional compilation would be a better
> solution for the developer because it is less error prone,
> and it is more natural.

I couldn't disagree. Now, try to figure out a natural way to express such
conditional compilation in Ada. I can't (and I've tried to solve this
problem for 20 years.) If you don't have a non-ugly way to solve the
problem, the chances of anything being done about it are zero.

There have been similar issues with similar resolutions in the history of
Ada. For instance, you'd can't usefully redefine "*" and "/" on fixed point
types in Ada 95. The problem is well known, but without a solution, it was
never fixed in Ada 95. Tucker recently proposed a solution that appears to
work, so we'll probably fix this in Ada 200Y.

But without a workable solution, there can be no new feature. (And, because
not everyone finds this necessary, the solution needs to be clean and
well-integrated into the rest of the language.)

                    Randy.

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
> ....
>>I hate this. Conditional compilation would be a better
>>solution for the developer because it is less error prone,
>>and it is more natural.
> 
> I couldn't disagree. Now, try to figure out a natural way to express such
> conditional compilation in Ada. I can't (and I've tried to solve this
> problem for 20 years.) If you don't have a non-ugly way to solve the
> problem, the chances of anything being done about it are zero.

I agree that an elegant solution should always be sought.
Especially if you are looking at the far reaching consequences
of "language changes".  But if this problem has existed for
20 years and no solution has come to light, then maybe it
is time to consider a less elegant solution?

> But without a workable solution, there can be no new feature. (And, because
> not everyone finds this necessary, the solution needs to be clean and
> well-integrated into the rest of the language.)
> 
>                     Randy.

I don't think it is a matter of "no solution exists". It is a
matter of "elegancy" as you have already stated. No one here
has come out and said "it won't work". There are simply biases
against the approaches, which vary from "Ada doesn't do it that
way" to "it's ugly". But solutions do exist.

To satisfy both camps, I would make the use of such a feature
something you have to enable (by compile option). Then by
default, you would get what you have always had.

The objection of course is that if some developers start to use
it, then someday you might have to maintain code that uses it.
But for shops that can mandate tools and conventions, you can
mandate against its use anyway. This brings us back to a matter
of preference.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Dmitry A. Kazakov]

On Tue, 27 Jan 2004 16:41:50 -0500, "Warren W. Gay VE3WWG"
<warren@ve3wwg.tk> wrote:

>Randy Brukardt wrote:
>> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
>> news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
>> ....
>>>I hate this. Conditional compilation would be a better
>>>solution for the developer because it is less error prone,
>>>and it is more natural.
>> 
>> I couldn't disagree. Now, try to figure out a natural way to express such
>> conditional compilation in Ada. I can't (and I've tried to solve this
>> problem for 20 years.) If you don't have a non-ugly way to solve the
>> problem, the chances of anything being done about it are zero.
>
>I agree that an elegant solution should always be sought.
>Especially if you are looking at the far reaching consequences
>of "language changes".  But if this problem has existed for
>20 years and no solution has come to light, then maybe it
>is time to consider a less elegant solution?

Conditional compilation is not less elegant it is disastrous. Ada
design is based on contracts. A conditional compilation contradicts to
this very principle. What kind of contract has Foo?

#if ...
procedure Foo (X : in out Integer);
#else
type Foo is record
   X : String;
end record;
#end if

IMO the solution is abstract packages.

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

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:

> On Tue, 27 Jan 2004 16:41:50 -0500, "Warren W. Gay VE3WWG"
> <warren@ve3wwg.tk> wrote:
>>Randy Brukardt wrote:
>>>"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
>>>news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
>>>....
> Conditional compilation is not less elegant it is disastrous. Ada
> design is based on contracts. A conditional compilation contradicts to
> this very principle. What kind of contract has Foo?
> 
> #if ...
> procedure Foo (X : in out Integer);
> #else
> type Foo is record
>    X : String;
> end record;
> #end if
> 
> IMO the solution is abstract packages.

I have presented the case as far as I have energy for it.
The discussions here have lead me to conclude that I'll
have to blaze my own trail (with help from gnatprep), as
I have always had to do. I never expected much
agreement on this anyway. It was however, interesting to
hear that I am not the only one to share this opinion.

Having said my piece on this, and I'm signing off.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:KVARb.52238$Kg6.385745@news20.bellglobal.com...
> Randy Brukardt wrote:
...
> > I couldn't disagree. Now, try to figure out a natural way to express
such
> > conditional compilation in Ada. I can't (and I've tried to solve this
> > problem for 20 years.) If you don't have a non-ugly way to solve the
> > problem, the chances of anything being done about it are zero.
>
> I agree that an elegant solution should always be sought.
> Especially if you are looking at the far reaching consequences
> of "language changes".  But if this problem has existed for
> 20 years and no solution has come to light, then maybe it
> is time to consider a less elegant solution?

Updating the Ada standard is as much a political process as it is a
technical one. In this case, I and others tried to get a solution added to
Ada 95. There was too much opposition at that time. Given that nothing has
changed, I'd expect the same result if the same solutions are presented.
Indeed, we have a meta-rule that we won't even waste time on issues decided
during Ada 95's development unless there is significant new information.
(The few that have come up, like 'in out' for functions, have ended up with
precisely the same results as the last time - even with new information.)

The only new information that I could think of that would help here would be
an elegant solution. Certainly, the fact that the problem exists - or its
scope - haven't changed a bit in the last 12 years. I'm going to spend my
time on issues that have a chance to be approved (like a limited containers
library), not tilting at windmills. (I've done enough of that in the last
couple of years.)

Otherwise, you'll get have to use a non-standard solution like Gnatprep.

                Randy.

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:KVARb.52238$Kg6.385745@news20.bellglobal.com...
>>Randy Brukardt wrote:
> ....
>>>I couldn't disagree. Now, try to figure out a natural way to express
> such
>>>conditional compilation in Ada. I can't (and I've tried to solve this
>>>problem for 20 years.) If you don't have a non-ugly way to solve the
>>>problem, the chances of anything being done about it are zero.
>>
>>I agree that an elegant solution should always be sought.
>>Especially if you are looking at the far reaching consequences
>>of "language changes".  But if this problem has existed for
>>20 years and no solution has come to light, then maybe it
>>is time to consider a less elegant solution?
> 
> Updating the Ada standard is as much a political process as it is a
> technical one. In this case, I and others tried to get a solution added to
> Ada 95. There was too much opposition at that time. Given that nothing has
> changed, I'd expect the same result if the same solutions are presented.
> Indeed, we have a meta-rule that we won't even waste time on issues decided
> during Ada 95's development unless there is significant new information.
> (The few that have come up, like 'in out' for functions, have ended up with
> precisely the same results as the last time - even with new information.)

I can only agree with this. Please understand, that this was
not a discussion that "we should include X in 200Y". That is
too much further down the road. The discussion stemmed from
the wider context of "Why is Ada Unpopular?"  I then wanted
to discuss the merits of addressing conditional compilation.

To say that it was ready for a proposal, would be naive ;-)

But the discussion here was useful. In my mind, unless
the general concensous changes, there does not seem to be
an acceptable solution to the majority on this topic.
But as I said in another post, it was interesting to
note from others that agreed there was a need to be
addressed there.

> The only new information that I could think of that would help here would be
> an elegant solution. Certainly, the fact that the problem exists - or its
> scope - haven't changed a bit in the last 12 years. 

To this I was only suggesting that if an elegant solution
does not emerge in 12-20 years, then perhaps there is
none. And if this is the conclusion, then perhaps it is
time to lower the "standard" a bit, to address practical
needs.

 > I'm going to spend my
> time on issues that have a chance to be approved (like a limited containers
> library), not tilting at windmills. (I've done enough of that in the last
> couple of years.)
> 
> Otherwise, you'll get have to use a non-standard solution like Gnatprep.
> 
>                 Randy.

A sensible thing to do. ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Randy Brukardt wrote:

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

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

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

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

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

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

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

> Ole-Hjalmar Kristensen wrote:
> 
> >>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes:
> >     JC> Warren W. Gay VE3WWG wrote:
> >     >> Jeffrey Carter wrote:
> >     >>> One standard POSIX-Ada binding
> >     >> Impossible. Some UNIces provide some API structure members,
> >     >> while others don't, or provide something else again. Yes,
> >     >> you can dumb it down to a "standard" (or omit non-universal
> >     >> functionality), but by doing so you throw away functionality.
> >     >> I find that unacceptable.
> >     JC> There is a standard POSIX-Ada binding (Florist is an implementation of
> >     JC> this standard)  to the  POSIX standard. If  you want something  not in
> >     JC> this standard, obviously  you're going to have to  provide it yourself
> >     JC> on some platforms.  If you're on a platform  that doesn't provide some
> >     JC> of the  functionality, then it's not  a POSIX system.  In neither case
> >     JC> are you dealing with different versions of POSIX.
> > Which does not matter if what you are doing is maintaining a program
> > which is running on multiple platforms and is compiled with multiple
> > compilers. The program has to run even if the platform does not
> > support a standard package like Florist. How many platforms is Florist
> > really available on, btw.?
> 
> Listen, C programmers do this thing every day. "If some feature
> is available, then do it this way, else do 'it' in a more
> inferior way".
> 

For the past 20 years, I think about 90% of the code I have been writing
is C or C++, so please cool down...
I think you may have misread my answer. The sentence 
"Which does not matter if what you are doing is maintaining..." is answer to
"There is a standard POSIX-Ada binding...".

To re-state my position: It does not matter that there is a standard POSIX-Ada
binding if I am maintaining a program on a platform where this standard 
POSIX binding does not exist. I still have to get my system working, somehow.
The problem does not go away because of this standard binding.

> Just because you write to "any platform", doesn't mean you
> have to dumb down the code for all platforms. If one O/S gives
> me an efficient way to do something, and I care to take
> advantage of this, then I can do just that with conditional
> compilation.
> 
> By saying that an Ada program would never do that, has again
> condemned it to be inferior in some cases (which, IMO,
> is an entirely unnecessary limitation).
> 
> > What matters is how do I do this while keeping the code readable and
> > maintainable.
> 
> Of course! I could argue that conditional compilation may
> make it clearer where I'd run into portability problems
> on some platforms, because the different offending code
> is right in front of me (vs sitting somewhere else,
> unexplored).
> 

I never said conditional compilation was bad.

> > One way to combat the combinatorial explosion of platforms * compiler
> > * library is to explicitly test for the features of the environment
> > you really need to know, not assume something because of a particular
> > platform/compiler. This is the approach typically used by projects
> > using the 'configure' tool.
> 
> Yes, and that ./configure tool generates files that drive
> a conditional compile process. But no amount of Ada if
> statements can help you with conditionally with-ing certain
> packages, and conditional code that have to distinguish
> between the code that must work around differences and
> limitations, and deal with optional members of records etc.
> 

I agree. My point was simply that there is an alternative to test for
compiler/platform.

> But this horse has been beaten to death already in this
> thread, and I see no reason to expand upon it again.
> 
> > I would really like to have some standard configuration tool which
> > could take such parameters as input and produce a version of the
> > system tailored to the environment in which it is to be compiled and
> > run.
> 
> This is just a high level statement of what has already
> been discussed. So how are you going to _implement_ this?
> 
>    1. Preprocessing?
>    2. Conditional compilation?
>    3. Generate source code?
> 
> The problem with #3 (which is what you seem to be suggesting)
> is that when there is a compile time problem, or a maintenance
> issue, you end up wanting to work with the generated files. BUT,
> you know you have to remember to work with the original INPUT
> files, that were used to generate it. #3 actually describes
> the gnatprep case, and there are options to make it easier
> to work this way (eg. an option that relates the line #
> back to the one in the original input file). But every once
> in a while, I end up modifying the wrong file by accident.
> I hate this. Conditional compilation would be a better
> solution for the developer because it is less error prone,
> and it is more natural.
> 
> -- 
> Warren W. Gay VE3WWG
> http://ve3wwg.tk
> 

It's been a while since I worked actively with CM systems, but basically 
the idea is that you select the variant you want to work on, make your
changes, and then commit your changes to the system to integrate them with
the other variants. Yes, you easily get into problems when wanting to work
with generated files. (Unless the compiler is integrated with the CM
system in such a way that the output of the compiler is related to the 
original file, and you do not see the intermediate file at all).

What you do with a conditional compilation system is to code the exact same
information as the CM system needs to keep internally into the source code.
As you point out, sometimes it may not be desirable to hide this information,
other times it may be for the sake of easily seeing the variant you are
working on.

Please observe that I am not arguing against conditional compilation.
Given the state of the art, it may well be the best solution in a number
of circumstances.

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

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Ole-Hjalmar Kristensen wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:
>>Ole-Hjalmar Kristensen wrote:
>>>>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes:
>>>
>>>    JC> Warren W. Gay VE3WWG wrote:
>>>    >> Jeffrey Carter wrote:
>>>    >>> One standard POSIX-Ada binding
>>>    >> Impossible. Some UNIces provide some API structure members,
>>>    >> while others don't, or provide something else again. Yes,
>>>    >> you can dumb it down to a "standard" (or omit non-universal
>>>    >> functionality), but by doing so you throw away functionality.
>>>    >> I find that unacceptable.
>>>    JC> There is a standard POSIX-Ada binding (Florist is an implementation of
>>>    JC> this standard)  to the  POSIX standard. If  you want something  not in
>>>    JC> this standard, obviously  you're going to have to  provide it yourself
>>>    JC> on some platforms.  If you're on a platform  that doesn't provide some
>>>    JC> of the  functionality, then it's not  a POSIX system.  In neither case
>>>    JC> are you dealing with different versions of POSIX.
>>>Which does not matter if what you are doing is maintaining a program
>>>which is running on multiple platforms and is compiled with multiple
>>>compilers. The program has to run even if the platform does not
>>>support a standard package like Florist. How many platforms is Florist
>>>really available on, btw.?
>>
>>Listen, C programmers do this thing every day. "If some feature
>>is available, then do it this way, else do 'it' in a more
>>inferior way".
> 
> For the past 20 years, I think about 90% of the code I have been writing
> is C or C++, so please cool down...

I am calmer today ;-)

> I think you may have misread my answer. The sentence 
> "Which does not matter if what you are doing is maintaining..." is answer to
> "There is a standard POSIX-Ada binding...".
> 
> To re-state my position: It does not matter that there is a standard POSIX-Ada
> binding if I am maintaining a program on a platform where this standard 
> POSIX binding does not exist. I still have to get my system working, somehow.
> The problem does not go away because of this standard binding.

Ok, yes. And my original point was that Florist does not
cover all of your POSIX-like needs anyway. To get equal
footing with C/C++ environments, you need Ada bindings to
all of the shared libraries that GNU/Linux provides
for example. As you understand, this is where things
get necessarily ugly.

>>>What matters is how do I do this while keeping the code readable and
>>>maintainable.
>>
>>Of course! I could argue that conditional compilation may
>>make it clearer where I'd run into portability problems
>>on some platforms, because the different offending code
>>is right in front of me (vs sitting somewhere else,
>>unexplored).
> 
> I never said conditional compilation was bad.

I'll reiterate that readable code is first on my list
also. But I would like the choice to forgo that for
thin bindings. I don't there there is much justification
for it outside of thin bindings.

...
> Please observe that I am not arguing against conditional compilation.
> Given the state of the art, it may well be the best solution in a number
> of circumstances.

Which was really my thrust in this thread. If an elegant
solution has not emerged, then it is time to look at the
"requirments" for such. One of them is suspect ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Jeffrey Carter wrote:
>>> One standard POSIX-Ada binding 
>>
>> Impossible. Some UNIces provide some API structure members,
>> while others don't, or provide something else again. Yes,
>> you can dumb it down to a "standard" (or omit non-universal
>> functionality), but by doing so you throw away functionality.
>> I find that unacceptable.
> 
> There is a standard POSIX-Ada binding (Florist is an implementation of 
> this standard) to the POSIX standard. If you want something not in this 
> standard, obviously you're going to have to provide it yourself on some 
> platforms. If you're on a platform that doesn't provide some of the 
> functionality, then it's not a POSIX system. In neither case are you 
> dealing with different versions of POSIX.

So your message to the Ada world is that if Florist
can't give you access to that O/S feature, then you
should be using C?  That's a progressive Ada answer. ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> So your message to the Ada world is that if Florist
> can't give you access to that O/S feature, then you
> should be using C?  That's a progressive Ada answer. ;-)

It's impossible to correct willful ignorance. You claimed you had to 
deal with 10 different versions of "POSIX". My answer is that there is 
exactly one POSIX. If you're after things not part of POSIX, that has 
nothing to do with POSIX.

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

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> So your message to the Ada world is that if Florist
>> can't give you access to that O/S feature, then you
>> should be using C?  That's a progressive Ada answer. ;-)
> 
> It's impossible to correct willful ignorance. You claimed you had to 
> deal with 10 different versions of "POSIX". My answer is that there is 
> exactly one POSIX. If you're after things not part of POSIX, that has 
> nothing to do with POSIX.

Fine: read "POSIX-like" then. Everyone wants to be
a lawyer ;-)

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

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:e9gRb.4112$qU3.177385@news20.bellglobal.com...
> Jeffrey Carter wrote:
>
> > Warren W. Gay VE3WWG wrote:
> >
> >> 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. :(
> >
> > One standard POSIX-Ada binding
>
> Impossible. Some UNIces provide some API structure members,
> while others don't, or provide something else again. Yes,
> you can dumb it down to a "standard" (or omit non-universal
> functionality), but by doing so you throw away functionality.
> I find that unacceptable.

What is the point of having that functionality? Any code depending on it is
by definition not portable. If you can't abstract a reasonable facimile of
it, it probably isn't worth using. Otherwise, it will poison your whole
application, and lock it to a few targets.

What Claw does for features that aren't available on the current target is
to raise Not_Supported_Error (which hopefully the caller can do something
useful with, such as fall back to something that is supported). Thus, the
interface is as rich as possible. That probably won't work everywhere, but
if you want portability, you have to eliminate functionality that is
available only a few targets. (Which is why embedded code pretty much cannot
be portable by definition.)

               Randy.

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:e9gRb.4112$qU3.177385@news20.bellglobal.com...
>>Jeffrey Carter wrote:
>>>Warren W. Gay VE3WWG wrote:
>>>>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. :(
>>>
>>>One standard POSIX-Ada binding
>>
>>Impossible. Some UNIces provide some API structure members,
>>while others don't, or provide something else again. Yes,
>>you can dumb it down to a "standard" (or omit non-universal
>>functionality), but by doing so you throw away functionality.
>>I find that unacceptable.
> 
> What is the point of having that functionality? Any code depending on it is
> by definition not portable. 

Performance!

Some platforms for instance support asynchronous I/O.
Some with bugs, others not at all. If you are writing
servers, that BTW are very performance sensitive, then
if you can determine that asynch I/O works properly
(and well) on a given platform, then you're going to
use it! Anything less is inferior.

For platforms where asynch I/O is defective or just
plain busted, you'll do things the plain old way you
always did it (with a corresponding hit in performance).

It doesn't take much imagination to see the need for
this type of thing.

> What Claw does for features that aren't available on the current target is
> to raise Not_Supported_Error (which hopefully the caller can do something
> useful with, such as fall back to something that is supported). 

That will really help performance. Let's add some unnecessary
exceptions!

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

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Some platforms for instance support asynchronous I/O.
> Some with bugs, others not at all. If you are writing
> servers, that BTW are very performance sensitive, then
> if you can determine that asynch I/O works properly
> (and well) on a given platform, then you're going to
> use it! Anything less is inferior.
> 
> For platforms where asynch I/O is defective or just
> plain busted, you'll do things the plain old way you
> always did it (with a corresponding hit in performance).

If the performance on these latter systems is unacceptable, then you 
don't have a solution for those systems. If it is acceptable, then you 
have no portability problem, since you can use the plain old way on all 
systems and achieve acceptable performance. Either way you have no 
problem with or without a preprocessor.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

Jeffrey Carter <spam@spam.com> writes:

> Warren W. Gay VE3WWG wrote:
> 
> > Some platforms for instance support asynchronous I/O.
> > Some with bugs, others not at all. If you are writing
> > servers, that BTW are very performance sensitive, then
> > if you can determine that asynch I/O works properly
> > (and well) on a given platform, then you're going to
> > use it! Anything less is inferior.
> > For platforms where asynch I/O is defective or just
> > plain busted, you'll do things the plain old way you
> > always did it (with a corresponding hit in performance).
> 
> If the performance on these latter systems is unacceptable, then you
> don't have a solution for those systems. If it is acceptable, then you
> have no portability problem, since you can use the plain old way on
> all systems and achieve acceptable performance. Either way you have no
> problem with or without a preprocessor.

Ever heard about competing products?

> 
> -- 
> Jeff Carter
> "Son of a window-dresser."
> Monty Python & the Holy Grail
> 12
> 

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

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:a%ARb.52241$Kg6.386478@news20.bellglobal.com...
> Randy Brukardt wrote:
...
> > What is the point of having that functionality? Any code depending on it
is
> > by definition not portable.
>
> Performance!
>
> Some platforms for instance support asynchronous I/O.
> Some with bugs, others not at all. If you are writing
> servers, that BTW are very performance sensitive, then
> if you can determine that asynch I/O works properly
> (and well) on a given platform, then you're going to
> use it! Anything less is inferior.

Truly high-performance applications are by definition, not portable. The
parts that aren't high-performance might be sharable, but again, this is a
larger granularity than conditional compilation would be good for. Taking
your example, you need to use tasks to make asynch. I/O work. If you don't
have asynch. I/O, you probably don't want the tasks, either (because they
have a substantial overhead in most cases), especially as the I/O may very
well block all of the tasks. So large parts of the code will need to be
different.

...
> > What Claw does for features that aren't available on the current target
is
> > to raise Not_Supported_Error (which hopefully the caller can do
something
> > useful with, such as fall back to something that is supported).
>
> That will really help performance. Let's add some unnecessary
> exceptions!

Different problem. We're trying to get the code to run unmodified on as many
targets as possible. Having it being self-adapting is very valuable in that
aim. (Hopefully, even the binarys can run on most targets unmodified.)

                             Randy.

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

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

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:a%ARb.52241$Kg6.386478@news20.bellglobal.com...
> > Randy Brukardt wrote:
> ...
> > > What is the point of having that functionality? Any code depending on it
> is
> > > by definition not portable.
> >
> > Performance!
> >
> > Some platforms for instance support asynchronous I/O.
> > Some with bugs, others not at all. If you are writing
> > servers, that BTW are very performance sensitive, then
> > if you can determine that asynch I/O works properly
> > (and well) on a given platform, then you're going to
> > use it! Anything less is inferior.
> 
> Truly high-performance applications are by definition, not portable. The
> parts that aren't high-performance might be sharable, but again, this is a
> larger granularity than conditional compilation would be good for. Taking
> your example, you need to use tasks to make asynch. I/O work. If you don't
> have asynch. I/O, you probably don't want the tasks, either (because they
> have a substantial overhead in most cases), especially as the I/O may very
> well block all of the tasks. So large parts of the code will need to be
> different.

You do not need tasks if you have asynchronous IO like the mechanisms available 
under POSIX, Solaris or Windows. You can use tasks with asynchronous IO of course,
but you do not need them.

If you do not have asynchroous IO you definitely want to use tasks, precisely
because on many (most?) platforms doing IO from one task will not block
other tasks.

Usually you get better performance with async IO than with using tasks, because
there usually will be more internal locks set in the OS, effectively stopping
you from executing multiple IO operations in parallel as efficiently as with
async IO.

> 
> ...
> > > What Claw does for features that aren't available on the current target
> is
> > > to raise Not_Supported_Error (which hopefully the caller can do
> something
> > > useful with, such as fall back to something that is supported).
> >
> > That will really help performance. Let's add some unnecessary
> > exceptions!
> 
> Different problem. We're trying to get the code to run unmodified on as many
> targets as possible. Having it being self-adapting is very valuable in that
> aim. (Hopefully, even the binarys can run on most targets unmodified.)
> 
>                              Randy.
> 

Yes, but he is trying to get the code to run unmodified on many platforms by 
making it adaptive at compile time. Same goal, different means.

> 
> 
> 

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

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:a%ARb.52241$Kg6.386478@news20.bellglobal.com...
>>Randy Brukardt wrote:
> ....
>>>What is the point of having that functionality? Any code depending on it
> is
>>>by definition not portable.
>>
>>Performance!
>>
>>Some platforms for instance support asynchronous I/O.
>>Some with bugs, others not at all. If you are writing
>>servers, that BTW are very performance sensitive, then
>>if you can determine that asynch I/O works properly
>>(and well) on a given platform, then you're going to
>>use it! Anything less is inferior.
> 
> Truly high-performance applications are by definition, not portable. 

This is a "head in the sand" argument, if I may say so. C/C++
code does this every day. To say that Ada shouldn't or needn't
is statement of denial. That is my only point.

>>>useful with, such as fall back to something that is supported).
>>
>>That will really help performance. Let's add some unnecessary
>>exceptions!
> 
> 
> Different problem. We're trying to get the code to run unmodified on as many
> targets as possible. Having it being self-adapting is very valuable in that
> aim. (Hopefully, even the binarys can run on most targets unmodified.)
> 
>                              Randy.

This is like probing hardware when Linux boots. Hardware is
getting better, so that probes don't hang etc., but this adds
time to the boot process, and for some hardware configs, is
unstable and leads to hangs.

Testing a version of a Linux kernel for a working asynch I/O
API or not, seems much like the same thing. Its ugly, its
dangerous and leads to more problems than it solves. It is
much better to work all of that out at compile time, and never
deal with it again.

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

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:qQbSb.57519$Kg6.643416@news20.bellglobal.com...
> Randy Brukardt wrote:
...
> > Different problem. We're trying to get the code to run unmodified on as
many
> > targets as possible. Having it being self-adapting is very valuable in
that
> > aim. (Hopefully, even the binarys can run on most targets unmodified.)
> >
>
> This is like probing hardware when Linux boots. Hardware is
> getting better, so that probes don't hang etc., but this adds
> time to the boot process, and for some hardware configs, is
> unstable and leads to hangs.
>
> Testing a version of a Linux kernel for a working asynch I/O
> API or not, seems much like the same thing. Its ugly, its
> dangerous and leads to more problems than it solves. It is
> much better to work all of that out at compile time, and never
> deal with it again.

I would be likely to base the decision whether or not to use a feature (say
asynch I/O) on the version information provided by the kernel. (I'm
presuming that Linux isn't so primitive that it doesn't have
version/distribution/supported features queries.) Plus, of course, lots of
upfront testing. Thus, the same info that you're using at compile-time would
be used to choose which implementation to use.

I readily admit that doing this is easier on Windows, where the number of
versions is somwhat bounded, and it's possible to get information (not
always right, of course) in one place. (Window emulators always try to match
the real thing as closely as possible, so they tend to be less incompatible
than the different versions of the real thing...)

                      Randy.

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Develop some Open Sourced code in
> without gnatprep, and we'll see how portable it is ;-)

Here's some Q&D open source, GPLed code to solve the following 
requirments, assuming that the proposed Ada.Directories is not 
available: List the names of all the files in the current directory, 
sorted in String order (that is, the order defined by "<" for String), 
one per line.

Sure, this is a simple problem, but I don't have the time to work a 
significant problem. If you think a more complex problem should be used, 
  provide the problem and your solution to it.

All the OS and compiler dependencies are in the subunit Fill. I have 
provided a body for fill that works with GNAT 3.15p on any OS GNAT 
supports (because GNAT has already hidden the details of doing this on 
different OSes in GNAT.OS_Lib). Provide a different body for Fill for 
another compiler or OS, and explain why you need a preprocessor to do so.

It's possible to push the OS and compiler dependencies down even further 
in this example, but I don't think it's necessary.

Warning: Over 100 LOC follows. I apologize for the long posting, but am 
unable to respond to the challenge in a timely manner otherwise. Feel 
free to skip it if you like. I've used an 80-character line length, but 
some lines may wrap.

-- File Lister: a sample open-source project without a preprocessor

-- Copyright (C) 2004 by Jeffrey R. Carter

-- This is free software; you can redistribute it and/or modify it under
-- terms of the GNU General Public License as published by the Free Software
-- Foundation; either version 2, or (at your option) any later version.
-- This software is distributed in the hope that it will be useful, but WITH
-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
-- for more details. Free Software Foundation, 59 Temple Place - Suite
-- 330, Boston, MA 02111-1307, USA.

-- The root package for the File Lister software.

package File_Lister is
    pragma Pure;
end File_Lister;

-- The list must be instantiated at the library level because it uses a
-- controlled type.
-- Print_One must be declared here so we can pass its 'access to the list's
-- Iterate procedure.

with Ada.Strings.Unbounded;
with PragmARC.Assignment;
with PragmARC.List_Unbounded;
package File_Lister.Lists is
    procedure Assign is new PragmARC.Assignment
    (Element => Ada.Strings.Unbounded.Unbounded_String);

    package File_List is new PragmARC.List_Unbounded
    (Element => Ada.Strings.Unbounded.Unbounded_String);

    procedure Print_One
       (Item     : in out Ada.Strings.Unbounded.Unbounded_String;
        Context  : in out File_List.Context_Data'Class;
        Pos      : in     File_List.Position;
        Continue :    out Boolean);
    -- Print Item to standard output, followed by a line terminator.
end File_Lister.Lists;

with Ada.Text_IO;
package body File_Lister.Lists is
    procedure Print_One
       (Item     : in out Ada.Strings.Unbounded.Unbounded_String;
        Context  : in out File_List.Context_Data'Class;
        Pos      : in     File_List.Position;
        Continue :    out Boolean)
    is
       use Ada.Strings.Unbounded;
       use Ada.Text_IO;
    begin -- Print_One
       Put_Line (Item => To_String (Item));
       Continue := True;
    end Print_One;
end File_Lister.Lists;

-- Main procedure for File Lister

with Ada.Strings.Unbounded;
with File_Lister.Lists;
procedure File_Lister.Program is
    use File_Lister.Lists;

    procedure Fill (List : in out File_List.Handle) is separate;
    -- Fill List with information about the files in the current
    -- directory.

    List  : File_List.Handle;
    Dummy : File_List.Context_Data;
begin -- File_Lister.Program
    Fill (List => List);
    List.Sort (Less_Than => Ada.Strings.Unbounded."<"'access);
    List.Iterate (Action => Print_One'access, Context => Dummy);
end File_Lister.Program;

-- File_Lister.Program.Fill: version for GNAT 3.15p on all platforms.
-- Replace to accomodate other platforms or compilers.

with Ada.Strings.Unbounded;
with GNAT.Directory_Operations;
separate (File_Lister.Program)
procedure Fill (List : in out File_List.Handle) is
    use Ada.Strings.Unbounded;
    use GNAT.Directory_Operations;

    Dir  : Dir_Type;
    Name : String (1 .. 1_000);
    Last : Natural;
    Info : Unbounded_String;
    Pos  : File_List.Position;
begin -- Fill
    Open (Dir => Dir, Dir_Name => Get_Current_Dir);

    Get_All : loop
       Read (Dir => Dir, Str => Name, Last => Last);

       exit Get_All when Last <= 0;

       Info := To_Unbounded_String (Name (Name'First .. Last) );
       List.Append (Item => Info, After => List.Last, New_Pos => Pos);
    end loop Get_All;

    Close (Dir => Dir);
end Fill;

I've created lists of Unbounded_Strings exceeding 3,000 strings without 
any memory problems on a Win98 machine with 64 KB of memory, so I doubt 
there are many situations where this program will have memory problems. 
Providing error handling is left as an exercise for the reader.

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

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
>> Develop some Open Sourced code in
>> without gnatprep, and we'll see how portable it is ;-)
> 
> Here's some Q&D open source, GPLed code to solve the following 
> requirments, assuming that the proposed Ada.Directories is not 
> available: List the names of all the files in the current directory, 
> sorted in String order (that is, the order defined by "<" for String), 
> one per line.
> 
> Sure, this is a simple problem, but I don't have the time to work a 
> significant problem. If you think a more complex problem should be used, 
>  provide the problem and your solution to it.

Precisely the problem: all solutions proposed have been
towards simple problems.

Try writing a binding to curses, to run with:

   - UNIX real curses
   - GNU curses
   - PDcurses

then, make it compile and work for win2k, Linux, Solaris,
and HPUX. Do it without gnatprep or code generation.

Yes, you can dumb this assignment down to a few curses calls
and be successful at this. But try providing the full complement
of functionality for each of the above curses libraries.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Try writing a binding to curses, to run with:
> 
>   - UNIX real curses
>   - GNU curses
>   - PDcurses
> 
> then, make it compile and work for win2k, Linux, Solaris,
> and HPUX. Do it without gnatprep or code generation.

Where's the specification for "curses" that I'm to write a binding to? 
Clearly it's no larger than the intersection of the 3 curses packages 
you named. Where's your solution, that cannot be achieved with a 
preprocessor?

If you're asking for everything in all 3 packages, then why not say 
"Give me a binding to everything and make it compile and work on 
everything?" That's not requirements for a realistic application; 
they're pie-in-the-sky wishing for a DWIM system.

> Yes, you can dumb this assignment down to a few curses calls
> and be successful at this. But try providing the full complement
> of functionality for each of the above curses libraries.

This is your problem. Give me requirements for an application that needs 
to do X, Y, Z, and W. Show me your solution and why you think a 
preprocessor is necessary for it. Then I can show you how I can do it 
without a preprocessor.

I met your challenge. It's time to put your time where your mouth is and 
meet mine.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Try writing a binding to curses, to run with:
>>
>>   - UNIX real curses
>>   - GNU curses
>>   - PDcurses
>>
>> then, make it compile and work for win2k, Linux, Solaris,
>> and HPUX. Do it without gnatprep or code generation.
> 
> Where's the specification for "curses" that I'm to write a binding to? 
> Clearly it's no larger than the intersection of the 3 curses packages 
> you named. Where's your solution, that cannot be achieved with a 
> preprocessor?

The idea is to put the Ada programmer on an even keel with
the C/C++ programmer on the same platform. If from C you
can call GNU curses API xyz (or functionality provided by xyz),
they by George, it would be nice for the Ada program to take
advantage of the same feature (caveat: thick bindings do not
always make this comparison trivial, but think functionality).

By the same token, xyz may not be available to the PDcurses
programmer on some or all platforms. Win32 may be more restricted
for example.

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

Re: Standard Ada Preprocessor

[Pascal Obry]

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

> Try writing a binding to curses, to run with:
> 
>    - UNIX real curses
>    - GNU curses
>    - PDcurses
> 
> then, make it compile and work for win2k, Linux, Solaris,
> and HPUX. Do it without gnatprep or code generation.

Maybe you'll call AWS a small project. It works on Windows, Linux,
Solaris, MacOS-X, FreeBSD... No gnatprep.

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

[Jeffrey Carter]

Pascal Obry wrote:

> Maybe you'll call AWS a small project. It works on Windows, Linux,
> Solaris, MacOS-X, FreeBSD... No gnatprep.

I wonder if the definition of a small project is like the definition of 
AI. Those who say computers can't be intelligent keep raising the bar as 
things they said a computer couldn't do are accomplished.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:r4BRb.52247$Kg6.387022@news20.bellglobal.com...
...
> Try writing a binding to curses, to run with:
>
>    - UNIX real curses
>    - GNU curses
>    - PDcurses
>
> then, make it compile and work for win2k, Linux, Solaris,
> and HPUX. Do it without gnatprep or code generation.

We had this problem with our JWindows text window library. (That was a
pre-cursor to Claw.) Our solution to this particular problem was to use none
of the above (we didn't trust the C code much anyway, particularly on SCO.),
and instead we directly intepreted the Termcap structures. That was a mess,
but it worked pretty well on all of the platforms that we tried it on.
(Which included Suns, Alphas, and the Unisaurs.)

These days, its not clear that that would work, but so what? No one in their
right mind used curses back then (late 80's) and I fail to see how that's
changed now.

                Randy.

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:r4BRb.52247$Kg6.387022@news20.bellglobal.com...
> ....
>>Try writing a binding to curses, to run with:
>>
>>   - UNIX real curses
>>   - GNU curses
>>   - PDcurses
>>
>>then, make it compile and work for win2k, Linux, Solaris,
>>and HPUX. Do it without gnatprep or code generation.
> 
> We had this problem with our JWindows text window library. (That was a
> pre-cursor to Claw.) Our solution to this particular problem was to use none
> of the above (we didn't trust the C code much anyway, particularly on SCO.),
> and instead we directly intepreted the Termcap structures. That was a mess,
> but it worked pretty well on all of the platforms that we tried it on.
> (Which included Suns, Alphas, and the Unisaurs.)

Well, I would agree that the ideal solution would be to
rewrite all GNU libraries in Ada. I would agree that a
POSIX kernel in Ada would be nice (or AdaOS). But until
that happens, I don't have the luxury of rewriting
everything ;-)

> These days, its not clear that that would work, but so what? No one in their
> right mind used curses back then (late 80's) and I fail to see how that's
> changed now.
> 
>                 Randy.

Curses is far from dead. There are still a large number of
text mode terminals used around the globe.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Chad R. Meiners]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:101gi766nkf57b6@corp.supernews.com...
> These days, its not clear that that would work, but so what? No one in
their
> right mind used curses back then (late 80's) and I fail to see how that's
> changed now.

I always thought they called it curses due to the foul language I used when
trying to get it to work properly ;-)

Win32 console API's on the other hand are a dream compared to my experience
with curses ;-)

-CRM

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Chad R. Meiners wrote:

> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:101gi766nkf57b6@corp.supernews.com...
> 
>>These days, its not clear that that would work, but so what? No one in
>> their
>>right mind used curses back then (late 80's) and I fail to see how that's
>>changed now.
> 
> I always thought they called it curses due to the foul language I used when
> trying to get it to work properly ;-)

Some serial terminals do tend to have that effect on
developers and users alike ;-)

> Win32 console API's on the other hand are a dream compared to my experience
> with curses ;-)
> 
> -CRM

That is probably true, at least until you need the blinking
attribute. The problem is sufficiently difficult that the
blink attribute does not exist in PDcurses (yet), where it
can be used in win32 environments.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Blinking text

[Chad R. Meiners]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:FYwSb.43814$mf4.1513524@news20.bellglobal.com...

>
> That is probably true, at least until you need the blinking
> attribute. The problem is sufficiently difficult that the
> blink attribute does not exist in PDcurses (yet), where it
> can be used in win32 environments.

You *could* fake the blink attribute on win32 with a task that updates the
screen regularly, but I don't care too much for blinking text so I never
missed it.

-CRM

Re: Blinking text

[Warren W. Gay VE3WWG]

Chad R. Meiners wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:FYwSb.43814$mf4.1513524@news20.bellglobal.com...
> 
>>That is probably true, at least until you need the blinking
>>attribute. The problem is sufficiently difficult that the
>>blink attribute does not exist in PDcurses (yet), where it
>>can be used in win32 environments.
> 
> You *could* fake the blink attribute on win32 with a task that updates the
> screen regularly, but I don't care too much for blinking text so I never
> missed it.
> 
> -CRM

This is precisely what I suggested to the PDcurses
maintainer some time ago. But to date this hasn't
been included AFAIK, leaving me to conclude that
it must be sufficiently messy that he's not been
inclined to bother with it.

The Blinking attribute is clearly one that should not
be abused. Yet there are times when you want it, for
things like "DANGER Will Robinson... do you really
want to delete that file? (I would only blink the
"DANGER" part, BTW).

A "web parallel" to the blink attribute
are those stupid animated graphics
that spin and fuss around beside the
news article text. It becomes hard to
ignore, when the text wraps around these
stupid animated images.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Pascal Obry]

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

> Impossible. Some UNIces provide some API structure members,
> while others don't, or provide something else again. Yes,
> you can dumb it down to a "standard" (or omit non-universal
> functionality), but by doing so you throw away functionality.
> I find that unacceptable.

Well yet if the standard offers 99% of the functionality you need it remains
you to do the work for the remaining 1% ! Not that bad :)

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

[Warren W. Gay VE3WWG]

Pascal Obry wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:
>>Impossible. Some UNIces provide some API structure members,
>>while others don't, or provide something else again. Yes,
>>you can dumb it down to a "standard" (or omit non-universal
>>functionality), but by doing so you throw away functionality.
>>I find that unacceptable.
> 
> Well yet if the standard offers 99% of the functionality you need it remains
> you to do the work for the remaining 1% ! Not that bad :)
> 
> Pascal.

Who guarantees that it will only be 1%? ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Jeffrey Carter wrote:

> This thread is about a standard preprocessor (see the subject). But as 
> someone who has done this kind of thing without a preprocessor and 
> prefer the results, I'm convinced that what's needed is a portable way 
> to tell the compiler to use the package body from the Win32 directory, 
> or from the UNIX directory, or from the VMS directory.

Amen!  Incidently, I use symbolic links.  It is a little more 
complicated that using search paths in environment variables, but I feel 
it gives me better control.

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

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Jeffrey Carter wrote:
> 
>> This thread is about a standard preprocessor (see the subject). 

You're right. But if you followed the thread, we progressed
from there ;-)

> But as 
>> someone who has done this kind of thing without a preprocessor and 
>> prefer the results, I'm convinced that what's needed is a portable way 
>> to tell the compiler to use the package body from the Win32 directory, 
>> or from the UNIX directory, or from the VMS directory.
> 
> Amen!  Incidently, I use symbolic links.  It is a little more 
> complicated that using search paths in environment variables, but I feel 
> it gives me better control.

Ostriches, with head in a warm sandy place.

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

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Ostriches, with head in a warm sandy place.

An ad hominem attack! How nice! A sure sign of an indefensible position.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Ostriches, with head in a warm sandy place.
> 
> An ad hominem attack! How nice! A sure sign of an indefensible position.

Fair enough. I hear that ostrich meat is tasty ;-)

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

Re: Standard Ada Preprocessor

[Frank J. Lhota]

> Fair enough. I hear that ostrich meat is tasty ;-)

... and low in fat.

Re: Standard Ada Preprocessor

[stephen.freeman9]

This argument about C (and D) is very interesting - I have been working on
Safety related work (Uk Defstan SIL 3/ Sil 4 software and  DO178b level a)
for flying aircraft.  We use Ada (Spark Ada at that) to develop code.
However the world in general knows C not Ada.  D helps to strengthen C as
does Misra (see Misra 2 for latest invocation)  but as said - what is
lacking is definition of ranges (and strong typing) . A possible solution
I'm working on is "E" for want of a more novel name.  This should look like
C but ask the programmer to define typedef's for each logically different
type s/he is using and as a comment specify the ranges that that is valid
for.  It then needs a pre-processor to parse that to check for
inconsistancies. (perhaps convert it to Ada?)


"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:sWxSb.74$bn1.6@nwrdny02.gnilink.net...
> > Fair enough. I hear that ostrich meat is tasty ;-)
>
> ... and low in fat.
>
>

Re: Language Design (was Standard Ada Preprocessor)

[Warren W. Gay VE3WWG]

stephen.freeman9 wrote:
> This argument about C (and D) is very interesting - I have been working on
> Safety related work (Uk Defstan SIL 3/ Sil 4 software and  DO178b level a)
> for flying aircraft.  We use Ada (Spark Ada at that) to develop code.
> However the world in general knows C not Ada.  D helps to strengthen C as
> does Misra (see Misra 2 for latest invocation)  but as said - what is
> lacking is definition of ranges (and strong typing) . A possible solution
> I'm working on is "E" for want of a more novel name.  This should look like
> C but ask the programmer to define typedef's for each logically different
> type s/he is using and as a comment specify the ranges that that is valid
> for.  It then needs a pre-processor to parse that to check for
> inconsistancies. (perhaps convert it to Ada?)

For my taste, there is too much interest in creating new
languages that look like C. I am OK with borrowing
successful concepts from any language (if it makes
sense), but to me D is just an improved C, just like
Java is a flavour of C++, and C# yet another flavour.

IMO, it would be better for the designer to step
back from experienace in several languages (not
just the C/C++/C#/Java camp) and look at the
problems that the language is designed to solve.

Learn from the ancestors, but some small subset
of those languages shouldn't dictate how the new
one gets defined. IOW, the design effort shouldn't
be stated as "a better version of C" ;-)

What that kind of statement effectively says is
that C is so good that we should use that
as a starting point for improving that model.

I would rather "they" examine the questions:
what has C done well? What has PASCAL
done well? What has Modula-3 done well? What has
Ada done well? What has <functional languages>
done well?  Take away the winning concepts and
use only the concepts as a basis for design.

Surely the C string handling and arrays in general
is flawed by the lack of range constraints. Can
"they" not improve upon that? Well, no: not if
their mandate is a better C.

</rant> ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Jeffrey Carter wrote:

> I'm convinced that what's needed is a portable way 
> to tell the compiler to use the package body from the Win32 directory, 
> or from the UNIX directory, or from the VMS directory.

A pragma for use after package's specs:

  #pragma Remote_Body (Store_Name = "Bodies");

(relegating all other to a particular compiler and its User's Guide...)

- something like this?





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

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: 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.

Not throwing in everything, (though that adds combinations no
matter which method is chosen to deal with the variety),
the following works for me (and also in more complex arrangements).
I will have to make exactly two changes if I want to switch the
OS/POSIX combination:

with OS;    -- see next
procedure run is

   use OS.BSD;

   sample_file: constant := -321;
   --  just any unlikely file descriptor, don't create havoc

   --  We need C.int comparisons for function returns, so:
   use type int;
begin

   --  bad style and all sorts of things...

   if C_MINUS_1 = lockf(sample_file, F_LOCK, 8192) then
      raise Program_Error;
   end if;

end run;


with Systems.BSD_x86;
-- with other Systems as well...
package OS is

   package BSD renames Systems.BSD_x86.FantasyBSD.Non_Standard_POSIX;

   -- package Linux renames ...;

   -- package SUNOS renames ...;

   -- package MacOS renames ...;

end OS;


package Systems is
end Systems;


with Interfaces.C;    use Interfaces;
package Systems.BSD_x86 is

   --  POSIX items for all flavours of BSD for x86.
   -- As there are allegedly both Standard POSIX items and non-standard
   -- ones on some (possibly older) systems, see Warren W. Gay's posting,
   -- there is a Non_Standard_POSIX and a Standard_POSIX package in
   -- each BSD variant package.

   -- ----------------
   -- FantasyBSD
   -- ----------------
   package FantasyBSD is

      package Non_Standard_POSIX is

         use type C.int;

         C_MINUS_1: constant C.int := -1;
         --  indicating a failing function

         F_LOCK: constant C.int := 3_4829; -- surprising value

         subtype off_t is C.long;
         subtype int is C.int;

         function lockf
           (file_descriptor: int;
            function_number: int;
            bytes: off_t)
           return int;
         pragma import(C, lockf);

      end Non_Standard_POSIX;

      package Standard_POSIX is

         --  rename needed functions from ISO Ada Bindings

      end Standard_POSIX;

   end FantasyBSD;


   -- ----------------
   -- OpenBSD
   -- ----------------
   package OpenBSD is
   end OpenBSD;


   -- ----------------
   -- FreeBSD
   -- ----------------
   package FreeBSD is
   end FreeBSD;

   -- ...

end Systems.BSD_x86;



georg@strudel:~/rsrc/Ada/wg$ gnatmake run
gcc -c run.adb
gcc -c os.ads
gcc -c systems.ads
gcc -c systems-bsd_x86.ads
gnatbind -x run.ali
gnatlink run.ali
georg@strudel:~/rsrc/Ada/wg$ ./run

raised PROGRAM_ERROR : run.adb:15 explicit raise
georg@strudel:~/rsrc/Ada/wg$ 


Most outstanding bug: the program has been compiled on
Linux strudel 2.4.18 #1 Fri May 2 17:22:29 CEST 2003 i686 unknown ;-)


: I get frustrated with the short sightedness of the "not invented
: here syndrome". But maybe, that is just me. ;-)

Hm. Plan 9's C enviroment does well without #ifdefs, even though
it has to provide this environment for different architectures.
This is reported to be confusing for those who have unfortunately
been told to use

#if defined __THIS_HEADER__

in header files, as a replacement for a design that keeps things
separate so multiple inclusion does not occur.

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
> : 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.
> 
> Not throwing in everything, (though that adds combinations no
> matter which method is chosen to deal with the variety),
> the following works for me (and also in more complex arrangements).
> I will have to make exactly two changes if I want to switch the
> OS/POSIX combination:
> 
> with OS;    -- see next
> procedure run is
> 
>    use OS.BSD;
...

But this gets back to maintaining many mostly parallel
pieces of code. For some projects, this is very
incovenient.

There I said it.

I wish for more convenience to deal with portability.

> : I get frustrated with the short sightedness of the "not invented
> : here syndrome". But maybe, that is just me. ;-)
> 
> Hm. Plan 9's C enviroment does well without #ifdefs, even though
> it has to provide this environment for different architectures.

How does this help the Ada scenario?  I am not saying that
some situations cannot be best addressed with separately
maintained packages/bodies. But it is not the best solution
for some projects that are very platform sensitive (see
earlier posts for why).

> This is reported to be confusing for those who have unfortunately
> been told to use
> 
> #if defined __THIS_HEADER__
> 
> in header files, as a replacement for a design that keeps things
> separate so multiple inclusion does not occur.

C header files are a mess. Ada packages are soooo different
from C, that we don't need to even go there. However, there
is a case to conditionally with a package, just as a C
program has a case for conditionally #include-ing.

I can't add to the plan9 case, since I've not dug too deep
into it. Unless they change their copyright restrictions,
I will not make any investment of my time there.

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

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: 
: But this gets back to maintaining many mostly parallel
: pieces of code.

Well, yes. It is very centralised though.
The ideal scenario for me would be a declaration (using
clickable check boxes or editing text) that
effectively creates a program view. This means, I specify
what I want at a high level and the computer compiles this
into a corresponding source text view.

When I see

if <this>
context_clause_A
fi
source
source
if <this>
variant_A
else
variant_B
fi
source
source
if <this>
addition_A
fi
source

this looks like assembly language to me, with all its flexibility.
But why do we build higher level text structures and compilers?


It is interesting that programmers and in particular those
with an engineering attitude have not built machinery to solve
the problem in a high level systematic manner. Why?

There is an opportunity to sell something, or selling support,
or starting a community effort...

-- Georg

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
> : 
> : But this gets back to maintaining many mostly parallel
> : pieces of code.
> 
> Well, yes. It is very centralised though.
> The ideal scenario for me would be a declaration (using
> clickable check boxes or editing text) that
> effectively creates a program view. This means, I specify
> what I want at a high level and the computer compiles this
> into a corresponding source text view.

True, but there are other factors to consider in
development. Mind you this is a "developer convenience"
issue, but once you compile and/or debug, and you
realize that line 905 of xyz.adb needs to be changed,
where must the real editing be done? Probably not the
file that the compiler used, because it was generated
by some other tool. Often what happens is the xyz.adb
gets edited, and the change is lost.

Tracing back to the where the change really has to go
is inconvenient, if not extremely so. If you're trying
to sort out a problem with open sourced project(s), then
you have to sort out how the creator/maintainer set things
up for you (each project will be different). Again, I
find this annoying at best.

> When I see
> 
> if <this>
> context_clause_A
> fi
> source
> source
> if <this>
> variant_A
> else
> variant_B
> fi
> source
> source
> if <this>
> addition_A
> fi
> source
> 
> this looks like assembly language to me, with all its flexibility.

Yes, this is ugly, but not always _this_ ugly. Furthermore,
if this ugliness were confined only to thin bindings, I
could live with that. No Ada programmer wants to see this
throughout his project.

> But why do we build higher level text structures and compilers?

I don't understand your point here.

> It is interesting that programmers and in particular those
> with an engineering attitude have not built machinery to solve
> the problem in a high level systematic manner. Why?
> 
> There is an opportunity to sell something, or selling support,
> or starting a community effort...
> 
> -- Georg

I think the real reason is that people are holding out for
the "ivory tower" (aka "elegant") solution. There is nothing
wrong with this in principle, but I think it is fair to say
that after 12-20 years, if no solution has emerged, then the
standard has been set too high.

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

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: you
: realize that line 905 of xyz.adb needs to be changed,
: where must the real editing be done? Probably not the
: file that the compiler used, because it was generated
: by some other tool. Often what happens is the xyz.adb
: gets edited, and the change is lost.

Hm, how can that be when you have deterministic rules
that will lead to one source text view given N configuration
inputs? Of course programmers will have to be aware that
they have to consider the configuration with care.

:> this looks like assembly language to me, with all its flexibility.
: 
: Yes, this is ugly, but not always _this_ ugly. Furthermore,
: if this ugliness were confined only to thin bindings, I
: could live with that. No Ada programmer wants to see this
: throughout his project.
: 
:> But why do we build higher level text structures and compilers?
: 
: I don't understand your point here.

Assembly language may be useful here and there but it seems like
programming is mostly done in higher level languages. If configuration
with conditionals in source files and assembly languge are considered
analogous, my expectation is that it makes sense to create a higher
level language for configuration. From another comment in this thread
I conclude that ClearCase has something like this.


-- Georg

Re: Standard Ada Preprocessor

[Marin David Condic]

If there is no elegant solution, then the alternatives are to create an 
inelegant one or live with the problem. Or switch to a language that has 
the inelegant solution. My concern is with the last alternative. People 
look at Ada and say "I can't make it do what I want it to do..." The Ada 
advocates say "Well, you can but you have to turn your head just right, 
stand on one leg, blink your eyes three times...." Or some version of 
"Go solve it with a tool outside the language...." So the developer 
does: He uses C++.

We don't have to make Ada look like C, C++ or Java, but we ought to aim 
for at least providing a way of doing important things that these 
languages can do in some Ada-ish manner.

You can't stop people from wanting things you don't like. You can refuse 
to sell it to them (as one should, if it is immoral), but that just 
sends them off to someone who *will* sell it to them.

MDC

Warren W. Gay VE3WWG wrote:
> 
> I think the real reason is that people are holding out for
> the "ivory tower" (aka "elegant") solution. There is nothing
> wrong with this in principle, but I think it is fair to say
> that after 12-20 years, if no solution has emerged, then the
> standard has been set too high.
> 


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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> If there is no elegant solution, then the alternatives are to create an 
> inelegant one or live with the problem. Or switch to a language that has 
> the inelegant solution. My concern is with the last alternative. People 
> look at Ada and say "I can't make it do what I want it to do..." The Ada 
> advocates say "Well, you can but you have to turn your head just right, 
> stand on one leg, blink your eyes three times...." 

This would give me trouble ;-)
...
> We don't have to make Ada look like C, C++ or Java, but we ought to aim 
> for at least providing a way of doing important things that these 
> languages can do in some Ada-ish manner.

Which was the point of the discussion.

> 
> You can't stop people from wanting things you don't like. You can refuse 
> to sell it to them (as one should, if it is immoral), but that just 
> sends them off to someone who *will* sell it to them.
> 
> MDC

I was tempted to compare this with "gun control", but
that might lead to another entirely OT thread ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

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

[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 ?)

[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 ?)

[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 ?)

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

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

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 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 ?)

[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 ?)

[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 ?)

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

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

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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

Re: Standard Ada Preprocessor

[Jacob Sparre Andersen]

Warren W. Gay VE3WWG wrote:

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

Agreed.

But don't you agree that allowing a preprocessor to work on package
specifications isn't exactly good Ada style.  Then you can't trust the
package specifications anymore.  Although I prefer a simple "choose an
appropriate package body" method, I can see some benefits of allowing
full preprocessing of package bodies.

My main problem right now is: Is it possible to specify a sensible
common method for asking the compiler questions about the target
environment?  How?

My first thought was to tell the user (of the compiler) to give the
compiler some appropriate flags, indicating the information needed for
selecting which package bodies to choose.  But that would still leave
the problem of making those configuration decisions to the user
instead of automating them.

Could we ask the compilers to be able to tell us if some library (a
string indicating a library name) exists in a specific version (a
string indicating a version)?  What do compiler vendors say to that?

What other kinds of compile time switches do we want to be able to
make?  Either based on user choice or on the configuration of the
target system.

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

Yes.  But users of Open Source software already seem to have agreed to
use Autoconf/Automake as their "standard" compile-time configuration
tool.  How does that work on non-Unix systems BTW?

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

Good.  Maybe we can actually come up with a suggestion we can sell to
the ARG.

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

I hope we can find a solution that makes it easier for people who
receive a source code package with an Ada program to just compile and
run the program, _without_ letting the whole C preprocessor hell loose
in Ada too.

Greetings,

Jacob
-- 
"Hungh. You see! More bear. Yellow snow is always dead give-away."

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jacob Sparre Andersen wrote:

> Warren W. Gay VE3WWG wrote:
...
> But don't you agree that allowing a preprocessor to work on package
> specifications isn't exactly good Ada style.  

No argument. But I do have a problem to solve. The problem
is ugly, and the solution might be ugly too ;-)

> Then you can't trust the
> package specifications anymore.  Although I prefer a simple "choose an
> appropriate package body" method, I can see some benefits of allowing
> full preprocessing of package bodies.

You might be using a different meaning for "trust"
than I use. As I see it, it need not be any different
trust-wise than #included source code in a C program.
You know in advance that certain elements will be compiled
certain way in certain environments. I can trust that to
be the case no matter how many times that is called upon.

I can also trust that things will be compiled in the
other environments that will use them. I see no real
issue here. I'll agree however, that it is bad style
and ugly.

> My main problem right now is: Is it possible to specify a sensible
> common method for asking the compiler questions about the target
> environment?  How?

That is the problem for Ada that has remained unsolved
for (IMO) too long.

> My first thought was to tell the user (of the compiler) to give the
> compiler some appropriate flags, indicating the information needed for
> selecting which package bodies to choose.  But that would still leave
> the problem of making those configuration decisions to the user
> instead of automating them.

The problem that exists now is not generating the configuration.
That can be done a multitude of ways, and is done in Open
Sourced projects all over the place. The problem is taking
it from configuration to source code. That is where the
rubber hits the road right now. C/C++ deal with this just
fine. Ada is challenged here.

> Could we ask the compilers to be able to tell us if some library (a
> string indicating a library name) exists in a specific version (a
> string indicating a version)?  What do compiler vendors say to that?
> 
> What other kinds of compile time switches do we want to be able to
> make?  Either based on user choice or on the configuration of the
> target system.

It is not up to the compiler to know what configuration to
use. But given directions about the configuration, the job
is to generate a compiled version of that solution ;-)

>>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 ;-)
> 
> Yes.  But users of Open Source software already seem to have agreed to
> use Autoconf/Automake as their "standard" compile-time configuration
> tool.  How does that work on non-Unix systems BTW?

Again, Autoconf et al work fine for C/C++ systems. It requires
real gyrations to use it with Ada ;-)

Presumably, Autoconf could be used in a CYGWIN environment,
though I have not tried it myself. Windows is in some ways
much easier to config for, since there are fewer variations
than exist in the *NIX/*BSD world. There are of course, still
variations, and one has to be concerned about what optional
components are installed etc. The general approach to Windows
seems to be to provide an Intel binary (setup) to do that work.

>>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 ;-)
> 
> I hope we can find a solution that makes it easier for people who
> receive a source code package with an Ada program to just compile and
> run the program, _without_ letting the whole C preprocessor hell loose
> in Ada too.
> 
> Greetings,
> 
> Jacob

The fact that a conditional compilation feature is made available,
does not require it to be used. Just by mandating that it is
not done by default should help. Certainly safety critical
systems where perhaps this type of thing would not be tolerated,
you can mandate that it never be used.

So given the above, the real resistance is boils down to the
argument "I don't want to ever see it".
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Jacob Sparre Andersen]

Warren W. Gay VE3WWG wrote:
> Jacob Sparre Andersen wrote:
> > Warren W. Gay VE3WWG wrote:

> > But don't you agree that allowing a preprocessor to work on
> > package specifications isn't exactly good Ada style.
> 
> No argument. But I do have a problem to solve. The problem is ugly,
> and the solution might be ugly too ;-)

:-(

Do you have any examples, where you would have, or actually have, used
a preprocessor on package specifications?  (I hope I haven't missed
some in the discussion)

I probably make too simple systems, but I find it hard to imagine
cases, where it wouldn't be more appropriate to - at least - keep the
variant parts of the code away from package specifications.

> > Then you can't trust the package specifications anymore.  Although
> > I prefer a simple "choose an appropriate package body" method, I
> > can see some benefits of allowing full preprocessing of package
> > bodies.
> 
> You might be using a different meaning for "trust" than I use. As I
> see it, it need not be any different trust-wise than #included
> source code in a C program.  You know in advance that certain
> elements will be compiled certain way in certain environments. I can
> trust that to be the case no matter how many times that is called
> upon.

My problem is that if the package specifications vary with the target
environment, that means that all the code using that package also may
have to vary with the target environment, and thus propagate use of
conditional compilation. - I doubt that the ARG would let that into
the standard.

> > My main problem right now is: Is it possible to specify a sensible
> > common method for asking the compiler questions about the target
> > environment?  How?
> 
> That is the problem for Ada that has remained unsolved for (IMO) too
> long.

Haven't anybody tried to put a suggestion together?

> > My first thought was to tell the user (of the compiler) to give
> > the compiler some appropriate flags, indicating the information
> > needed for selecting which package bodies to choose.  But that
> > would still leave the problem of making those configuration
> > decisions to the user instead of automating them.
> 
> The problem that exists now is not generating the configuration.

I am not sure I agree.

> That can be done a multitude of ways, and is done in Open Sourced
> projects all over the place.

Yes, but the Open Source world has a de-facto standard for doing it.
We should either get those tools to support Ada as well as they
support C and C++ or make an easier and safer solution for Ada.

> The problem is taking it from configuration to source code. That is
> where the rubber hits the road right now. C/C++ deal with this just
> fine. Ada is challenged here.

I would say that that part is close to trivial - if we can agree to
which granularity to support.  At one extreme there is the current
situation with no formalised conditional compilation, somewhere in
between there is letting the compiler choose appropriate package
bodies given the configuration parameters, and at the other extreme we
have mandating something like the C preprocessor.

Personally I would like to have the solution of letting the compiler
choose appropriate package bodies.  But without some level of
automated detection of the target environment, it wouldn't be of much
use, and I could just as well handle it myself as I do today.

> It is not up to the compiler to know what configuration to use. But
> given directions about the configuration, the job is to generate a
> compiled version of that solution ;-)

I can understand your point of view, but if we really want to compete
with `./configure && make && su -c make install`, we have to do better
than that.

If users have to find out which versions of which libraries are on
their systems _and_ how to tell the compiler that information, we are
already _far_ behind what I can do myself with existing tools and
without much work.

> Again, Autoconf et al work fine for C/C++ systems. It requires real
> gyrations to use it with Ada ;-)

Sure?  I have never had to create an Autoconf/Automake configuration
from scratch, but I find it hard to imagine that it requires excessive
amounts of work to get it to do the testing needed to configure an Ada
program.

> The fact that a conditional compilation feature is made available,
> does not require it to be used.

Right.  But programmers have an awful habit of using whatever tools
available.

> So given the above, the real resistance is boils down to the
> argument "I don't want to ever see it".

If you are talking about full C preprocessor style conditional
compilation, you are certainly right.

If we are talking about some intermediated solution, where the public
part of package specifications are untouched by the conditional
compilation mechanism _and_ we can include some implementation advise
about the compiler guessing or asking the user the questions needed to
resolve the conditional compilation, then I will most likely support
it.

Jacob
-- 
"I don't want to gain immortality in my works.
 I want to gain it by not dying."

Re: Standard Ada Preprocessor

[Dmitry A. Kazakov]

On 10 Feb 2004 22:49:28 +0100, Jacob Sparre Andersen <sparre@nbi.dk>
wrote:

>My problem is that if the package specifications vary with the target
>environment, that means that all the code using that package also may
>have to vary with the target environment, and thus propagate use of
>conditional compilation. - I doubt that the ARG would let that into
>the standard.

Sure. The solution should be based on a contract model.

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

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jacob Sparre Andersen wrote:

> Warren W. Gay VE3WWG wrote:
>>Jacob Sparre Andersen wrote:
>>>Warren W. Gay VE3WWG wrote:
>>>But don't you agree that allowing a preprocessor to work on
>>>package specifications isn't exactly good Ada style.
>>
>>No argument. But I do have a problem to solve. The problem is ugly,
>>and the solution might be ugly too ;-)
> 
> :-(
> 
> Do you have any examples, where you would have, or actually have, used
> a preprocessor on package specifications?  (I hope I haven't missed
> some in the discussion)

I've kind of run out of steam on this thread. I've pointed out
some general examples in the earlier parts of this thread.

>>So given the above, the real resistance is boils down to the
>>argument "I don't want to ever see it".
> 
> If you are talking about full C preprocessor style conditional
> compilation, you are certainly right.

No, actually (this has been discussed earlier in this thread).
Remember that some of C/C++'s problems are related to #include
which is quite different that with-ing a package. However, there
are times when you want to with one package over another (for
example you want to use the GNAT.* package(s) when using GNAT,
and something else to replace if compiling with another compiler).
This is just one example and of course you need to conditionally
compile code depending upon which package(s) you have with-ed
because the functionality may not be the same (certainly the
hierarchical names for the package defined items are different
also).

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

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

[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 ?)

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

"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 ?)

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

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

[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 ?)

[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 ?)

[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 ?)

[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 ?)

[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

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:

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

ObjectAda:
 The Available System Names are: S370, I80X86, I80386, MC680X0,
VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300,
SPARC.

 Current System.System_Name is: I80386.

Re: Standard Ada Preprocessor

[Marin David Condic]

Better than Gnat, but still not terribly useful if you want to make code 
that will compile on both a Gnat and an Aonix platform.

MDC

Georg Bauhaus wrote:
> 
> ObjectAda:
>  The Available System Names are: S370, I80X86, I80386, MC680X0,
> VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300,
> SPARC.
> 
>  Current System.System_Name is: I80386.
> 


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

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: Better than Gnat, but still not terribly useful if you want to make code 
: that will compile on both a Gnat and an Aonix platform.

What kind of difficulties do you see that could be better solved
by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
versa? Dependence on pragmata?)

I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p.
Ada source text is chopped where necessary using make.
(Operating) System specific routines are are assembled into a
package hierarchy (which I naively had top-level-named "System" (and
that triggers a bug box in GCC 34 after looping (the maintainers
say that, obviously, a library unit should not be modified...)))
Then a branch renames package Systems.Windows, another renames
package Systems.UNIX (or similarly).

The problem that leads GNAT 3.15p to reject another unit is
apparently a bug in GNAT 3.15p that has been fixed in GCC 34.
I like this better than having to construct sources around a
compiler bug/limitation using hopefully temporary preprocessor #ifs.


-- Georg

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Marin David Condic <nobody@noplace.com> wrote:
> : Better than Gnat, but still not terribly useful if you want to make code 
> : that will compile on both a Gnat and an Aonix platform.
> 
> What kind of difficulties do you see that could be better solved
> by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
> versa? Dependence on pragmata?)

MDC pointed out that you cannot conditionally do "with"
as one example. Implementation defined pragmas are
another area of difficulty. Optional features are
a pain to deal with since there is no way to feed
values into a compile process (using make),
without creating make "steps" that process the
source code before hand (ie. this becomes a manual
preprocessing step).

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

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: MDC pointed out that you cannot conditionally do "with"
: as one example.

Withing or not cannot be an option unless another possibly
related conditional requires a unit or not.
If there is no other conditional text, renaming an empty
package will do.

: Implementation defined pragmas are
: another area of difficulty. Optional features are
: a pain to deal with since there is no way to feed
: values into a compile process (using make),
: without creating make "steps" that process the
: source code before hand (ie. this becomes a manual
: preprocessing step).

So what is the greater pain?
To me, placing conditionals near the conditional sections is
tempting, but usually leads to #ifs all over the place.  It is
like writing tasking constructs without language support, or
like wrting your own dispatcher.  If we had a way to declare for
any of the 2**N compilations which conditions are to be met, and
which parts of the program text have to be in place for one of the
compilations, configuration could be done in a systematic manner,
with the help of a computer program that does configuration checking,
and with a readable statement (declarative in style) of the programs
dependences.


-- Georg

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
> : MDC pointed out that you cannot conditionally do "with"
> : as one example.
> 
> Withing or not cannot be an option unless another possibly
> related conditional requires a unit or not.
> If there is no other conditional text, renaming an empty
> package will do.

Perhaps I don't understand your point here, but if I
supply a parameter on the command line to the compiler
that says I am compiling with GNAT (or PDcurses or
whatever), then I can at compile time choose what
packages I am going to "need". I don't find any
reason to see prevent a conditional compile condition
here.

> : Implementation defined pragmas are
> : another area of difficulty. Optional features are
> : a pain to deal with since there is no way to feed
> : values into a compile process (using make),
> : without creating make "steps" that process the
> : source code before hand (ie. this becomes a manual
> : preprocessing step).
> 
> So what is the greater pain?
> To me, placing conditionals near the conditional sections is
> tempting, but usually leads to #ifs all over the place.  

If you have #ifs all over the place, it is because you
need them ;-)   Granted much of this abuse on the C/C++
side is related to how C/C++ works in the first place.
So drawing parallels to C should be done carefully.

There is still a strong need for conditional compilation.
Not for embedded work, since you have very specific
targets for that code. But if Ada is to support the
general purpose computing environment, and to support
portability, it must have better facilities for the
portability issues that come up.

 > It is
> like writing tasking constructs without language support, or
> like wrting your own dispatcher.  If we had a way to declare for
> any of the 2**N compilations which conditions are to be met, and
> which parts of the program text have to be in place for one of the
> compilations, configuration could be done in a systematic manner,
> with the help of a computer program that does configuration checking,
> and with a readable statement (declarative in style) of the programs
> dependences.

Tell me, how do you solve the situation where API call to your
OS requires 3 parameters on one platform, and 2 on another? No
if statement can solve that for you.

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

Re: Standard Ada Preprocessor

[Marin David Condic]

Even in embedded work it is sometimes important. I might have code that 
relates to some breadboard version of the system that dummies up some 
stuff that exists differently on the "real" hardware. Or I might want to 
make a version of some of the code that operates on a workstation by 
faking out hardware that exists in the real unit. Or I might have 
multiple turns of a hardware board that each have peculiarities that 
need to be coded around. Or I might have multiple versions of an RTOS 
with variations on system calls that change from one version to the next.

I've encountered all of these in real-world situations and sometimes I 
might have dealt with them by having separate bodies (often really 
difficult to manage in practice) or I dealt with them via conditional 
compilation because I was using C. I just know it happens enough where 
conditional compilation would be a useful thing and not always a matter 
of abuse. If someone thinks it isn't really needed because it can be 
dealt with via some kind of CM or build process - I'd suggest they need 
to work in some of the environments I've been in where you either don't 
have the tools or there are all sorts of complications that make this 
really hard to do.

Conditional compilation isn't always pretty - but then neither are rep 
clauses or other things that are regularly done because that's the 
easiest way to get the job done.

MDC

Warren W. Gay VE3WWG wrote:
> 
> There is still a strong need for conditional compilation.
> Not for embedded work, since you have very specific
> targets for that code. But if Ada is to support the
> general purpose computing environment, and to support
> portability, it must have better facilities for the
> portability issues that come up.
> 

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

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:4011CF46.3040001@noplace.com...
...
> I've encountered all of these in real-world situations and sometimes I
> might have dealt with them by having separate bodies (often really
> difficult to manage in practice) or I dealt with them via conditional
> compilation because I was using C. I just know it happens enough where
> conditional compilation would be a useful thing and not always a matter
> of abuse. If someone thinks it isn't really needed because it can be
> dealt with via some kind of CM or build process - I'd suggest they need
> to work in some of the environments I've been in where you either don't
> have the tools or there are all sorts of complications that make this
> really hard to do.

You want to change the language because you've had to work in poorly managed
shops with insufficient tools? Sure, we all do what we have to do to get the
job done, but that hardly justifies a major language change (and one where
no obvious workable solution springs to mind).

> Conditional compilation isn't always pretty - but then neither are rep
> clauses or other things that are regularly done because that's the
> easiest way to get the job done.

I think you're comparing apples to oranges. Rep clauses are an elegant way
of getting the job done; the only alternative is bit mask operations and
those are a lot harder to understand. And they certainly aren't about just
interfacing to hardware - I use them a lot to reduce storage use without
making critical parts too slow. So I guess I'd say that rep. clauses ARE
pretty. You'd be better off picking on Access_to_Address_Conversions or
something like that -- except that no one much uses any of those packages.
Perhaps because they are ugly.

I'm not personally against conditional compilation, I just don't see any way
to integrate a useful form of it into the language. (I don't think it is
necessary in an ideal world, but the world is hardly ideal - people write
gibberish in C and Java after all.) The form that Janus/Ada has (and we no
longer use in new code because it isn't flexible enough) is a pure binary
in-or-out scheme intended solely for marking debugging code. ('@' is either
compiled as a comment "--" or as a space ' ' depending on the command line
options.) Pragmas have a number of problems: they can't be used in some
parts of the code (for example, formal_parts and discriminant_parts); such a
pragma would violate "good taste in pragmas" as laid out in 2.8; and enough
people think that they're ugly to prevent them from being used this way.
(GNAT's pragma Debug was considered and discarded for this reason.) Some
sort of syntax would be needed, and that seems like it would be pretty
heavy. (And I have no idea what it ought to look like.)

If you want to propose something, feel free, but remember that the ARG is
not taking new topics anymore, so unless you can find a way to coordinate it
with an existing AI, it will have to wait for Ada 1Z.

                      Randy.


All-in-all, it seems like there

Re: Standard Ada Preprocessor

[Marin David Condic]

Rep clauses are ugly in the sense that "In A Perfect World" we'd want to 
let the compiler worry about how to represent data. Inherently, they 
make the code compiler and target dependent. By their very existence, 
you can't just hand someone some body of code and say "Trust me. It will 
compile & run on your machine..." Rep clauses are actually one of the 
better arguments for needing conditional compilation. (Target A? Use 
this rep! Target B? Use that one!)

Oh sure. They are better than a sharp stick in the eye and if you have 
to  control representation, they're an elegant solution. But they are 
still "Butt Ugly" in the sense that the instant you use one, you can't 
promise that the code will work *anywhere* except on the one 
compiler/target where you built it.

As for submitting something to the ARG? I'll leave that to the language 
lawyers. They'll come up with far better proposals than I could ever 
write - so long as they think the idea might be a good one. I'm just the 
end-user of Ada - a customer - expressing what he thinks would make the 
language more usable on a day-to-day level. We're a dwindling herd, so 
maybe those opinions ought to get some attention by the people who make 
and sell Ada. Hope springs eternal! :-)

MDC

Randy Brukardt wrote:
> 
> I think you're comparing apples to oranges. Rep clauses are an elegant way
> of getting the job done; the only alternative is bit mask operations and
> those are a lot harder to understand. And they certainly aren't about just
> interfacing to hardware - I use them a lot to reduce storage use without
> making critical parts too slow. So I guess I'd say that rep. clauses ARE
> pretty. You'd be better off picking on Access_to_Address_Conversions or
> something like that -- except that no one much uses any of those packages.
> Perhaps because they are ugly.



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

[Robert I. Eachus]

Marin David Condic wrote:

> Rep clauses are ugly in the sense that "In A Perfect World" we'd want to 
> let the compiler worry about how to represent data. Inherently, they 
> make the code compiler and target dependent. By their very existence, 
> you can't just hand someone some body of code and say "Trust me. It will 
> compile & run on your machine..." Rep clauses are actually one of the 
> better arguments for needing conditional compilation. (Target A? Use 
> this rep! Target B? Use that one!)

Somebody wrote an article (for Ada Letters I think) on how to write 
representation specifications that are legal (and identical!) for 
bigendian and little endian hardware.  Anyone remember it?  I tend now 
to target only x86 family machines, where MMX, 3dNow!, SSE, and SSE2 
give me enough headaches. ;-)

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

[Marin David Condic]

Possible. But endianness is *not* the only reason for the existence of 
rep clauses. So while you *might* write portable endianness code, you 
can't figure that's the answer to everything. Somewhere a rep clause is 
going to work for one target and you'll need a different rep clause for 
a different target. Until all compilers and environments are exactly 
alike, you'll have some kind of problem like this.

MDC

Robert I. Eachus wrote:
> 
> Somebody wrote an article (for Ada Letters I think) on how to write 
> representation specifications that are legal (and identical!) for 
> bigendian and little endian hardware.  Anyone remember it?  I tend now 
> to target only x86 family machines, where MMX, 3dNow!, SSE, and SSE2 
> give me enough headaches. ;-)
> 


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

[tmoran]

>Rep clauses are ugly in the sense that "In A Perfect World" we'd want to
>let the compiler worry about how to represent data. Inherently, they
>make the code compiler and target dependent. By their very existence,
>you can't just hand someone some body of code and say "Trust me. It will
  I don't understand what you use rep clauses for.  I normally use them
when a data structure must be shared outside my program, by a hardware
device, an OS call, another program, etc.  For those, the rep clause does
not change when you change compiler or target machine - unless your target
*requires* a change because it demands a different representation.  Not
even a perfect compiler could do that automatically.

Re: Standard Ada Preprocessor

[Marin David Condic]

A simple case: Suppose you are developing for an embedded box but you 
want to do some simple "Smoke Testing" on a PC. For the embedded box, 
you need a rep clause for some register. For the PC you're dummying that 
up with something and don't want a rep clause at all. (Or the PC 
compiler barfs on the rep clause that the embedded compiler accepts.) It 
would be nice to say "If compiling for the PC with Aonix, use this code 
(no rep), but if compiling for the target with the Gnat compiler, go use 
that code..."

I've also run into situations where the hardware weenies are working as 
fast as we software bozos are and every few weeks, you're getting new 
turns of a board with different hardware in it. You still need to 
compile for earlier boards but now you have something different - 
probably with a different rep clause. I don't want to go into some 
complex CM and build process just for the developmental stuff - I just 
need a quick and dirty answer to being able to get the code to work on 
two (or more) boxes short-term.

That's why I'm saying that conditional compilation may be ugly and 
intellectually unsatisfying and not "The Perfect World" but often you've 
got circumstances that make it the best, expedient choice for fixing a 
real world situation. And yes, I agree it can be abused. Maybe there is 
some way of making it simple enough to get a job done but not powerful 
enough to make an atrocity.

But its been observed that there never has been a programming language 
in which it has been the least bit hard to write bad code. Maybe we can 
just accept that and live with it.

MDC


tmoran@acm.org wrote:
> 
>   I don't understand what you use rep clauses for.  I normally use them
> when a data structure must be shared outside my program, by a hardware
> device, an OS call, another program, etc.  For those, the rep clause does
> not change when you change compiler or target machine - unless your target
> *requires* a change because it demands a different representation.  Not
> even a perfect compiler could do that automatically.


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

[Robert I. Eachus]

Marin David Condic wrote:

> A simple case: Suppose you are developing for an embedded box but you 
> want to do some simple "Smoke Testing" on a PC. For the embedded box, 
> you need a rep clause for some register. For the PC you're dummying that 
> up with something and don't want a rep clause at all. (Or the PC 
> compiler barfs on the rep clause that the embedded compiler accepts.) It 
> would be nice to say "If compiling for the PC with Aonix, use this code 
> (no rep), but if compiling for the target with the Gnat compiler, go use 
> that code..."

You are familar with RM 13.1(22) right?  "An implementation need not 
support representation items containing nonstatic expressions, except 
that an implementation should support a representation item for a given 
entity if each nonstatic expression in the representation item is a name 
that statically denotes a constant declared before the entity."

I know it is Implemenation Advice, but especially for Address 
representation specifications it is almost required of any decent 
compiler that they support at least this.  If you don't understand how 
to read it look at the "Rosen trick":

function Random(Gen: Generator) return Float is
    Local: Generator;
    for Local'Address use Gen'Address;
begin
    ....
end Random;

The value of Gen'Address is definitely non-static.  But it is easy for a 
compiler to "get it right" in this case because the value of 
Local'Address each time the declaration of Local is elaborated.

What has this got to do with Marin's complaint?  He thinks that invalid 
representation clauses must be illegal.  If they are non-static they 
can't be illegal because the value to be set at run-time is wrong. 
Either the compiler will raise Program_Error at run-time or execution of 
the invalid representation clause will make the program erroneous.  See 
for example RM 13.3(13): "If an Address is specified, it is the 
programmer's responsibility to ensure that the address is valid; 
otherwise, program execution is erroneous."

Since the address in the representation clause need not be static, your 
program can set it at run-time depending on the hardware involved.  You 
mean you have never done that?  I have code with address clauses that 
depend on system calls made at run-time.

So loosen up a little Marin, and try writing non-static representation 
clauses.  Remember 13.1(22) that I referenced above, and that 'Size for 
objects (but not subtypes) must be static, RM 13.3(41). But you should 
be able to do a lot more with Rep clauses than you have done so far. ;-)

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

[Marin David Condic]

I'm not talking about addresses. Have you never seen a rep clause on a 
record, for example, that a given compiler will refuse to accept even if 
it is syntactically legal? I don't happen to have one sitting in my back 
pocket at the moment, but I *know* I've coded up valid rep clauses on 
records that compilers have spit out and refused to accept. Technically, 
it is legal for an implementation to refuse just about any rep clause it 
doesn't want to be bothered with - so perhaps you've got it coded up one 
way for one compiler and another way for another compiler.

Perhaps there's some arcane trick that can be pulled to change rep 
clauses on a record on the fly, but I've not seen it (and it sure starts 
sounding *far* more complex than decrypting a simple conditional 
compilation directive - maybe this is what frustrates me about the 
opposition to a conditional compile: Everyone holds out some cumbersome, 
complex, arcane trickery that is orders of magnitude more difficult to 
understand and utilize properly as an answer in order to avoid something 
that is capable of being pretty simple & basic.). What I *have* seen is 
rep clauses that a compiler refuses to accept - and hence I can't even 
*get* to runtime because I've got compile errors. Legal or not - Moral 
or not - I still have to get a job done and a conditonal compilation 
directive of some sort would fix the problem.

MDC

Robert I. Eachus wrote:
> 
> You are familar with RM 13.1(22) right?  "An implementation need not 
> support representation items containing nonstatic expressions, except 
> that an implementation should support a representation item for a given 
> entity if each nonstatic expression in the representation item is a name 
> that statically denotes a constant declared before the entity."
> 
> I know it is Implemenation Advice, but especially for Address 
> representation specifications it is almost required of any decent 
> compiler that they support at least this.  If you don't understand how 
> to read it look at the "Rosen trick":
> 
> function Random(Gen: Generator) return Float is
>    Local: Generator;
>    for Local'Address use Gen'Address;
> begin
>    ....
> end Random;
> 
> The value of Gen'Address is definitely non-static.  But it is easy for a 
> compiler to "get it right" in this case because the value of 
> Local'Address each time the declaration of Local is elaborated.
> 
> What has this got to do with Marin's complaint?  He thinks that invalid 
> representation clauses must be illegal.  If they are non-static they 
> can't be illegal because the value to be set at run-time is wrong. 
> Either the compiler will raise Program_Error at run-time or execution of 
> the invalid representation clause will make the program erroneous.  See 
> for example RM 13.3(13): "If an Address is specified, it is the 
> programmer's responsibility to ensure that the address is valid; 
> otherwise, program execution is erroneous."
> 
> Since the address in the representation clause need not be static, your 
> program can set it at run-time depending on the hardware involved.  You 
> mean you have never done that?  I have code with address clauses that 
> depend on system calls made at run-time.
> 
> So loosen up a little Marin, and try writing non-static representation 
> clauses.  Remember 13.1(22) that I referenced above, and that 'Size for 
> objects (but not subtypes) must be static, RM 13.3(41). But you should 
> be able to do a lot more with Rep clauses than you have done so far. ;-)
> 


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

[Robert I. Eachus]

Marin David Condic wrote:

> I'm not talking about addresses. Have you never seen a rep clause on a 
> record, for example, that a given compiler will refuse to accept even if 
> it is syntactically legal? I don't happen to have one sitting in my back 
> pocket at the moment, but I *know* I've coded up valid rep clauses on 
> records that compilers have spit out and refused to accept. Technically, 
> it is legal for an implementation to refuse just about any rep clause it 
> doesn't want to be bothered with - so perhaps you've got it coded up one 
> way for one compiler and another way for another compiler.
> 
> Perhaps there's some arcane trick that can be pulled to change rep 
> clauses on a record on the fly, but I've not seen it (and it sure starts 
> sounding *far* more complex than decrypting a simple conditional 
> compilation directive - maybe this is what frustrates me about the 
> opposition to a conditional compile: Everyone holds out some cumbersome, 
> complex, arcane trickery that is orders of magnitude more difficult to 
> understand and utilize properly as an answer in order to avoid something 
> that is capable of being pretty simple & basic.). What I *have* seen is 
> rep clauses that a compiler refuses to accept - and hence I can't even 
> *get* to runtime because I've got compile errors. Legal or not - Moral 
> or not - I still have to get a job done and a conditonal compilation 
> directive of some sort would fix the problem.

Sigh, if you want to win the debate, fine, but I can't help you.  If you 
want to have an easier time of it when writing implementation dependent 
code, pay attention.

My point is not that I have a magic wand that can be waved over your 
program to reduce the amount of implementation code to zero.  My point 
is that if you are willing to do things the Ada way instead of the C 
way, the number of system dependent files becomes very small.

It would be nice if you could write your code so that all of the that 
code depended on System, so you didn't need to maintain multiple 
versions.  To some extent that is a bug in the language that we 
discussed in this thread.  (Implementations where System.Name is 
useless.)  What I am trying to say, is use these techniques, and you 
will end up with one or two files that need to be changed when porting.

If you want to use a preprocessor to maintain that file, fine.  Many Ada 
compilers actually supply one, or you can use cpp.  Personally my style 
is to provide a "generic" version and to expect those who port the code 
to tailor it.  Optimally, that file contains only a package body, but 
doing that requires going to extremes you might not like.  Just to give 
one example,  You might define two interfaces for some OS calls and 
choose which one to use every time the interface is called.  This 
requires that the code that calls them, and the parameters passed, are 
in a nested scope.  This often adds extra overhead to system calls. 
Worth it?  You choose.  But putting all the system dependent cruft in 
one compilation unit in my experience, should be automatic.

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

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:401272E3.4040506@noplace.com...
...
> Oh sure. They are better than a sharp stick in the eye and if you have
> to  control representation, they're an elegant solution. But they are
> still "Butt Ugly" in the sense that the instant you use one, you can't
> promise that the code will work *anywhere* except on the one
> compiler/target where you built it.

There is hardly any (useful) code that will work *anywhere*. Most existing
free Ada code won't run on Janus/Ada out of the box because Integer is
16-bit -- and thus a lot of operations overflow. (Of course, there's no
problem with proper type declarations, but those are rare.) And a lot of
code is dependent in some way on the target - for GUI or output devices or
whatever. Certainly adding a rep. clause has little effect on that.
Especially if your world view pretty much starts and ends with PC hardware
(as mine does practically).

We build Claw from the ground up with the intent of making it portable to
every Windows compiler -- yet there a quite a few differences that we have
to deal with. So rep. clauses don't bother me; it is extremely rare that
they would make code less portable than it already is.

> As for submitting something to the ARG? I'll leave that to the language
> lawyers. They'll come up with far better proposals than I could ever
> write - so long as they think the idea might be a good one.

The language lawyers are unlikely to even pay any attention to it unless you
submit a worked out change request. We have enough such requests that we
certainly aren't looking for more!

I view this is list pretty much as what Robert Dewar called a "chat list" -
a place where people gripe a lot, turn molehills into mountains (and vice
versa), and you can't gauge much of anything by the conversations here. I
read this list mainly as part of my work for one of my other hats (webmaster
at adaic.org) -- I'm trolling for newsworthy items. There have been
occassional ideas where I got excited enough to propose something to the ARG
("private with" is the one that comes to mind), but these days I feel
swamped enough that it would have to be a stupendous idea before I'd make
more work for myself.

So, if you want something done, you need to take action to make a proposal
on Ada-Comment. It certainly doesn't need to be perfect - and even if it is,
the ARG would change it all around before standardizing it - but if no one
asks, it's very unlikely that the topic would even come up. Griping here may
feel good, but it has virtually no impact on the future of Ada.

                          Randy.



 I'm just the
> end-user of Ada - a customer - expressing what he thinks would make the
> language more usable on a day-to-day level. We're a dwindling herd, so
> maybe those opinions ought to get some attention by the people who make
> and sell Ada. Hope springs eternal! :-)

Re: Standard Ada Preprocessor

[Stephane Richard]

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

What's the URL for Ada-comment?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:10160jcm6ma1acf@corp.supernews.com...
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:401272E3.4040506@noplace.com...
> ...
> > Oh sure. They are better than a sharp stick in the eye and if you have
> > to  control representation, they're an elegant solution. But they are
> > still "Butt Ugly" in the sense that the instant you use one, you can't
> > promise that the code will work *anywhere* except on the one
> > compiler/target where you built it.
>
> There is hardly any (useful) code that will work *anywhere*. Most existing
> free Ada code won't run on Janus/Ada out of the box because Integer is
> 16-bit -- and thus a lot of operations overflow. (Of course, there's no
> problem with proper type declarations, but those are rare.) And a lot of
> code is dependent in some way on the target - for GUI or output devices or
> whatever. Certainly adding a rep. clause has little effect on that.
> Especially if your world view pretty much starts and ends with PC hardware
> (as mine does practically).
>
> We build Claw from the ground up with the intent of making it portable to
> every Windows compiler -- yet there a quite a few differences that we have
> to deal with. So rep. clauses don't bother me; it is extremely rare that
> they would make code less portable than it already is.
>
> > As for submitting something to the ARG? I'll leave that to the language
> > lawyers. They'll come up with far better proposals than I could ever
> > write - so long as they think the idea might be a good one.
>
> The language lawyers are unlikely to even pay any attention to it unless
you
> submit a worked out change request. We have enough such requests that we
> certainly aren't looking for more!
>
> I view this is list pretty much as what Robert Dewar called a "chat
list" -
> a place where people gripe a lot, turn molehills into mountains (and vice
> versa), and you can't gauge much of anything by the conversations here. I
> read this list mainly as part of my work for one of my other hats
(webmaster
> at adaic.org) -- I'm trolling for newsworthy items. There have been
> occassional ideas where I got excited enough to propose something to the
ARG
> ("private with" is the one that comes to mind), but these days I feel
> swamped enough that it would have to be a stupendous idea before I'd make
> more work for myself.
>
> So, if you want something done, you need to take action to make a proposal
> on Ada-Comment. It certainly doesn't need to be perfect - and even if it
is,
> the ARG would change it all around before standardizing it - but if no one
> asks, it's very unlikely that the topic would even come up. Griping here
may
> feel good, but it has virtually no impact on the future of Ada.
>
>                           Randy.
>
>
>
>  I'm just the
> > end-user of Ada - a customer - expressing what he thinks would make the
> > language more usable on a day-to-day level. We're a dwindling herd, so
> > maybe those opinions ought to get some attention by the people who make
> > and sell Ada. Hope springs eternal! :-)
>
>
>

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Stephane Richard" <stephane.richard@verizon.net> wrote in message
news:XNPQb.5318$Ig2.1236@nwrdny02.gnilink.net...
> What's the URL for Ada-comment?

There is a page describing access to Ada-Comment at:

http://www.adaic.com/standards/articles/comment.html

              Randy.

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> Tell me, how do you solve the situation where API call to your
> OS requires 3 parameters on one platform, and 2 on another? No
> if statement can solve that for you.

Of course it can, see above.  I sometimes feel dirty having two Ada 
templates bound (by the linker) to the same C function, and depending on 
configuration constants to insure that I make call with the correct 
parameters for this environment.  But I do 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

[Marin David Condic]

I agree that if you can isolate something down in a low-level "System 
Dependency" package and swap those out easily, that you have *an* answer 
to some (if not all) problems. I've done this thousands of times. I've 
described cases elsewhere in this thread that *must* be dealt with at 
compile time (either by having separate configuration dependent units 
and some kind of conditional build tools or by having conditional 
compilation.) I'll bet you've even encountered things like a given 
declaration that works fine on one compiler but doesn't work on another 
or a statement that is legal and compiles for one compiler but is 
illegal for another. There are all sorts of allowed compiler differences 
- without even bringing up the subject of trying to get around compiler 
bugs.

So if there's issues that have to be resolved at compile time and I 
can't guarantee that there is some external configuration management 
and/or build tools available to make maintaining separate units possible 
(if not always desirable) then I want some kind of conditional 
compilation to help me maintain a single body of code that works for 
more than one configuration.

MDC


Georg Bauhaus wrote:
> What kind of difficulties do you see that could be better solved
> by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
> versa? Dependence on pragmata?)
> 
> I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p.
> Ada source text is chopped where necessary using make.
> (Operating) System specific routines are are assembled into a
> package hierarchy (which I naively had top-level-named "System" (and
> that triggers a bug box in GCC 34 after looping (the maintainers
> say that, obviously, a library unit should not be modified...)))
> Then a branch renames package Systems.Windows, another renames
> package Systems.UNIX (or similarly).
> 
> The problem that leads GNAT 3.15p to reject another unit is
> apparently a bug in GNAT 3.15p that has been fixed in GCC 34.
> I like this better than having to construct sources around a
> compiler bug/limitation using hopefully temporary preprocessor #ifs.
> 



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

[Dmitry A. Kazakov]

On Thu, 22 Jan 2004 13:19:08 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Robert I. Eachus <rieachus@comcast.net> wrote:
>
>: 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?
>
>ObjectAda:
> The Available System Names are: S370, I80X86, I80386, MC680X0,
>VAX, TRANSPUTER,

Should that mean they have a compiler for Inmos T805? I am impressed!

> RS_6000, MIPS, HP9000_PA_RISC, HP9000_300, SPARC.
>
> Current System.System_Name is: I80386.

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

Re: why ada is so unpopular ?

[Marin David Condic]

I'm aware of who takes care of Java's library and the differences 
between Java and Ada with respect to reference implementation versus 
standards. The point is that if Java can manage to have a library and a 
GUI that is at least mostly portable (via reference implementation) then 
why can't Ada? Its proven to be a popular route and one that can be 
handled well enough to keep the user community happy. It adds leverage 
to development and makes Java a good choice for lots of apps. Is Ada 
going to sit around and say "Sure it could be useful to you but I won't 
do it because it violates some intellectual purism I have in mind..."? 
That just makes language choice really simple: use Java. ;-)

MDC

Dennis Lee Bieber wrote:
> 
> 	Most likely, SUN. Java is, essentially, owned by one company.
> THEY define it, and they release the reference implementation. What Sun
> releases, in effect, defines the "standard".
> 
> 	Ada, OTOH, is not defined by implementations -- the converse in
> fact. The formal standard document defines the language, implementations
> are expected to conform to that standard. When Ada was first defined,
> one of the requirements of the language was that there be no supersets
> or subsets of the language. Any differences from the standard meant that
> the result language could NOT be called Ada -- in those days, if anyone
> could be said to own Ada, it was the US DoD <G>.
> 
> 	The other item is that Java's GUI is defined at a high-level,
> and relies on low-level /OS specific/ code in the JVM. There is no such
> beast in Ada. Any graphical library would have to be built in versions
> for each OS.
> 
> --  
>  > ============================================================== <
>  >   wlfraed@ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
>  >      wulfraed@dm.net     |       Bestiaria Support Staff       <
>  > ============================================================== <
>  >           Home Page: <http://www.dm.net/~wulfraed/>            <
>  >        Overflow Page: <http://wlfraed.home.netcom.com/>        <


-- 
======================================================================
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: why ada is so unpopular ?

[Jeff C,]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:400BD4B5.6000307@noplace.com...
> I don't know about the Gtk license itself or why GtkAda would have to
> modify it slightly to enable the writing of proprietary software. What I
> gathered by looking at the GtkAda license at least was that one could
> develop an entirely proprietary app that made the Gtk calls through the
> GtkAda binding. If one was doing a Gtk based interface, GtkAda seems
> like the only logical choice (unless one needs Gtk capabilities that
> aren't supported in GtkAda - a problem that all such bindings have and
> an argument as to why Ada ought to have its own GUI.)
>
> It seems the best choice for a semi-portable interface if that is the
> requirement. GPL "infection" does not seem to be an issue AFAICS.
>
> MDC
>
> Preben Randhol wrote:
> >
> > This package is distributed under the GPL license, slightly modified so
> > that you can create proprietary software with this toolkit. The license
> > is actually the same as the GNAT library itself. You should also read
> > the Gtk license itself if you intend to do proprietary software based on
> > gtk and GtkAda.
> >
> >
>

The "read the license part" is just a warning that this software (like
almost
all software) is covered by A license so make sure you understand the
terms before development.


The reason that the GNAT libraries and GtkAda use a modified GPL instead
of an LGPL is that it is difficult  (if not impossible) to comply with the
terms of
the LGPL in Ada (and in many cases C++) with proprietary distribution.

WARNING. NON LAWYER APPROXIMATION OF TRUTH TO FOLLOW

The LGPL requires that you distribute source with your execuables or that
you
distribute your execuables in such a way that the components that are LGPL
can
be updated by the end users (e.g. dynamically link to the LGPL library or
provide .o files for all the proprietary stuff)..This woulld in theory allow
an end user
to fix a bug in the LGPL component (or get a bug fix link library) and
"update"
the program.

The problem in Ada (and actually in other languages) is that there are
pieces of
code that at hard to do this with. If you have and LGPL generic it is
essentially impossible
with GNAT to have that be an LGPL component since the generic expantion
happens
at compile time. Something like this is also true of C++ and to some exent C
header
files.

So the GMGPL is actually a slightly lesser (in RMS speak) language than the
LGPL (meaning
that it does not require the "field upgrade" capability of the LGPL.

Re: why ada is so unpopular ?

[Robert I. Eachus]

Jeff C, wrote:

> So the GMGPL is actually a slightly lesser (in RMS speak) language than the
> LGPL (meaning that it does not require the "field upgrade" capability of the LGPL.

I am not picking on Jeff, who does a good job of describing why GTK+ 
uses LGPL and GtkAda uses GMGPL.  I just want to say that the consensus 
is that GtkAda can be used without any "Gnu contamination" of your 
application.  You can release such a program as proprietary or if you 
prefer copylefted or into the public domain.  All you really need to 
know is that the respective developers got their licensing right so that 
you don't need to worry.

As to GtkAda, it seems to be the consensus Ada graphics library right 
now.  It would be nice if someone would update it, but probably the best 
way to describe the situation is that it is much better than "good 
enough" so no one currently seems to feel a need to do better.

-- 
                                           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: why ada is so unpopular ?

[cl1]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:_NedndNu6J_W_5Hd4p2dnA@comcast.com...
> Jeff C, wrote:
>
> > So the GMGPL is actually a slightly lesser (in RMS speak) language than
the
> > LGPL (meaning that it does not require the "field upgrade" capability of
the LGPL.
>
> I am not picking on Jeff, who does a good job of describing why GTK+
> uses LGPL and GtkAda uses GMGPL.  I just want to say that the consensus
> is that GtkAda can be used without any "Gnu contamination" of your
> application.  You can release such a program as proprietary or if you
> prefer copylefted or into the public domain.  All you really need to
> know is that the respective developers got their licensing right so that
> you don't need to worry.
>
> As to GtkAda, it seems to be the consensus Ada graphics library right
> now.  It would be nice if someone would update it, but probably the best
> way to describe the situation is that it is much better than "good
> enough" so no one currently seems to feel a need to do better.

Last i checked gtkada was current with gtk+
http://libre.act-europe.fr/GtkAda/
and it also has some stuff that gtk+ doesn't have(not that i have used that
stuff)
>
> -- 
>                                            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: why ada is so unpopular ?

[Robert I. Eachus]

cl1 wrote:

> Last i checked gtkada was current with gtk+
> http://libre.act-europe.fr/GtkAda/
> and it also has some stuff that gtk+ doesn't have(not that i have used that
> stuff)

Shrug.  I would like it if GtkAda had a more Ada-like binding. But as I 
said it is more than good enough so other things are higher on my 
priority list.

-- 
                                           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: why ada is so unpopular ?

[Preben Randhol]

On 2004-01-20, Robert I. Eachus <rieachus@comcast.net> wrote:
>
> Shrug.  I would like it if GtkAda had a more Ada-like binding. But as I 
> said it is more than good enough so other things are higher on my 
> priority list.

Please descibe what you mean.


-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: why ada is so unpopular ?

[Robert I. Eachus]

Preben Randhol wrote:
> On 2004-01-20, Robert I. Eachus <rieachus@comcast.net> wrote:
> 
>>Shrug.  I would like it if GtkAda had a more Ada-like binding. But as I 
>>said it is more than good enough so other things are higher on my 
>>priority list.
> 
> 
> Please descibe what you mean.

Exactly what I said.  There are some areas where, when I use GtkAda, I 
think "It might be nice if..."  Then when I think about it a bit more, I 
realize what a major undertaking it would take compared to the very 
minor benefit, and forget about it.  I'd mention specific cases, but as 
I said, I can't even think of any that were worth remembering. ;-)

Just in case anyone thinks I am 'damning with faint praise', there is a 
very good reason that GtkAda is currently the most used Ada graphics 
interface, and that is that it is by far the best.  There are lots of 
other things where an investment of my time may make a difference, 
excuse me if I get back to them.

Incidently when Ada0Y is finalized and compilers comform to it, I 
suspect that changing GtkAda to use interfaces and constructors in some 
areas will be well worth the effort.  But that is probably a project for 
next year, or the year after.

-- 
                                           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: why ada is so unpopular ?

[Stephen Leake]

Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> writes:

> On 2004-01-20, Robert I. Eachus <rieachus@comcast.net> wrote:
> >
> > Shrug.  I would like it if GtkAda had a more Ada-like binding. But as I 
> > said it is more than good enough so other things are higher on my 
> > priority list.
> 
> Please descibe what you mean.

I'll jump in here :)

GtkAda currently follows Gtk+ in using strings to name events; the Ada
way would be to use enumerals, named constants, or function names.

GtkAda also allows the user to easily bind an incorrect handler to an
event ("incorrect" here meaning "has the wrong parameter/result
profile"). The error is reported at run-time, but the Ada way is to
catch this error at compile time.

In my GtkAda projects, I'm attempting to fix both issues, by providing
child packages for the current GtkAda packages that present the "Ada
way". If it works out, I'll propose it as a change to be incorporated
(some things would benefit from being primitive operations, which must
be in the same package as the type).

-- 
-- Stephe

Re: why ada is so unpopular ?

[Preben Randhol]

On 2004-01-20, Stephen Leake <Stephe.Leake@nasa.gov> wrote:
> GtkAda also allows the user to easily bind an incorrect handler to an
> event ("incorrect" here meaning "has the wrong parameter/result
> profile"). The error is reported at run-time, but the Ada way is to
> catch this error at compile time.

How do you bind your handles? If I remember correctly there are two
ways, the C way and the Ada way already. At least I use marshals which
will make the compiler catch errors at compile time.

Can you give a source example?

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: why ada is so unpopular ?

[Marin David Condic]

Its *always* worth learning a programming language because it can show 
you the strengths and weaknesses of other languages & improves your 
programming skills in general. Learning Ada might teach you a thing or 
two about what is good/bad about something like C++ - whereas ignorance 
of Ada and knowledge only of C++ (for example) tends to leave you blind 
about how things might otherwise be done.

As for earning anything from the experience, you might consider this: If 
you decide to write a *useful* program, there are ways that the program 
may generate some money for you. Nobody will care much that it was 
written in Ada or C++ or Java. Come up with a good idea and get a 
baseline product built and see if you can find some users. Make money by 
selling upgrades or by licensing the technology or any number of other 
business models.

As for simple employment, while a company may be looking for a dozen 
years of experience in Programming Language X - showing them on your 
resume that you know a *variety* of languages tends to indicate that you 
are a quick learner and adaptable as well as well educated. Any 
experience cannot possibly hurt you.

Learning some Ada is an excellent way of discovering techniques and 
capabilities you aren't likely to see duplicated in other languages.

Szymon Guz wrote:
> 
> I see. But I'd like to know if it is worth learning. I'd like to write a 
> program and maybe in future earn on that and I still don't know what to 
> choose ada or C++.
> 


-- 
======================================================================
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: why ada is so unpopular ?

[Hyman Rosen]

Marin David Condic wrote:
> showing them on your resume that you know a *variety* of languages
 > tends to indicate that you are a quick learner and adaptable as well
 > as well educated. Any experience cannot possibly hurt you.

I interviewed a programming candidate for my compnay not long ago who
had C++ and Ada on his resume. I was looking forward to a nice chat on
comparing the two languages. Unfortunately, it turned out that the
candidate knew nothing about either one.

Re: why ada is so unpopular ?

[cl1]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:WskOb.68$Wm4.21@nwrdny01.gnilink.net...
> Marin David Condic wrote:
> > showing them on your resume that you know a *variety* of languages
>  > tends to indicate that you are a quick learner and adaptable as well
>  > as well educated. Any experience cannot possibly hurt you.
>
> I interviewed a programming candidate for my compnay not long ago who
> had C++ and Ada on his resume. I was looking forward to a nice chat on
> comparing the two languages. Unfortunately, it turned out that the
> candidate knew nothing about either one.
and this is why it took me almost 2 years to find a job

Re: why ada is so unpopular ?

[Hyman Rosen]

cl1 wrote:
> and this is why it took me almost 2 years to find a job

You mean that you too put things on your resume that you
didn't know anything about?

Re: why ada is so unpopular ?

[cl1]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:MQmOb.124$Wm4.66@nwrdny01.gnilink.net...
> cl1 wrote:
> > and this is why it took me almost 2 years to find a job
>
> You mean that you too put things on your resume that you
> didn't know anything about?

god no! but there are so many people who do it's been like playing the
lottery to get my resume in front of companies to get an interview. I no
longer have this problem as of last friday. (yippie) i start my new job as
and ASP/VB developer on monday...
... i feel like such a whore. but at least i'm writing code :)

someday i hope to write really good stuff with ada on a linux platform as
soon as i can find someone to hire me. but i think it would help for me to
have more than a few months of learning experiance with ada before i attempt
that endevor.

Re: why ada is so unpopular ?

[Marin David Condic]

Resumes are a little like "Marketing" (in the bad sense of the word). 
You often have to divide everything by 10. Perhaps this is why companies 
seem to be paying very little attention to them these days. I know when 
my boss and I are discussing personnel, his push is always to find 
someone that someone else in the organization can give a good 
recommendation for or otherwise get them vetted by a reliable source. 
Blind resumes may or may not tell you much about the candidate. Even if 
the person didn't exagerate his skills too badly, it doesn't tell you 
much about work habbits and interpersonal skills. I don't care how many 
languages a guy has or how much experience he can show if he is 
incapable of getting a job done on time or can't get along with his 
co-workers & customers. You sometimes can't tell that until its too 
late. ;-)

MDC


Hyman Rosen wrote:
> I interviewed a programming candidate for my compnay not long ago who
> had C++ and Ada on his resume. I was looking forward to a nice chat on
> comparing the two languages. Unfortunately, it turned out that the
> candidate knew nothing about either one.


-- 
======================================================================
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: why ada is so unpopular ?

[chris]

Szymon Guz wrote:
> Dmytry Lavrov wrote:
> 
>> Military uses. It's answer to question why unpopular.
> 
> I see. But I'd like to know if it is worth learning. I'd like to write a 
> program and maybe in future earn on that and I still don't know what to 
> choose ada or C++.

I've tried Gtkmm and GtkAda.  Gtkmm was easier to use to begin with, but 
I ran into a problem with the model I was building because I didn't 
understand C++ too well (templates specifically).  In Ada it was easier 
to build the model because I know the language fairly well, but the view 
in GtkAda was a little more difficult (or in the way... don't like 
generically instantiated handlers).

It's a trade off.  I went for Ada, but only because C++ got on my nerves 
and I found the Oz documentation too academic... there are enough 
academics messing with my brain at the minute. ;)

Personally I'd try both and see what fits... no wait!  I did ;)


Chris

Re: why ada is so unpopular ?

[Jano]

Szymon Guz dice...
> Hi,
> I'd like to know how ada is popular ? And i which countries. I'm asking 
> because I live in Poland and here I couldn't find any firm that use it.

It's the language of choice to teach several subjects in Zaragoza 
(Spain) college, computer engineering. I couldn't say about other 
colleges in Spain.

Introduction to programming.
Data structures and algorithms.
Concurrent programming.
Real time programming.
Embedded systems.

I may be missing something.

Re: why ada is so unpopular ?

[Luke A. Guest]

On Sat, 17 Jan 2004 12:15:35 +0100, Szymon Guz wrote:

> Hi,
> I'd like to know how ada is popular ? And i which countries. I'm asking 
> because I live in Poland and here I couldn't find any firm that use it.

Well, I wouldn't say that Ada is unpopular. There are other factors to
take into consideration:

1) Management don't know about Ada.
2) Management tend to want the programmers to use languages that are the
current fad, i.e. C/C++.
3) I had to learn Ada at uni and I had no idea about before then. I
actually love the language, It has so many features not found anywhere
else that are (IMO) necessary for development.
4) Programmers learn what is required of them.
5) The DoD (supposedly) dropped all support for Ada and this then looks
(to the outsider) that the language is dead.

I think that if enough programmers get to know Ada, I think that better
programming standards will emerge, but it's up to those who know it
and those who can tell others about it to spread the word and make sure
that others start to use it.

Luke.

Re: why ada is so unpopular ?

[Hyman Rosen]

Luke A. Guest wrote:
> 2) Management tend to want the programmers to use
 > languages that are the current fad, i.e. C/C++.

And they all communicate in that fad language English
instead of using NewSpeak. Despite the fact that in
NewSpeak your sentences are clear and unambiguous,
people are still required to use languages which fail
to accurately deliver to the listener the intent of
the speaker. Remember, "You can't put too much water
into a nuclear reactor!"

Re: why ada is so unpopular ?

[Ludovic Brenta]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:

> On Sat, 17 Jan 2004 12:15:35 +0100, Szymon Guz wrote:
> 
> > Hi,
> > I'd like to know how ada is popular ? And i which countries. I'm asking 
> > because I live in Poland and here I couldn't find any firm that use it.
> 
> Well, I wouldn't say that Ada is unpopular. There are other factors to
> take into consideration:
> 
> 1) Management don't know about Ada.
> 2) Management tend to want the programmers to use languages that are the
> current fad, i.e. C/C++.

In my view their attitude is more cynical than that.  The reason why
they want programmers to use "mainstream" languages is so they can
replace programmers easily without retraining.  They want programmers
to be disposable and interchangeable just like a piece of commodity
hardware.  They don't mind that their language of choice has an
adverse effect on the quality of software, because they're interested
in selling bug fixes, upgrades and maintenance.  They also don't mind
that disposable programmers will produce disposable software.  They're
in fact quite happy about it.

I don't like to sound so pessimistic, but I've actually gotten a
manager to admit openly to all of the above.  Now that was at a very
large company that makes enterprise data storage products.  I was not
a nuclear, aerospace, or rail company.  I hope there are still
companies that try to produce quality software.

> 3) I had to learn Ada at uni and I had no idea about before then. I
> actually love the language, It has so many features not found anywhere
> else that are (IMO) necessary for development.

Yes.  Furthermore, I have found that people who learn Ada often change
their attitude regarding software development.  They no longer want to
develop junk, disposable software; instead they want to develop
quality software that lasts.

(yes, there are many people who actually like developing disposable
software; those are the ones who promote and improve on scripting
languages like Perl or Python to a point where they change from being
prototyping languages to being implementation languages).

> 4) Programmers learn what is required of them.
> 5) The DoD (supposedly) dropped all support for Ada and this then looks
> (to the outsider) that the language is dead.
> 
> I think that if enough programmers get to know Ada, I think that better
> programming standards will emerge, but it's up to those who know it
> and those who can tell others about it to spread the word and make sure
> that others start to use it.
> 
> Luke.

I would like to see more free software developed in Ada.  The free
software world does not try to produce disposable software, and
therefore would benefit from a language that helps improve quality.
Perhaps, that way, Ada will become a little bit more mainstream.

-- 
Ludovic Brenta.

Re: why ada is so unpopular ?

[Hyman Rosen]

Ludovic Brenta wrote:
 > I've actually gotten a manager to admit openly to all of the above.

I'll bet he was just tired of your badgering him about Ada,
and told you that to get you to go away and leave him alone.
I do that with my three-year old sometimes too.

Re: why ada is so unpopular ?

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> I'll bet he was just tired of your badgering him about Ada,
> and told you that to get you to go away and leave him alone.
> I do that with my three-year old sometimes too.

I'm glad to know your three-year-old badgers you about Ada. ;-)
Good taste.

- Bob

Re: why ada is so unpopular ?

[chris]

Luke A. Guest wrote:
> 
> Well, I wouldn't say that Ada is unpopular. There are other factors to
> take into consideration:
> 
> 1) Management don't know about Ada.

If they knew, would they care?  In the desktop, I don't think so. 
Ludovic is right in the disposability of programmers.  Especially today.

Do you know how many software developers are out in just the UK there 
looking for jobs (like me)?  Loads!  The more experienced SEs might even 
have to take a pay drop (in terms of what they're worth) just to get a 
job.  There is not as much money as there used to be out there and 
people aren't going to take risks moving over to other technologies if 
the technologies they have do the job and there's a steady stream of 
programmers conversant in those technologies available.  Unis teach 
graduates the hot technology and the cycle repeats!


> 2) Management tend to want the programmers to use languages that are the
> current fad, i.e. C/C++.
> 3) I had to learn Ada at uni and I had no idea about before then. I
> actually love the language, It has so many features not found anywhere
> else that are (IMO) necessary for development.

I used to think so, but have found similar features in other languages 
expressed more powerfully and also with the benefit of run time 
portability and lots of tools targetting the desktop developer.  Ocaml 
for instance library support on the desktop exceeds Ada's with the 
exception of GUI toolkits (there are only a couple of these), despite 
being a functionally imperative language from the research community (or 
maybe it doesn't, but appears so since there is a central repository 
full of current links & sw).

I think the perception from uni is that Ada is a good language, but why 
spend time making data structure libraries or downloading them when C++, 
C#, Delphi (iirc) and Java have them out of the box.  Data structures 
will be remedied but what about XML?  It has no place in the standard 
but what if compilers came with an XML parser, a gui toolkit and 
whatever else need be.  Note it doesn't take ACT (specifically) to do 
this.  Someone could package it up for people and let them download it. 
  Some Ada compiler companies might do this already but are they expensive?


> I think that if enough programmers get to know Ada, I think that better
> programming standards will emerge, but it's up to those who know it
> and those who can tell others about it to spread the word and make sure
> that others start to use it.

It's a nice language yes, but it's one of *many* such languages.


Chris

Re: why ada is so unpopular ?

[Marin David Condic]

Its not a totally illigitimate concern. Programmers come and go. Its 
expensive and risky to use *anything* outside of the mainstream.

Hardware is a good example. Would you rather support a current version 
of an IBM PC or an old DEC Alpha/VMS system? The old system is *really* 
costly to maintain because nobody is mass producing parts for it and not 
as many programmers know how to use it, etc. All that adds cost to a 
project. The technical superiority of an Alpha over a PC is irrelevant. 
You'd be building your system on top of an antique and the first 
breakdown you have is going to kill you.

As for "disposable" programmers - would you be willing to sign a 
long-term contract promising never to leave the company you are at? 
Probably not. Hence a manager needs to consider the possibility that you 
might quit and what does he do in that case? He would have to hire and 
train someone else - costly and time consuming. So using a language that 
is widely known and platforms that are widely used, he minimizes risks 
and costs. That's what managers are *supposed* to do.

Rather than complain about "stupid management" we ought to be helping 
them solve their problems. If Ada had much more capability and 
widespread use, then the manager has substantially less risk in going 
that route. Give the poor guy something he can *trust* will be around, 
supported, low cost and high leverage and you may discover he starts 
making decisions more to your liking.

MDC



chris wrote:
> 
> If they knew, would they care?  In the desktop, I don't think so. 
> Ludovic is right in the disposability of programmers.  Especially today.
> 

-- 
======================================================================
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: why ada is so unpopular ?

[Stephen Leake]

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

> Rather than complain about "stupid management" we ought to be helping
> them solve their problems. If Ada had much more capability and
> widespread use, then the manager has substantially less risk in going
> that route. Give the poor guy something he can *trust* will be around,
> supported, low cost and high leverage and you may discover he starts
> making decisions more to your liking.

In my field, the time it takes to learn Ada is quite small compared to
the time it takes to learn how to write useful programs. The later
involves data structures, real-time scheduling, the physics of
actuators and sensors, and control algorithms. None of those things
are "main stream" :).

And yet the managers still say "we can't teach people new programming
languages". 

-- 
-- Stephe

Re: why ada is so unpopular ?

[Marin David Condic]

Been there. Done that. Got the T-Shirt. You're right that in lots of 
domains, it takes you more time to learn the domain than to learn the 
language. Managers love to hire guys who already have experience in the 
domain for exactly that reason.

But that doesn't really address the issue that a manager has when 
choosing a language. Training people is *part* of the cost, but by no 
means all of it. If you're building things using sensors and actuators 
and control algorithms like I am, then you're probably talking about 
very long-lived systems that are extremely expensive to verify. 
Especially in some environment like that, a manager doesn't want to be 
sitting on top of a dead-end language. If it becomes mostly non-existant 
in ten years and his control has to live for another 30 years, he is 
most eggregiously sexually penetrated when he has to switch to something 
else in mid-project.

I'll reiterate: Give the poor manager something he can have some 
confidence in and believe it will solve his problems and maybe he'll 
start making the decisions you want him to make. He lives or dies by 
things like cost, schedule, time-to-market, risk reduction, etc. 
Selecting some niche language with an uncertain future, a lack of 
industry support, a poverty of tools/libraries (compared to other 
choices) and a profound disinterest on the part of most of the available 
programmers out there just doesn't look like a career-enhancing move. 
Fix that and maybe he'll show more interest in the language.

MDC

Stephen Leake wrote:
> 
> In my field, the time it takes to learn Ada is quite small compared to
> the time it takes to learn how to write useful programs. The later
> involves data structures, real-time scheduling, the physics of
> actuators and sensors, and control algorithms. None of those things
> are "main stream" :).
> 
> And yet the managers still say "we can't teach people new programming
> languages". 
> 


-- 
======================================================================
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: why ada is so unpopular ?

[amado.alves]

"How do you bind your handles?"

I'll step in, too.

Ada has ways of getting the name of 'enumerals' (is that the proper term?) and exceptions as strings, so no problem here. For functions there are compiler-dependent ways (e.g. GNAT's symbolic traceback). And for everything there is ASIS: as the idea is to move in the direction of compile-time, it fits.