* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
@ 2004-01-23 20:03 Leon Winslow
2004-01-24 2:00 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Leon Winslow @ 2004-01-23 20:03 UTC (permalink / raw)
**** Post for FREE via your newsreader at post.usenet.com ****
I'm interested in knowing why no one has mentioned that 40 years ago the
COBAL language included a statement to specify the machine and/or
operating system for the executable code. If you wanted the program to
run on a UNIX box, you essentially entered UNIX at the head of the
program; if you wanted it to run on a Windows box you entered Windows.
The rest of the program remained the same. (Its been a long time since
I used this feature so I don't remember the exact syntax. Maybe someone
else knows?)
Of course, very few compilers actually implemented more than one
option. If you wanted a different one, you usually needed a different
compiler.
The important feature however is that the rest of the program was
independent of the machine that would execute the program. If COBAL
could implement this 40 years ago, why can't we try something similar?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 20:03 Standard Ada Preprocessor (Was: why ada is so unpopular ?) Leon Winslow
@ 2004-01-24 2:00 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 2:00 UTC (permalink / raw)
Probably because it was widely ignored by implementers and hence pretty
close to useless. In a perfect world, all compilers would recognize
platform differences and correct for them so you had 100% portable code
- but this is not likely to happen while I'm above ground. Its really
pretty hopeless to expect that a compiler writer can forsee *all*
platform differences and deal with them via some abstraction, so you
have to leave it in the hands of the developer. Somehow, the developer
needs to detect and code around such platform differences.
MDC
Leon Winslow wrote:
> **** Post for FREE via your newsreader at post.usenet.com ****
>
> I'm interested in knowing why no one has mentioned that 40 years ago the
> COBAL language included a statement to specify the machine and/or
> operating system for the executable code. If you wanted the program to
> run on a UNIX box, you essentially entered UNIX at the head of the
> program; if you wanted it to run on a Windows box you entered Windows.
> The rest of the program remained the same. (Its been a long time since
> I used this feature so I don't remember the exact syntax. Maybe someone
> else knows?)
>
> Of course, very few compilers actually implemented more than one
> option. If you wanted a different one, you usually needed a different
> compiler.
>
> The important feature however is that the rest of the program was
> independent of the machine that would execute the program. If COBAL
> could implement this 40 years ago, why can't we try something similar?
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
> http://www.usenet.com
> Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m o d c @ a m o g
c n i c . r
"Face it ladies, its not the dress that makes you look fat.
Its the FAT that makes you look fat."
-- Al Bundy
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* RE: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
@ 2004-01-26 20:03 Lionel.DRAGHI
2004-01-26 23:10 ` Robert A Duff
0 siblings, 1 reply; 85+ messages in thread
From: Lionel.DRAGHI @ 2004-01-26 20:03 UTC (permalink / raw)
To: comp.lang.ada
| -----Message d'origine-----
| De: Warren W. Gay VE3WWG [mailto:warren@ve3wwg.tk]
...
| >>
| >>> C with preprocessor directives is also Maintenance Hell.
| I don't see
| >>> that it's a better Hell.
| >>
| >> Given that it should be optional, it would not be your problem ;-)
|
| I would tend to agree. There is no "pure" way to make non-trivial
| code portable.
|
| If we go back to the "non-normalized database" metaphore, keeping
| separate versions of code for purity sake (to avoid conditional
| compilation), is like having to update a customer name in a
| database in 12 different tables. This potentially leads to
| leaving one instance of that name wrong, or left unchanged.
A good design allows to separate common and customized code in a pretty
sharp way.
There is no free lunch, and you need some more code and design.
Method template and Strategy patterns are useful here.
It is possible (and not so hard) to get a software with no embedded dead
code, and with almost no possible source confusion, that is, with the whole
configuration defined in one source.
Lets consider two OS interfaces (not compiled code) :
----------------------------------------------------------
package OS_Interface is
procedure Open_File (Name ...
...);
...
-- etc.
private
type Abstract_Interface is abstract ...
procedure Open_File (Abstract_Interface ...
Name ...
...) is abstract;
...
procedure Register_As_Concrete (Abstract_Interface'class'Access...);
-- used by child interfaces to register themself
end OS_Interface;
----------------------------------------------------------
package body OS_Interface is
Concrete : ... -- pointer to the concrete Interface,
-- set by Register_As_Concrete
procedure Open_File (Name ...
...) is
begin
Open_File (Concrete,
Name ...); -- let's dispatch to the concrete
-- Interface
end Open_File;
...
end OS_Interface;
----------------------------------------------------------
package OS_Interface.Windows is
type Windows_Interface is new Abstract_Interface ...
-- define abstract operations
-- redefine some of the concrete operations.
...
procedure Register;
-- register this one as the concrete interface
-- by calling Register_As_Concrete with
-- a local dummy instance of Windows_Interface
end OS_Interface.Windows;
For the configuration, you need some separate configuration procedure :
----------------------------------------------------------
separate (Main)
procedure Configure is
begin
OS_Interface.Windows.Register;
end Configure;
But this is the only compilation unit provided in several versions, the only
one that you need to manage carefully in your configuration system.
As for conditional compilation systems, some external configuration is
pretty unavoidable.
Note also that calls to (for example) a specific Linux thin binding will be
hidden into the OS_Interface.Linux package : Register is the only operation
in OS_Interface child specification, so if you don't "with" it within the
Configure operation, this code is not included in the executable.
Another advantage is that you don't touch common code when adding or
modifying some specific implementation. You don't cause useless
recompilations or regression testing.
For user code, the whole stuff is hidden : it just call
OS_Interface.Open_File (Name, ...);
as usual.
One drawback of this template respect to conditional compilation is an added
indirection and dispatching hidden into OS_Interface body.
But if someone care of performance at this point, he is in a desperate
situation.
Another drawback is the difficulty to compare implementations, but it's not
that useful, neither that difficult to do with your favorite environment.
--
Lionel Draghi
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 20:03 Lionel.DRAGHI
@ 2004-01-26 23:10 ` Robert A Duff
0 siblings, 0 replies; 85+ messages in thread
From: Robert A Duff @ 2004-01-26 23:10 UTC (permalink / raw)
Lionel.DRAGHI@fr.thalesgroup.com writes:
The approach you outlined is a good one, in many cases, but:
> One drawback of this template respect to conditional compilation is an added
> indirection and dispatching hidden into OS_Interface body.
> But if someone care of performance at this point, he is in a desperate
> situation.
I have sometimes needed static constants that depend on the
configuration, either for efficiency reasons, or so I could use
them in places where Ada requires static expressions.
- Bob
^ permalink raw reply [flat|nested] 85+ messages in thread
* why ada is so unpopular ?
@ 2004-01-17 11:15 Szymon Guz
2004-01-17 14:27 ` Dmytry Lavrov
0 siblings, 1 reply; 85+ messages in thread
From: Szymon Guz @ 2004-01-17 11:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-17 11:15 why ada is so unpopular ? Szymon Guz
@ 2004-01-17 14:27 ` Dmytry Lavrov
2004-01-17 21:02 ` Szymon Guz
0 siblings, 1 reply; 85+ messages in thread
From: Dmytry Lavrov @ 2004-01-17 14:27 UTC (permalink / raw)
Military uses. It's answer to question why unpopular.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-17 14:27 ` Dmytry Lavrov
@ 2004-01-17 21:02 ` Szymon Guz
2004-01-17 22:36 ` Adrian Knoth
0 siblings, 1 reply; 85+ messages in thread
From: Szymon Guz @ 2004-01-17 21:02 UTC (permalink / raw)
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++.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-17 21:02 ` Szymon Guz
@ 2004-01-17 22:36 ` Adrian Knoth
2004-01-18 9:21 ` Szymon Guz
0 siblings, 1 reply; 85+ messages in thread
From: Adrian Knoth @ 2004-01-17 22:36 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-17 22:36 ` Adrian Knoth
@ 2004-01-18 9:21 ` Szymon Guz
2004-01-18 12:59 ` Ronald Dauster
0 siblings, 1 reply; 85+ messages in thread
From: Szymon Guz @ 2004-01-18 9:21 UTC (permalink / raw)
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++.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-18 9:21 ` Szymon Guz
@ 2004-01-18 12:59 ` Ronald Dauster
2004-01-18 14:17 ` Szymon Guz
0 siblings, 1 reply; 85+ messages in thread
From: Ronald Dauster @ 2004-01-18 12:59 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-18 12:59 ` Ronald Dauster
@ 2004-01-18 14:17 ` Szymon Guz
2004-01-18 14:42 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Szymon Guz @ 2004-01-18 14:17 UTC (permalink / raw)
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 ?
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-18 14:17 ` Szymon Guz
@ 2004-01-18 14:42 ` Marin David Condic
2004-01-18 16:34 ` Preben Randhol
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-18 14:42 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-18 14:42 ` Marin David Condic
@ 2004-01-18 16:34 ` Preben Randhol
2004-01-19 12:59 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Preben Randhol @ 2004-01-18 16:34 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-18 16:34 ` Preben Randhol
@ 2004-01-19 12:59 ` Marin David Condic
2004-01-19 13:06 ` Preben Randhol
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-19 12:59 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-19 12:59 ` Marin David Condic
@ 2004-01-19 13:06 ` Preben Randhol
2004-01-19 13:28 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Preben Randhol @ 2004-01-19 13:06 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-19 13:06 ` Preben Randhol
@ 2004-01-19 13:28 ` Marin David Condic
2004-01-19 13:37 ` Preben Randhol
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-19 13:28 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-19 13:28 ` Marin David Condic
@ 2004-01-19 13:37 ` Preben Randhol
2004-01-20 12:38 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Preben Randhol @ 2004-01-19 13:37 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: why ada is so unpopular ?
2004-01-19 13:37 ` Preben Randhol
@ 2004-01-20 12:38 ` Marin David Condic
2004-01-20 17:31 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-20 12:38 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-20 12:38 ` Marin David Condic
@ 2004-01-20 17:31 ` Warren W. Gay VE3WWG
2004-01-21 12:39 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-20 17:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-20 17:31 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG
@ 2004-01-21 12:39 ` Marin David Condic
2004-01-22 0:05 ` Robert I. Eachus
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-21 12:39 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-21 12:39 ` Marin David Condic
@ 2004-01-22 0:05 ` Robert I. Eachus
2004-01-22 5:59 ` Randy Brukardt
2004-01-22 12:47 ` Marin David Condic
0 siblings, 2 replies; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-22 0:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 0:05 ` Robert I. Eachus
@ 2004-01-22 5:59 ` Randy Brukardt
2004-01-22 12:58 ` Marin David Condic
2004-01-22 14:13 ` Robert A Duff
2004-01-22 12:47 ` Marin David Condic
1 sibling, 2 replies; 85+ messages in thread
From: Randy Brukardt @ 2004-01-22 5:59 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 5:59 ` Randy Brukardt
@ 2004-01-22 12:58 ` Marin David Condic
2004-01-22 17:25 ` Warren W. Gay VE3WWG
2004-01-23 2:47 ` Robert I. Eachus
2004-01-22 14:13 ` Robert A Duff
1 sibling, 2 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-22 12:58 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 12:58 ` Marin David Condic
@ 2004-01-22 17:25 ` Warren W. Gay VE3WWG
2004-01-23 12:24 ` Marin David Condic
2004-01-23 2:47 ` Robert I. Eachus
1 sibling, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-22 17:25 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 17:25 ` Warren W. Gay VE3WWG
@ 2004-01-23 12:24 ` Marin David Condic
2004-01-23 13:46 ` Dmitry A. Kazakov
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-23 12:24 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 12:24 ` Marin David Condic
@ 2004-01-23 13:46 ` Dmitry A. Kazakov
2004-01-23 17:16 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Dmitry A. Kazakov @ 2004-01-23 13:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 13:46 ` Dmitry A. Kazakov
@ 2004-01-23 17:16 ` Warren W. Gay VE3WWG
2004-01-23 17:52 ` Jeffrey Carter
` (3 more replies)
0 siblings, 4 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-23 17:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 17:16 ` Warren W. Gay VE3WWG
@ 2004-01-23 17:52 ` Jeffrey Carter
2004-01-23 21:57 ` Warren W. Gay VE3WWG
2004-01-23 17:56 ` Larry Hazel
` (2 subsequent siblings)
3 siblings, 1 reply; 85+ messages in thread
From: Jeffrey Carter @ 2004-01-23 17:52 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 17:52 ` Jeffrey Carter
@ 2004-01-23 21:57 ` Warren W. Gay VE3WWG
2004-01-24 0:52 ` Jeffrey Carter
` (2 more replies)
0 siblings, 3 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-23 21:57 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 21:57 ` Warren W. Gay VE3WWG
@ 2004-01-24 0:52 ` Jeffrey Carter
2004-01-26 17:19 ` Warren W. Gay VE3WWG
2004-01-24 1:34 ` Marin David Condic
2004-01-24 8:20 ` Pascal Obry
2 siblings, 1 reply; 85+ messages in thread
From: Jeffrey Carter @ 2004-01-24 0:52 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 0:52 ` Jeffrey Carter
@ 2004-01-26 17:19 ` Warren W. Gay VE3WWG
2004-01-27 12:24 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-26 17:19 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 17:19 ` Warren W. Gay VE3WWG
@ 2004-01-27 12:24 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-27 12:24 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 21:57 ` Warren W. Gay VE3WWG
2004-01-24 0:52 ` Jeffrey Carter
@ 2004-01-24 1:34 ` Marin David Condic
2004-01-26 17:27 ` Warren W. Gay VE3WWG
2004-01-24 8:20 ` Pascal Obry
2 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 1:34 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 1:34 ` Marin David Condic
@ 2004-01-26 17:27 ` Warren W. Gay VE3WWG
2004-01-27 12:30 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-26 17:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 17:27 ` Warren W. Gay VE3WWG
@ 2004-01-27 12:30 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-27 12:30 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 21:57 ` Warren W. Gay VE3WWG
2004-01-24 0:52 ` Jeffrey Carter
2004-01-24 1:34 ` Marin David Condic
@ 2004-01-24 8:20 ` Pascal Obry
2004-01-26 17:29 ` Warren W. Gay VE3WWG
2 siblings, 1 reply; 85+ messages in thread
From: Pascal Obry @ 2004-01-24 8:20 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 8:20 ` Pascal Obry
@ 2004-01-26 17:29 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-26 17:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 17:16 ` Warren W. Gay VE3WWG
2004-01-23 17:52 ` Jeffrey Carter
@ 2004-01-23 17:56 ` Larry Hazel
2004-01-24 1:36 ` Marin David Condic
2004-01-23 22:14 ` Randy Brukardt
2004-01-26 9:34 ` Dmitry A. Kazakov
3 siblings, 1 reply; 85+ messages in thread
From: Larry Hazel @ 2004-01-23 17:56 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 17:56 ` Larry Hazel
@ 2004-01-24 1:36 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 1:36 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 17:16 ` Warren W. Gay VE3WWG
2004-01-23 17:52 ` Jeffrey Carter
2004-01-23 17:56 ` Larry Hazel
@ 2004-01-23 22:14 ` Randy Brukardt
2004-01-23 22:42 ` tmoran
2004-01-26 17:50 ` Warren W. Gay VE3WWG
2004-01-26 9:34 ` Dmitry A. Kazakov
3 siblings, 2 replies; 85+ messages in thread
From: Randy Brukardt @ 2004-01-23 22:14 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 22:14 ` Randy Brukardt
@ 2004-01-23 22:42 ` tmoran
2004-01-26 17:50 ` Warren W. Gay VE3WWG
1 sibling, 0 replies; 85+ messages in thread
From: tmoran @ 2004-01-23 22:42 UTC (permalink / raw)
>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?
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 22:14 ` Randy Brukardt
2004-01-23 22:42 ` tmoran
@ 2004-01-26 17:50 ` Warren W. Gay VE3WWG
2004-01-27 12:48 ` Marin David Condic
1 sibling, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-26 17:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 17:50 ` Warren W. Gay VE3WWG
@ 2004-01-27 12:48 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-27 12:48 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 17:16 ` Warren W. Gay VE3WWG
` (2 preceding siblings ...)
2004-01-23 22:14 ` Randy Brukardt
@ 2004-01-26 9:34 ` Dmitry A. Kazakov
2004-01-26 19:23 ` Randy Brukardt
3 siblings, 1 reply; 85+ messages in thread
From: Dmitry A. Kazakov @ 2004-01-26 9:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 9:34 ` Dmitry A. Kazakov
@ 2004-01-26 19:23 ` Randy Brukardt
0 siblings, 0 replies; 85+ messages in thread
From: Randy Brukardt @ 2004-01-26 19:23 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 12:58 ` Marin David Condic
2004-01-22 17:25 ` Warren W. Gay VE3WWG
@ 2004-01-23 2:47 ` Robert I. Eachus
2004-01-23 12:38 ` Marin David Condic
` (2 more replies)
1 sibling, 3 replies; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-23 2:47 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 2:47 ` Robert I. Eachus
@ 2004-01-23 12:38 ` Marin David Condic
2004-01-24 5:23 ` Robert I. Eachus
2004-01-24 8:17 ` Pascal Obry
2004-01-23 16:38 ` Alexandre E. Kopilovitch
2004-01-23 17:24 ` Warren W. Gay VE3WWG
2 siblings, 2 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-23 12:38 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 12:38 ` Marin David Condic
@ 2004-01-24 5:23 ` Robert I. Eachus
2004-01-24 12:28 ` Marin David Condic
2004-01-26 18:03 ` Warren W. Gay VE3WWG
2004-01-24 8:17 ` Pascal Obry
1 sibling, 2 replies; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-24 5:23 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 5:23 ` Robert I. Eachus
@ 2004-01-24 12:28 ` Marin David Condic
2004-01-24 15:32 ` Robert I. Eachus
2004-01-26 18:03 ` Warren W. Gay VE3WWG
1 sibling, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 12:28 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 12:28 ` Marin David Condic
@ 2004-01-24 15:32 ` Robert I. Eachus
2004-01-24 15:43 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-24 15:32 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 15:32 ` Robert I. Eachus
@ 2004-01-24 15:43 ` Marin David Condic
2004-01-25 4:24 ` Robert I. Eachus
2004-01-29 11:17 ` Jacob Sparre Andersen
0 siblings, 2 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 15:43 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 15:43 ` Marin David Condic
@ 2004-01-25 4:24 ` Robert I. Eachus
2004-01-25 16:24 ` Marin David Condic
2004-01-29 11:17 ` Jacob Sparre Andersen
1 sibling, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-25 4:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-25 4:24 ` Robert I. Eachus
@ 2004-01-25 16:24 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-25 16:24 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 15:43 ` Marin David Condic
2004-01-25 4:24 ` Robert I. Eachus
@ 2004-01-29 11:17 ` Jacob Sparre Andersen
2004-01-29 12:52 ` Marin David Condic
1 sibling, 1 reply; 85+ messages in thread
From: Jacob Sparre Andersen @ 2004-01-29 11:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-29 11:17 ` Jacob Sparre Andersen
@ 2004-01-29 12:52 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-29 12:52 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 5:23 ` Robert I. Eachus
2004-01-24 12:28 ` Marin David Condic
@ 2004-01-26 18:03 ` Warren W. Gay VE3WWG
2004-01-27 0:15 ` Robert I. Eachus
1 sibling, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-26 18:03 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 18:03 ` Warren W. Gay VE3WWG
@ 2004-01-27 0:15 ` Robert I. Eachus
2004-01-27 22:05 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-27 0:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-27 0:15 ` Robert I. Eachus
@ 2004-01-27 22:05 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-27 22:05 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 12:38 ` Marin David Condic
2004-01-24 5:23 ` Robert I. Eachus
@ 2004-01-24 8:17 ` Pascal Obry
2004-01-24 12:44 ` Marin David Condic
1 sibling, 1 reply; 85+ messages in thread
From: Pascal Obry @ 2004-01-24 8:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 8:17 ` Pascal Obry
@ 2004-01-24 12:44 ` Marin David Condic
2004-01-24 15:39 ` Robert I. Eachus
2004-01-26 11:28 ` Ole-Hjalmar Kristensen
0 siblings, 2 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 12:44 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 12:44 ` Marin David Condic
@ 2004-01-24 15:39 ` Robert I. Eachus
2004-01-24 16:06 ` Marin David Condic
2004-01-26 11:28 ` Ole-Hjalmar Kristensen
1 sibling, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-24 15:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 15:39 ` Robert I. Eachus
@ 2004-01-24 16:06 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 16:06 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 12:44 ` Marin David Condic
2004-01-24 15:39 ` Robert I. Eachus
@ 2004-01-26 11:28 ` Ole-Hjalmar Kristensen
2004-01-26 12:07 ` Marin David Condic
1 sibling, 1 reply; 85+ messages in thread
From: Ole-Hjalmar Kristensen @ 2004-01-26 11:28 UTC (permalink / raw)
>>>>> "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.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 11:28 ` Ole-Hjalmar Kristensen
@ 2004-01-26 12:07 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-26 12:07 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 2:47 ` Robert I. Eachus
2004-01-23 12:38 ` Marin David Condic
@ 2004-01-23 16:38 ` Alexandre E. Kopilovitch
2004-01-23 17:54 ` Jeffrey Carter
2004-01-23 17:24 ` Warren W. Gay VE3WWG
2 siblings, 1 reply; 85+ messages in thread
From: Alexandre E. Kopilovitch @ 2004-01-23 16:38 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 16:38 ` Alexandre E. Kopilovitch
@ 2004-01-23 17:54 ` Jeffrey Carter
0 siblings, 0 replies; 85+ messages in thread
From: Jeffrey Carter @ 2004-01-23 17:54 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 2:47 ` Robert I. Eachus
2004-01-23 12:38 ` Marin David Condic
2004-01-23 16:38 ` Alexandre E. Kopilovitch
@ 2004-01-23 17:24 ` Warren W. Gay VE3WWG
2004-01-23 22:30 ` Randy Brukardt
2 siblings, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-23 17:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 17:24 ` Warren W. Gay VE3WWG
@ 2004-01-23 22:30 ` Randy Brukardt
2004-01-26 22:11 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Randy Brukardt @ 2004-01-23 22:30 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 22:30 ` Randy Brukardt
@ 2004-01-26 22:11 ` Warren W. Gay VE3WWG
2004-01-27 0:28 ` Robert I. Eachus
2004-01-27 1:02 ` Jeffrey Carter
0 siblings, 2 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-26 22:11 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 22:11 ` Warren W. Gay VE3WWG
@ 2004-01-27 0:28 ` Robert I. Eachus
2004-01-27 22:13 ` Warren W. Gay VE3WWG
2004-01-27 1:02 ` Jeffrey Carter
1 sibling, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-27 0:28 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-27 0:28 ` Robert I. Eachus
@ 2004-01-27 22:13 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-27 22:13 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-26 22:11 ` Warren W. Gay VE3WWG
2004-01-27 0:28 ` Robert I. Eachus
@ 2004-01-27 1:02 ` Jeffrey Carter
1 sibling, 0 replies; 85+ messages in thread
From: Jeffrey Carter @ 2004-01-27 1:02 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 5:59 ` Randy Brukardt
2004-01-22 12:58 ` Marin David Condic
@ 2004-01-22 14:13 ` Robert A Duff
2004-01-22 17:27 ` Warren W. Gay VE3WWG
2004-01-23 12:52 ` Marin David Condic
1 sibling, 2 replies; 85+ messages in thread
From: Robert A Duff @ 2004-01-22 14:13 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 14:13 ` Robert A Duff
@ 2004-01-22 17:27 ` Warren W. Gay VE3WWG
2004-01-23 12:54 ` Marin David Condic
2004-01-23 12:52 ` Marin David Condic
1 sibling, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-22 17:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 17:27 ` Warren W. Gay VE3WWG
@ 2004-01-23 12:54 ` Marin David Condic
2004-01-23 17:26 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-23 12:54 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 12:54 ` Marin David Condic
@ 2004-01-23 17:26 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-23 17:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 14:13 ` Robert A Duff
2004-01-22 17:27 ` Warren W. Gay VE3WWG
@ 2004-01-23 12:52 ` Marin David Condic
2004-01-24 5:52 ` Robert I. Eachus
1 sibling, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-23 12:52 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 12:52 ` Marin David Condic
@ 2004-01-24 5:52 ` Robert I. Eachus
2004-01-24 12:56 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-24 5:52 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 5:52 ` Robert I. Eachus
@ 2004-01-24 12:56 ` Marin David Condic
2004-01-24 15:53 ` Robert I. Eachus
2004-01-30 17:34 ` Warren W. Gay VE3WWG
0 siblings, 2 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 12:56 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 12:56 ` Marin David Condic
@ 2004-01-24 15:53 ` Robert I. Eachus
2004-01-30 17:39 ` Warren W. Gay VE3WWG
2004-01-30 17:34 ` Warren W. Gay VE3WWG
1 sibling, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-24 15:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 15:53 ` Robert I. Eachus
@ 2004-01-30 17:39 ` Warren W. Gay VE3WWG
2004-01-31 1:58 ` Robert I. Eachus
0 siblings, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-30 17:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-30 17:39 ` Warren W. Gay VE3WWG
@ 2004-01-31 1:58 ` Robert I. Eachus
2004-02-02 17:55 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-31 1:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-31 1:58 ` Robert I. Eachus
@ 2004-02-02 17:55 ` Warren W. Gay VE3WWG
2004-02-04 18:36 ` Robert I. Eachus
0 siblings, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-02-02 17:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-02-02 17:55 ` Warren W. Gay VE3WWG
@ 2004-02-04 18:36 ` Robert I. Eachus
2004-02-06 17:27 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-02-04 18:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-02-04 18:36 ` Robert I. Eachus
@ 2004-02-06 17:27 ` Warren W. Gay VE3WWG
2004-02-07 13:18 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-02-06 17:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-02-06 17:27 ` Warren W. Gay VE3WWG
@ 2004-02-07 13:18 ` Marin David Condic
2004-02-09 17:37 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-02-07 13:18 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-02-07 13:18 ` Marin David Condic
@ 2004-02-09 17:37 ` Warren W. Gay VE3WWG
0 siblings, 0 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-02-09 17:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 12:56 ` Marin David Condic
2004-01-24 15:53 ` Robert I. Eachus
@ 2004-01-30 17:34 ` Warren W. Gay VE3WWG
1 sibling, 0 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-30 17:34 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 0:05 ` Robert I. Eachus
2004-01-22 5:59 ` Randy Brukardt
@ 2004-01-22 12:47 ` Marin David Condic
2004-01-22 13:24 ` Jean-Pierre Rosen
2004-01-22 17:29 ` Warren W. Gay VE3WWG
1 sibling, 2 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-22 12:47 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 12:47 ` Marin David Condic
@ 2004-01-22 13:24 ` Jean-Pierre Rosen
2004-01-22 18:20 ` Robert A Duff
2004-01-23 12:59 ` Marin David Condic
2004-01-22 17:29 ` Warren W. Gay VE3WWG
1 sibling, 2 replies; 85+ messages in thread
From: Jean-Pierre Rosen @ 2004-01-22 13:24 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 13:24 ` Jean-Pierre Rosen
@ 2004-01-22 18:20 ` Robert A Duff
2004-01-23 9:18 ` Jean-Pierre Rosen
2004-01-23 12:59 ` Marin David Condic
1 sibling, 1 reply; 85+ messages in thread
From: Robert A Duff @ 2004-01-22 18:20 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 18:20 ` Robert A Duff
@ 2004-01-23 9:18 ` Jean-Pierre Rosen
0 siblings, 0 replies; 85+ messages in thread
From: Jean-Pierre Rosen @ 2004-01-23 9:18 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 13:24 ` Jean-Pierre Rosen
2004-01-22 18:20 ` Robert A Duff
@ 2004-01-23 12:59 ` Marin David Condic
2004-01-23 14:21 ` Jean-Pierre Rosen
2004-01-24 6:02 ` Robert I. Eachus
1 sibling, 2 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-23 12:59 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 12:59 ` Marin David Condic
@ 2004-01-23 14:21 ` Jean-Pierre Rosen
2004-01-24 6:02 ` Robert I. Eachus
1 sibling, 0 replies; 85+ messages in thread
From: Jean-Pierre Rosen @ 2004-01-23 14:21 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-23 12:59 ` Marin David Condic
2004-01-23 14:21 ` Jean-Pierre Rosen
@ 2004-01-24 6:02 ` Robert I. Eachus
2004-01-24 13:09 ` Marin David Condic
1 sibling, 1 reply; 85+ messages in thread
From: Robert I. Eachus @ 2004-01-24 6:02 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 6:02 ` Robert I. Eachus
@ 2004-01-24 13:09 ` Marin David Condic
2004-01-24 19:32 ` tmoran
0 siblings, 1 reply; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 13:09 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 13:09 ` Marin David Condic
@ 2004-01-24 19:32 ` tmoran
2004-01-24 20:34 ` Marin David Condic
0 siblings, 1 reply; 85+ messages in thread
From: tmoran @ 2004-01-24 19:32 UTC (permalink / raw)
>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.
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-24 19:32 ` tmoran
@ 2004-01-24 20:34 ` Marin David Condic
0 siblings, 0 replies; 85+ messages in thread
From: Marin David Condic @ 2004-01-24 20:34 UTC (permalink / raw)
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
======================================================================
^ permalink raw reply [flat|nested] 85+ messages in thread
* Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)
2004-01-22 12:47 ` Marin David Condic
2004-01-22 13:24 ` Jean-Pierre Rosen
@ 2004-01-22 17:29 ` Warren W. Gay VE3WWG
1 sibling, 0 replies; 85+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-01-22 17:29 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 85+ messages in thread
end of thread, other threads:[~2004-02-09 17:37 UTC | newest]
Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-23 20:03 Standard Ada Preprocessor (Was: why ada is so unpopular ?) Leon Winslow
2004-01-24 2:00 ` Marin David Condic
-- strict thread matches above, loose matches on Subject: below --
2004-01-26 20:03 Lionel.DRAGHI
2004-01-26 23:10 ` Robert A Duff
2004-01-17 11:15 why ada is so unpopular ? Szymon Guz
2004-01-17 14:27 ` Dmytry Lavrov
2004-01-17 21:02 ` Szymon Guz
2004-01-17 22:36 ` Adrian Knoth
2004-01-18 9:21 ` Szymon Guz
2004-01-18 12:59 ` Ronald Dauster
2004-01-18 14:17 ` Szymon Guz
2004-01-18 14:42 ` Marin David Condic
2004-01-18 16:34 ` Preben Randhol
2004-01-19 12:59 ` Marin David Condic
2004-01-19 13:06 ` Preben Randhol
2004-01-19 13:28 ` Marin David Condic
2004-01-19 13:37 ` Preben Randhol
2004-01-20 12:38 ` Marin David Condic
2004-01-20 17:31 ` Standard Ada Preprocessor (Was: why ada is so unpopular ?) Warren W. Gay VE3WWG
2004-01-21 12:39 ` Marin David Condic
2004-01-22 0:05 ` Robert I. Eachus
2004-01-22 5:59 ` Randy Brukardt
2004-01-22 12:58 ` Marin David Condic
2004-01-22 17:25 ` Warren W. Gay VE3WWG
2004-01-23 12:24 ` Marin David Condic
2004-01-23 13:46 ` Dmitry A. Kazakov
2004-01-23 17:16 ` Warren W. Gay VE3WWG
2004-01-23 17:52 ` Jeffrey Carter
2004-01-23 21:57 ` Warren W. Gay VE3WWG
2004-01-24 0:52 ` Jeffrey Carter
2004-01-26 17:19 ` Warren W. Gay VE3WWG
2004-01-27 12:24 ` Marin David Condic
2004-01-24 1:34 ` Marin David Condic
2004-01-26 17:27 ` Warren W. Gay VE3WWG
2004-01-27 12:30 ` Marin David Condic
2004-01-24 8:20 ` Pascal Obry
2004-01-26 17:29 ` Warren W. Gay VE3WWG
2004-01-23 17:56 ` Larry Hazel
2004-01-24 1:36 ` Marin David Condic
2004-01-23 22:14 ` Randy Brukardt
2004-01-23 22:42 ` tmoran
2004-01-26 17:50 ` Warren W. Gay VE3WWG
2004-01-27 12:48 ` Marin David Condic
2004-01-26 9:34 ` Dmitry A. Kazakov
2004-01-26 19:23 ` Randy Brukardt
2004-01-23 2:47 ` Robert I. Eachus
2004-01-23 12:38 ` Marin David Condic
2004-01-24 5:23 ` Robert I. Eachus
2004-01-24 12:28 ` Marin David Condic
2004-01-24 15:32 ` Robert I. Eachus
2004-01-24 15:43 ` Marin David Condic
2004-01-25 4:24 ` Robert I. Eachus
2004-01-25 16:24 ` Marin David Condic
2004-01-29 11:17 ` Jacob Sparre Andersen
2004-01-29 12:52 ` Marin David Condic
2004-01-26 18:03 ` Warren W. Gay VE3WWG
2004-01-27 0:15 ` Robert I. Eachus
2004-01-27 22:05 ` Warren W. Gay VE3WWG
2004-01-24 8:17 ` Pascal Obry
2004-01-24 12:44 ` Marin David Condic
2004-01-24 15:39 ` Robert I. Eachus
2004-01-24 16:06 ` Marin David Condic
2004-01-26 11:28 ` Ole-Hjalmar Kristensen
2004-01-26 12:07 ` Marin David Condic
2004-01-23 16:38 ` Alexandre E. Kopilovitch
2004-01-23 17:54 ` Jeffrey Carter
2004-01-23 17:24 ` Warren W. Gay VE3WWG
2004-01-23 22:30 ` Randy Brukardt
2004-01-26 22:11 ` Warren W. Gay VE3WWG
2004-01-27 0:28 ` Robert I. Eachus
2004-01-27 22:13 ` Warren W. Gay VE3WWG
2004-01-27 1:02 ` Jeffrey Carter
2004-01-22 14:13 ` Robert A Duff
2004-01-22 17:27 ` Warren W. Gay VE3WWG
2004-01-23 12:54 ` Marin David Condic
2004-01-23 17:26 ` Warren W. Gay VE3WWG
2004-01-23 12:52 ` Marin David Condic
2004-01-24 5:52 ` Robert I. Eachus
2004-01-24 12:56 ` Marin David Condic
2004-01-24 15:53 ` Robert I. Eachus
2004-01-30 17:39 ` Warren W. Gay VE3WWG
2004-01-31 1:58 ` Robert I. Eachus
2004-02-02 17:55 ` Warren W. Gay VE3WWG
2004-02-04 18:36 ` Robert I. Eachus
2004-02-06 17:27 ` Warren W. Gay VE3WWG
2004-02-07 13:18 ` Marin David Condic
2004-02-09 17:37 ` Warren W. Gay VE3WWG
2004-01-30 17:34 ` Warren W. Gay VE3WWG
2004-01-22 12:47 ` Marin David Condic
2004-01-22 13:24 ` Jean-Pierre Rosen
2004-01-22 18:20 ` Robert A Duff
2004-01-23 9:18 ` Jean-Pierre Rosen
2004-01-23 12:59 ` Marin David Condic
2004-01-23 14:21 ` Jean-Pierre Rosen
2004-01-24 6:02 ` Robert I. Eachus
2004-01-24 13:09 ` Marin David Condic
2004-01-24 19:32 ` tmoran
2004-01-24 20:34 ` Marin David Condic
2004-01-22 17:29 ` Warren W. Gay VE3WWG
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox