why ada is so unpopular ?
Szymon Guz
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
Martin Dowie
news:bub5n8$kf5$1...@atlantis.news.tpi.pl...
> Hi,
> I'd like to know how ada is popular ? And i which countries. I'm asking
> because I live in Poland and here I couldn't find any firm that use it.
Check your local military suppliers. We certainly sell Ada-based products
to Poland.
Dmytry Lavrov
Szymon Guz
> 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++.
Adrian Knoth
>> 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: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
Kosmetik ist die Kunst aus der Not eine Jugend zu machen!
Marin David Condic
you the strengths and weaknesses of other languages & improves your
programming skills in general. Learning Ada might teach you a thing or
two about what is good/bad about something like C++ - whereas ignorance
of Ada and knowledge only of C++ (for example) tends to leave you blind
about how things might otherwise be done.
As for earning anything from the experience, you might consider this: If
you decide to write a *useful* program, there are ways that the program
may generate some money for you. Nobody will care much that it was
written in Ada or C++ or Java. Come up with a good idea and get a
baseline product built and see if you can find some users. Make money by
selling upgrades or by licensing the technology or any number of other
business models.
As for simple employment, while a company may be looking for a dozen
years of experience in Programming Language X - showing them on your
resume that you know a *variety* of languages tends to indicate that you
are a quick learner and adaptable as well as well educated. Any
experience cannot possibly hurt you.
Learning some Ada is an excellent way of discovering techniques and
capabilities you aren't likely to see duplicated in other languages.
Szymon Guz wrote:
>
> I see. But I'd like to know if it is worth learning. I'd like to write a
> program and maybe in future earn on that and I still don't know what to
> choose ada or C++.
>
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m o d c @ a m o g
c n i c . r
"Face it ladies, its not the dress that makes you look fat.
Its the FAT that makes you look fat."
-- Al Bundy
======================================================================
Hyman Rosen
> showing them on your resume that you know a *variety* of languages
> tends to indicate that you are a quick learner and adaptable as well
> as well educated. Any experience cannot possibly hurt you.
I interviewed a programming candidate for my compnay not long ago who
had C++ and Ada on his resume. I was looking forward to a nice chat on
comparing the two languages. Unfortunately, it turned out that the
candidate knew nothing about either one.
cl1
"Hyman Rosen" <hyr...@mail.com> wrote in message
news:WskOb.68$Wm4...@nwrdny01.gnilink.net...
Hyman Rosen
> and this is why it took me almost 2 years to find a job
You mean that you too put things on your resume that you
didn't know anything about?
cl1
god no! but there are so many people who do it's been like playing the
lottery to get my resume in front of companies to get an interview. I no
longer have this problem as of last friday. (yippie) i start my new job as
and ASP/VB developer on monday...
... i feel like such a whore. but at least i'm writing code :)
someday i hope to write really good stuff with ada on a linux platform as
soon as i can find someone to hire me. but i think it would help for me to
have more than a few months of learning experiance with ada before i attempt
that endevor.
Szymon Guz
> Szymon Guz <al...@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++.
Luke A. Guest
> well.. I know that, but my problem is a little bit different. I don't
> have money for sth like Builder or Kylix or Visual but I think that my
> program really needs to operate on some windows. I don't want to write
> that using WinApi nor Gtk; First of all the Gtk/Qt licence is not good
> for me and WinApi is terrible. I wanted to use wxWindows. It is written
> in C++, that's why I still don't know what to choose. Mix wxWindows(C++)
> with Ada or just use C++.
Hmm, I asked this on the wxWindows list the other day, the reply was that
the easiest way to do it would be to add an Ada backend to SWIG and use
the code from wxPython.
I can't be bothered as I haven't got the time.
Luke.
Ronald Dauster
>
> 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.
Ronald Dauster
Writing a language backend for SWIG is by no means trivial. In
addition, the SWIG mappings for different languages have very
different capabilities. That means, to get a clean Ada interface
the wxPython interface will need a lot of tweaking.
Stephane Richard
be equal or less work to port the whole library to Ada instead of attempting
to bind to it.
--
Stéphane Richard
"Ada World" Webmaster
http://www.adaworld.com
"Ronald Dauster" <r...@gido.remove_this_part.de> wrote in message
news:budvvf$9al$1...@online.de...
Szymon Guz
> 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 ?
Marin David Condic
You often have to divide everything by 10. Perhaps this is why companies
seem to be paying very little attention to them these days. I know when
my boss and I are discussing personnel, his push is always to find
someone that someone else in the organization can give a good
recommendation for or otherwise get them vetted by a reliable source.
Blind resumes may or may not tell you much about the candidate. Even if
the person didn't exagerate his skills too badly, it doesn't tell you
much about work habbits and interpersonal skills. I don't care how many
languages a guy has or how much experience he can show if he is
incapable of getting a job done on time or can't get along with his
co-workers & customers. You sometimes can't tell that until its too
late. ;-)
MDC
Hyman Rosen wrote:
> I interviewed a programming candidate for my compnay not long ago who
> had C++ and Ada on his resume. I was looking forward to a nice chat on
> comparing the two languages. Unfortunately, it turned out that the
> candidate knew nothing about either one.
Marin David Condic
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.
>
--
Szymon Guz
> My understanding of Gtk - at least in its Ada incarnation GtkAda - was
> that it is licensed such that an application that calls it is not
> subject to the GPL license. Should one modify the library itself, those
> changes would naturally be covered by the GPL, but to simply use it as a
> GUI interface would not require you to put your app under the GPL. Am I
> wrong about this?
>
> MDC
>
yea, you're right.. I've checked that and for suer it the LGPL licence:
"GTK+ is free software and part of the GNU Project. However, the
licensing terms for GTK+, the GNU LGPL, allow it to be used by all
developers, including those developing proprietary software, without any
license fees or royalties."
http://gtk.org/faq/#AEN81
Preben Randhol
> 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."
Jeffrey Carter
> yea, you're right.. I've checked that and for suer it the LGPL licence:
>
> "GTK+ is free software and part of the GNU Project. However, the
> licensing terms for GTK+, the GNU LGPL, allow it to be used by all
> developers, including those developing proprietary software, without any
> license fees or royalties."
> http://gtk.org/faq/#AEN81
GtkAda, the Ada binding to GTK+, is under the GNAT-Modified GPL (GMGPL),
so Ada programs using GTK through GtkAda can be proprietary if the
developer desires.
--
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72
Jano
> Hi,
> I'd like to know how ada is popular ? And i which countries. I'm asking
> because I live in Poland and here I couldn't find any firm that use it.
It's the language of choice to teach several subjects in Zaragoza
(Spain) college, computer engineering. I couldn't say about other
colleges in Spain.
Introduction to programming.
Data structures and algorithms.
Concurrent programming.
Real time programming.
Embedded systems.
I may be missing something.
Marin David Condic
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.
>
>
--
Preben Randhol
> 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.
Jeff C,
"Marin David Condic" <nob...@noplace.com> wrote in message
news:400BD4B5...@noplace.com...
> I don't know about the Gtk license itself or why GtkAda would have to
> modify it slightly to enable the writing of proprietary software. What I
> gathered by looking at the GtkAda license at least was that one could
> develop an entirely proprietary app that made the Gtk calls through the
> GtkAda binding. If one was doing a Gtk based interface, GtkAda seems
> like the only logical choice (unless one needs Gtk capabilities that
> aren't supported in GtkAda - a problem that all such bindings have and
> an argument as to why Ada ought to have its own GUI.)
>
> It seems the best choice for a semi-portable interface if that is the
> requirement. GPL "infection" does not seem to be an issue AFAICS.
>
> MDC
>
> Preben Randhol wrote:
> >
> > This package is distributed under the GPL license, slightly modified so
> > that you can create proprietary software with this toolkit. The license
> > is actually the same as the GNAT library itself. You should also read
> > the Gtk license itself if you intend to do proprietary software based on
> > gtk and GtkAda.
> >
> >
>
The "read the license part" is just a warning that this software (like
almost
all software) is covered by A license so make sure you understand the
terms before development.
The reason that the GNAT libraries and GtkAda use a modified GPL instead
of an LGPL is that it is difficult (if not impossible) to comply with the
terms of
the LGPL in Ada (and in many cases C++) with proprietary distribution.
WARNING. NON LAWYER APPROXIMATION OF TRUTH TO FOLLOW
The LGPL requires that you distribute source with your execuables or that
you
distribute your execuables in such a way that the components that are LGPL
can
be updated by the end users (e.g. dynamically link to the LGPL library or
provide .o files for all the proprietary stuff)..This woulld in theory allow
an end user
to fix a bug in the LGPL component (or get a bug fix link library) and
"update"
the program.
The problem in Ada (and actually in other languages) is that there are
pieces of
code that at hard to do this with. If you have and LGPL generic it is
essentially impossible
with GNAT to have that be an LGPL component since the generic expantion
happens
at compile time. Something like this is also true of C++ and to some exent C
header
files.
So the GMGPL is actually a slightly lesser (in RMS speak) language than the
LGPL (meaning
that it does not require the "field upgrade" capability of the LGPL.
Marin David Condic
>
> 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 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
Preben Randhol
> _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.
Robert I. Eachus
> So the GMGPL is actually a slightly lesser (in RMS speak) language than the
> LGPL (meaning that it does not require the "field upgrade" capability of the LGPL.
I am not picking on Jeff, who does a good job of describing why GTK+
uses LGPL and GtkAda uses GMGPL. I just want to say that the consensus
is that GtkAda can be used without any "Gnu contamination" of your
application. You can release such a program as proprietary or if you
prefer copylefted or into the public domain. All you really need to
know is that the respective developers got their licensing right so that
you don't need to worry.
As to GtkAda, it seems to be the consensus Ada graphics library right
now. It would be nice if someone would update it, but probably the best
way to describe the situation is that it is much better than "good
enough" so no one currently seems to feel a need to do better.
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
chris
I've tried Gtkmm and GtkAda. Gtkmm was easier to use to begin with, but
I ran into a problem with the model I was building because I didn't
understand C++ too well (templates specifically). In Ada it was easier
to build the model because I know the language fairly well, but the view
in GtkAda was a little more difficult (or in the way... don't like
generically instantiated handlers).
It's a trade off. I went for Ada, but only because C++ got on my nerves
and I found the Oz documentation too academic... there are enough
academics messing with my brain at the minute. ;)
Personally I'd try both and see what fits... no wait! I did ;)
Chris
cl1
"Robert I. Eachus" <riea...@comcast.net> wrote in message
news:_NedndNu6J_...@comcast.com...
> Jeff C, wrote:
>
> > So the GMGPL is actually a slightly lesser (in RMS speak) language than
the
> > LGPL (meaning that it does not require the "field upgrade" capability of
the LGPL.
>
> I am not picking on Jeff, who does a good job of describing why GTK+
> uses LGPL and GtkAda uses GMGPL. I just want to say that the consensus
> is that GtkAda can be used without any "Gnu contamination" of your
> application. You can release such a program as proprietary or if you
> prefer copylefted or into the public domain. All you really need to
> know is that the respective developers got their licensing right so that
> you don't need to worry.
>
> As to GtkAda, it seems to be the consensus Ada graphics library right
> now. It would be nice if someone would update it, but probably the best
> way to describe the situation is that it is much better than "good
> enough" so no one currently seems to feel a need to do better.
Last i checked gtkada was current with gtk+
http://libre.act-europe.fr/GtkAda/
and it also has some stuff that gtk+ doesn't have(not that i have used that
stuff)
Robert I. Eachus
> Last i checked gtkada was current with gtk+
> http://libre.act-europe.fr/GtkAda/
> and it also has some stuff that gtk+ doesn't have(not that i have used that
> stuff)
Shrug. I would like it if GtkAda had a more Ada-like binding. But as I
said it is more than good enough so other things are higher on my
priority list.
Preben Randhol
>
> Shrug. I would like it if GtkAda had a more Ada-like binding. But as I
> said it is more than good enough so other things are higher on my
> priority list.
Please descibe what you mean.
Marin David Condic
Preben Randhol wrote:
>
> Well, who would be in charge of an Ada GUI and develop it actively and
> not every 10-15 years ?
>
Who's in charge of Java's GUI? Do they update it only every 10 to 15
years? Why is it that Java can do it but Ada can't? (Besides lack of
will.) Here's the point: Java can find a way to react quickly to a
changing world and provide developers with tools to help them do their
jobs with greater speed. Ada can't because of lack of will to do so. Who
wins? (Hint: the answer is Java. ;-)
>
> Sure, but there are other things that the GUI to show that. My problem
> is that there are X GUIs and Y OSes out there already.
>
How did Java manage to get a GUI that seems to be useful across a number
of platforms? How did it succeed in something that looks so hopeless?
Realistically, a GUI needs to support Windows and X-Windows (across a
few different flavors of Unix) and it can cover 90% of the market. The
rest? You say "Here is the GUI library in source - go make it work for
yourself if you have to use something off-the-wall..."
Ada has this "Portability Fetish" that often cripples it. "If we can't
make a feature work on everything from a PC to a digital toaster then it
can't be part of the language!" We solve that with some kind of library
external to the standard that exists in source and works on some stated
number of platforms and where it doesn't work - don't try to use it. The
problem, of course, is to get the vendors to actually think that Ada
*needs* something like this and exhibit the will & leadership to get it.
>
> Well if you look at the timespan for developing Gtk you'll see it isn't
> a trivial task. Making a binding is, however, much more trivial.
>
I never said a GUI was a trivial task. What I said was that the C
programmers are always going to get it *first* and its going to look the
way *C programmers* want it to look. The Ada programmers will always get
it later and will have to struggle with the usual C metaphors. As long
as Ada depends on bindings for this sort of thing, Ada programmers are
sucking hind tit. Developers ask themselves "Do I want to suck hind
tit?" Generally the answer is "No!" and they go develop in C/C++ or
Java. So long as Ada is in that ugly position, developers will stay away
from it in droves. They'll go where they can get the most bang for the
buck - and for the most part, that's not Ada.
>
> Yes I agree. But I want a container library +++ first.
>
I have absolutely no objection to a container library. However, we
barely see any real will to get even *that* as a standard with the
vendors lacking the leadership to get in front of the problem and say
"Here's the answer that everyone should start to agree on..." I suppose
if they want to lose the compiler-wars, that's up to them.
Realistically, developers can look at Java and (to some extent) C++ and
see that they are getting a whole lot more leverage by way of a library
than they do with Ada.
Your average uncommitted developer is going to see all that leverage and
ask "So why is it I should go with some obscure, niche programming
language that offers me less in the way of tools and I have to struggle
by being incompatible with the whole rest of the universe? What do I get
for this? An unquantified cost savings in maintenance ten years down the
line and a few less bugs? My software doesn't live that long and I can
tolerate a few bugs and what I gain in development leverage will easily
outweigh the cost of fixing the bugs if I really need to." Its basically
a no-brainer that is consistently demonstrated over and over again by
the fact that developers are using languages other than Ada.
The question is simple: "Do you want Ada to be around in ten years with
a healthy, large user base?" If you'll settle for Ada being some niche
language used in a few antique projects (like Jovial?) then it certainly
can have that much strength. But if you want Ada to be a "Player" in the
language market, then Ada had better start finding a way to offer *more*
leverage to the developer than does its competitors.
Robert I. Eachus
> On 2004-01-20, Robert I. Eachus <riea...@comcast.net> wrote:
>
>>Shrug. I would like it if GtkAda had a more Ada-like binding. But as I
>>said it is more than good enough so other things are higher on my
>>priority list.
>
>
> Please descibe what you mean.
Exactly what I said. There are some areas where, when I use GtkAda, I
think "It might be nice if..." Then when I think about it a bit more, I
realize what a major undertaking it would take compared to the very
minor benefit, and forget about it. I'd mention specific cases, but as
I said, I can't even think of any that were worth remembering. ;-)
Just in case anyone thinks I am 'damning with faint praise', there is a
very good reason that GtkAda is currently the most used Ada graphics
interface, and that is that it is by far the best. There are lots of
other things where an investment of my time may make a difference,
excuse me if I get back to them.
Incidently when Ada0Y is finalized and compilers comform to it, I
suspect that changing GtkAda to use interfaces and constructors in some
areas will be well worth the effort. But that is probably a project for
next year, or the year after.
Warren W. Gay VE3WWG
> 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
Georg Bauhaus
: Portability of course is an important issue. This becomes even more
: important to Open Sourced projects, since they must be easy to
: compile and maintain for all/most flavours of UNIX, and different
: Windows environments (native and/or CYGWIN etc.)
"native and/or CYGWIN" is a distinction that IMO amounts to saying
"not portable and/or portable", at least for your average C command
line tool or X11 program. How would you compile a Unix program
not using one of the Unix libraries/services provided with or for
Windows?
No preprocessor can help here, unless it magically provides
a mapping from a cooperating sequence of API calls found in the
Unix world to a cooperating sequence of APIs calls found
in the Windows world.
Or are you saying that Ada code shoud use #ifs all over the place,
neglecting language features? IMHO, a program is portable if it
uses *abstraction*, for example a good separation a la MVC.
Abstraction is more easily expressed in a Ada than in CYGWIN's
perceived "standard" language, I think. A program is
not portable in this sense if it is a Unix command line tool and
happens to run on top of a Unix layer, or if it is an X11 program
and runs in the presence of an X server that has been ported to
Windows.
: Failing that, everyone must bake their own solution to this
: problem. Many maintain that by centralizing problem code into
: separate libraries works well enough. But this does not help
: in the cases where a product can be compiled with different
: options turned on or not (say from a Makefile).
How could #ifs or text substitutions make any difference?
If the maintenance has to happen in my head so to speak, that is
if I have to know which #if surround what specialisation, I'd
rather stay with my language and use what is provided for
expressing a difference in a type's components say. Example
struct _gna {
int x;
int y;
#if defined(__S1__)
int z;
#else
short z;
#endif
} *S;
I don't see the advantage, even if the distinction appears
"centralised" (?).
: In other cases,
: it may mean enhancements involve maintenance of several parallel
: modules, instead of one centralized location.
Why not use language means to check modules for compliance
with the common requirements?
"display help on topic_abc_123 in a dialogue window" could well be
mapped to an abstract operation.
-- Georg
Stephen Leake
> On 2004-01-20, Robert I. Eachus <riea...@comcast.net> wrote:
> >
> > Shrug. I would like it if GtkAda had a more Ada-like binding. But as I
> > said it is more than good enough so other things are higher on my
> > priority list.
>
> Please descibe what you mean.
I'll jump in here :)
GtkAda currently follows Gtk+ in using strings to name events; the Ada
way would be to use enumerals, named constants, or function names.
GtkAda also allows the user to easily bind an incorrect handler to an
event ("incorrect" here meaning "has the wrong parameter/result
profile"). The error is reported at run-time, but the Ada way is to
catch this error at compile time.
In my GtkAda projects, I'm attempting to fix both issues, by providing
child packages for the current GtkAda packages that present the "Ada
way". If it works out, I'll propose it as a change to be incorporated
(some things would benefit from being primitive operations, which must
be in the same package as the type).
--
-- Stephe
Luke A. Guest
> Hi,
> I'd like to know how ada is popular ? And i which countries. I'm asking
> because I live in Poland and here I couldn't find any firm that use it.
Well, I wouldn't say that Ada is unpopular. There are other factors to
take into consideration:
1) Management don't know about Ada.
2) Management tend to want the programmers to use languages that are the
current fad, i.e. C/C++.
3) I had to learn Ada at uni and I had no idea about before then. I
actually love the language, It has so many features not found anywhere
else that are (IMO) necessary for development.
4) Programmers learn what is required of them.
5) The DoD (supposedly) dropped all support for Ada and this then looks
(to the outsider) that the language is dead.
I think that if enough programmers get to know Ada, I think that better
programming standards will emerge, but it's up to those who know it
and those who can tell others about it to spread the word and make sure
that others start to use it.
Luke.
Preben Randhol
> GtkAda also allows the user to easily bind an incorrect handler to an
> event ("incorrect" here meaning "has the wrong parameter/result
> profile"). The error is reported at run-time, but the Ada way is to
> catch this error at compile time.
How do you bind your handles? If I remember correctly there are two
ways, the C way and the Ada way already. At least I use marshals which
will make the compiler catch errors at compile time.
Can you give a source example?
amado.alves
I'll step in, too.
Ada has ways of getting the name of 'enumerals' (is that the proper term?) and exceptions as strings, so no problem here. For functions there are compiler-dependent ways (e.g. GNAT's symbolic traceback). And for everything there is ASIS: as the idea is to move in the direction of compile-time, it fits.
Marin David Condic
between Java and Ada with respect to reference implementation versus
standards. The point is that if Java can manage to have a library and a
GUI that is at least mostly portable (via reference implementation) then
why can't Ada? Its proven to be a popular route and one that can be
handled well enough to keep the user community happy. It adds leverage
to development and makes Java a good choice for lots of apps. Is Ada
going to sit around and say "Sure it could be useful to you but I won't
do it because it violates some intellectual purism I have in mind..."?
That just makes language choice really simple: use Java. ;-)
MDC
Dennis Lee Bieber wrote:
>
> Most likely, SUN. Java is, essentially, owned by one company.
> THEY define it, and they release the reference implementation. What Sun
> releases, in effect, defines the "standard".
>
> Ada, OTOH, is not defined by implementations -- the converse in
> fact. The formal standard document defines the language, implementations
> are expected to conform to that standard. When Ada was first defined,
> one of the requirements of the language was that there be no supersets
> or subsets of the language. Any differences from the standard meant that
> the result language could NOT be called Ada -- in those days, if anyone
> could be said to own Ada, it was the US DoD <G>.
>
> The other item is that Java's GUI is defined at a high-level,
> and relies on low-level /OS specific/ code in the JVM. There is no such
> beast in Ada. Any graphical library would have to be built in versions
> for each OS.
>
> --
> > ============================================================== <
> > wlf...@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> > wulf...@dm.net | Bestiaria Support Staff <
> > ============================================================== <
> > Home Page: <http://www.dm.net/~wulfraed/> <
> > Overflow Page: <http://wlfraed.home.netcom.com/> <
Marin David Condic
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
--
Georg Bauhaus
: that will compile on one but not on the other.
But then this is not an issue of program portability, but of
compiler differences or compiler bugs. To some extent Source Code Versioning
software and branches can help.
: Isolation with separate
: bodies is sometimes difficult to do and always complicates the build
: process. Some form of conditional compilation would make the job easier.
I'd prefer a conditional build process. IMHO, there should be a
declarative language for build processes, integrated with one
or more "source languages". ACE files (Eiffel), Project files (Ada),
VCS integration/awareness etc.
: Naturally that has risks and can lead to all sorts of abuse.
If you keep the #ifs out of the code, and instead declare the
target/compiler dependences in documents of their own right,
to be processed by a configuration preprocessor, that risk isn't
there, I think.
-- Georg
Hyman Rosen
> 2) Management tend to want the programmers to use
> languages that are the current fad, i.e. C/C++.
And they all communicate in that fad language English
instead of using NewSpeak. Despite the fact that in
NewSpeak your sentences are clear and unambiguous,
people are still required to use languages which fail
to accurately deliver to the listener the intent of
the speaker. Remember, "You can't put too much water
into a nuclear reactor!"
Ludovic Brenta
> On Sat, 17 Jan 2004 12:15:35 +0100, Szymon Guz wrote:
>
> > Hi,
> > I'd like to know how ada is popular ? And i which countries. I'm asking
> > because I live in Poland and here I couldn't find any firm that use it.
>
> Well, I wouldn't say that Ada is unpopular. There are other factors to
> take into consideration:
>
> 1) Management don't know about Ada.
> 2) Management tend to want the programmers to use languages that are the
> current fad, i.e. C/C++.
In my view their attitude is more cynical than that. The reason why
they want programmers to use "mainstream" languages is so they can
replace programmers easily without retraining. They want programmers
to be disposable and interchangeable just like a piece of commodity
hardware. They don't mind that their language of choice has an
adverse effect on the quality of software, because they're interested
in selling bug fixes, upgrades and maintenance. They also don't mind
that disposable programmers will produce disposable software. They're
in fact quite happy about it.
I don't like to sound so pessimistic, but I've actually gotten a
manager to admit openly to all of the above. Now that was at a very
large company that makes enterprise data storage products. I was not
a nuclear, aerospace, or rail company. I hope there are still
companies that try to produce quality software.
> 3) I had to learn Ada at uni and I had no idea about before then. I
> actually love the language, It has so many features not found anywhere
> else that are (IMO) necessary for development.
Yes. Furthermore, I have found that people who learn Ada often change
their attitude regarding software development. They no longer want to
develop junk, disposable software; instead they want to develop
quality software that lasts.
(yes, there are many people who actually like developing disposable
software; those are the ones who promote and improve on scripting
languages like Perl or Python to a point where they change from being
prototyping languages to being implementation languages).
> 4) Programmers learn what is required of them.
> 5) The DoD (supposedly) dropped all support for Ada and this then looks
> (to the outsider) that the language is dead.
>
> I think that if enough programmers get to know Ada, I think that better
> programming standards will emerge, but it's up to those who know it
> and those who can tell others about it to spread the word and make sure
> that others start to use it.
>
> Luke.
I would like to see more free software developed in Ada. The free
software world does not try to produce disposable software, and
therefore would benefit from a language that helps improve quality.
Perhaps, that way, Ada will become a little bit more mainstream.
--
Ludovic Brenta.
Hyman Rosen
> I've actually gotten a manager to admit openly to all of the above.
I'll bet he was just tired of your badgering him about Ada,
and told you that to get you to go away and leave him alone.
I do that with my three-year old sometimes too.
chris
>
> Well, I wouldn't say that Ada is unpopular. There are other factors to
> take into consideration:
>
> 1) Management don't know about Ada.
If they knew, would they care? In the desktop, I don't think so.
Ludovic is right in the disposability of programmers. Especially today.
Do you know how many software developers are out in just the UK there
looking for jobs (like me)? Loads! The more experienced SEs might even
have to take a pay drop (in terms of what they're worth) just to get a
job. There is not as much money as there used to be out there and
people aren't going to take risks moving over to other technologies if
the technologies they have do the job and there's a steady stream of
programmers conversant in those technologies available. Unis teach
graduates the hot technology and the cycle repeats!
> 2) Management tend to want the programmers to use languages that are the
> current fad, i.e. C/C++.
> 3) I had to learn Ada at uni and I had no idea about before then. I
> actually love the language, It has so many features not found anywhere
> else that are (IMO) necessary for development.
I used to think so, but have found similar features in other languages
expressed more powerfully and also with the benefit of run time
portability and lots of tools targetting the desktop developer. Ocaml
for instance library support on the desktop exceeds Ada's with the
exception of GUI toolkits (there are only a couple of these), despite
being a functionally imperative language from the research community (or
maybe it doesn't, but appears so since there is a central repository
full of current links & sw).
I think the perception from uni is that Ada is a good language, but why
spend time making data structure libraries or downloading them when C++,
C#, Delphi (iirc) and Java have them out of the box. Data structures
will be remedied but what about XML? It has no place in the standard
but what if compilers came with an XML parser, a gui toolkit and
whatever else need be. Note it doesn't take ACT (specifically) to do
this. Someone could package it up for people and let them download it.
Some Ada compiler companies might do this already but are they expensive?
> I think that if enough programmers get to know Ada, I think that better
> programming standards will emerge, but it's up to those who know it
> and those who can tell others about it to spread the word and make sure
> that others start to use it.
It's a nice language yes, but it's one of *many* such languages.
Chris
Robert A Duff
> I'll bet he was just tired of your badgering him about Ada,
> and told you that to get you to go away and leave him alone.
> I do that with my three-year old sometimes too.
I'm glad to know your three-year-old badgers you about Ada. ;-)
Good taste.
- Bob
Robert I. Eachus
> 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. ;-)
Randy Brukardt
news:LNOdncWFbKU...@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.
Marin David Condic
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
--
Marin David Condic
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
expensive and risky to use *anything* outside of the mainstream.
Hardware is a good example. Would you rather support a current version
of an IBM PC or an old DEC Alpha/VMS system? The old system is *really*
costly to maintain because nobody is mass producing parts for it and not
as many programmers know how to use it, etc. All that adds cost to a
project. The technical superiority of an Alpha over a PC is irrelevant.
You'd be building your system on top of an antique and the first
breakdown you have is going to kill you.
As for "disposable" programmers - would you be willing to sign a
long-term contract promising never to leave the company you are at?
Probably not. Hence a manager needs to consider the possibility that you
might quit and what does he do in that case? He would have to hire and
train someone else - costly and time consuming. So using a language that
is widely known and platforms that are widely used, he minimizes risks
and costs. That's what managers are *supposed* to do.
Rather than complain about "stupid management" we ought to be helping
them solve their problems. If Ada had much more capability and
widespread use, then the manager has substantially less risk in going
that route. Give the poor guy something he can *trust* will be around,
supported, low cost and high leverage and you may discover he starts
making decisions more to your liking.
MDC
chris wrote:
>
> If they knew, would they care? In the desktop, I don't think so.
> Ludovic is right in the disposability of programmers. Especially today.
>
--
Georg Bauhaus
: E:\Ada\Test>system_names
: system_names
: The Available System Names are: SYSTEM_NAME_GNAT.
:
: Current System.System_Name is: SYSTEM_NAME_GNAT.
:
: Is there any compiler that produces a useful output?
ObjectAda:
The Available System Names are: S370, I80X86, I80386, MC680X0,
VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300,
SPARC.
Current System.System_Name is: I80386.
Marin David Condic
that will compile on both a Gnat and an Aonix platform.
MDC
Georg Bauhaus wrote:
>
> ObjectAda:
> The Available System Names are: S370, I80X86, I80386, MC680X0,
> VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300,
> SPARC.
>
> Current System.System_Name is: I80386.
>
Jean-Pierre Rosen
"Marin David Condic" <nob...@noplace.com> a écrit dans le message de news:400FC65B...@noplace.com...
> 1) With it being an enumeral, unless *ALL* implementations use the same
> ones, I have code that won't compile, right?
If Name'Image (System_Name) = "Whatever" then ....
--
---------------------------------------------------------
J-P. Rosen (ro...@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
Dmitry A. Kazakov
<sb4...@l1-hrz.uni-duisburg.de> wrote:
>Robert I. Eachus <riea...@comcast.net> wrote:
>
>: E:\Ada\Test>system_names
>: system_names
>: The Available System Names are: SYSTEM_NAME_GNAT.
>:
>: Current System.System_Name is: SYSTEM_NAME_GNAT.
>:
>: Is there any compiler that produces a useful output?
>
>ObjectAda:
> The Available System Names are: S370, I80X86, I80386, MC680X0,
>VAX, TRANSPUTER,
Should that mean they have a compiler for Inmos T805? I am impressed!
> RS_6000, MIPS, HP9000_PA_RISC, HP9000_300, SPARC.
>
> Current System.System_Name is: I80386.
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
Robert A Duff
> "Robert I. Eachus" <riea...@comcast.net> wrote in message
> news:LNOdncWFbKU...@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
Georg Bauhaus
What kind of difficulties do you see that could be better solved
by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
versa? Dependence on pragmata?)
I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p.
Ada source text is chopped where necessary using make.
(Operating) System specific routines are are assembled into a
package hierarchy (which I naively had top-level-named "System" (and
that triggers a bug box in GCC 34 after looping (the maintainers
say that, obviously, a library unit should not be modified...)))
Then a branch renames package Systems.Windows, another renames
package Systems.UNIX (or similarly).
The problem that leads GNAT 3.15p to reject another unit is
apparently a bug in GNAT 3.15p that has been fixed in GCC 34.
I like this better than having to construct sources around a
compiler bug/limitation using hopefully temporary preprocessor #ifs.
-- Georg
Warren W. Gay VE3WWG
> 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
> "Randy Brukardt" <ra...@rrsoftware.com> writes:
>>"Robert I. Eachus" <riea...@comcast.net> wrote in message
>>news:LNOdncWFbKU...@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
> 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
> Marin David Condic <nob...@noplace.com> wrote:
> : Better than Gnat, but still not terribly useful if you want to make code
> : that will compile on both a Gnat and an Aonix platform.
>
> What kind of difficulties do you see that could be better solved
> by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
> versa? Dependence on pragmata?)
MDC pointed out that you cannot conditionally do "with"
as one example. Implementation defined pragmas are
another area of difficulty. Optional features are
a pain to deal with since there is no way to feed
values into a compile process (using make),
without creating make "steps" that process the
source code before hand (ie. this becomes a manual
preprocessing step).
Robert A Duff
> "Marin David Condic" <nob...@noplace.com> a écrit dans le message de news:400FC65B...@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
Georg Bauhaus
: MDC pointed out that you cannot conditionally do "with"
: as one example.
Withing or not cannot be an option unless another possibly
related conditional requires a unit or not.
If there is no other conditional text, renaming an empty
package will do.
: Implementation defined pragmas are
: another area of difficulty. Optional features are
: a pain to deal with since there is no way to feed
: values into a compile process (using make),
: without creating make "steps" that process the
: source code before hand (ie. this becomes a manual
: preprocessing step).
So what is the greater pain?
To me, placing conditionals near the conditional sections is
tempting, but usually leads to #ifs all over the place. It is
like writing tasking constructs without language support, or
like wrting your own dispatcher. If we had a way to declare for
any of the 2**N compilations which conditions are to be met, and
which parts of the program text have to be in place for one of the
compilations, configuration could be done in a systematic manner,
with the help of a computer program that does configuration checking,
and with a readable statement (declarative in style) of the programs
dependences.
-- Georg
Stephen Leake
> Rather than complain about "stupid management" we ought to be helping
> them solve their problems. If Ada had much more capability and
> widespread use, then the manager has substantially less risk in going
> that route. Give the poor guy something he can *trust* will be around,
> supported, low cost and high leverage and you may discover he starts
> making decisions more to your liking.
In my field, the time it takes to learn Ada is quite small compared to
the time it takes to learn how to write useful programs. The later
involves data structures, real-time scheduling, the physics of
actuators and sensors, and control algorithms. None of those things
are "main stream" :).
And yet the managers still say "we can't teach people new programming
languages".
--
-- Stephe
Robert I. Eachus
> 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.
Jean-Pierre Rosen
"Robert A Duff" <bob...@shell01.TheWorld.com> a écrit dans le message de news:wccd69b...@shell01.TheWorld.com...
Sigh, even in this case, everything posted should be tried on a compiler :-)
Marin David Condic
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
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
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
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
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" <nob...@noplace.com> a écrit dans le message de news:400FC65B...@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
Dependency" package and swap those out easily, that you have *an* answer
to some (if not all) problems. I've done this thousands of times. I've
described cases elsewhere in this thread that *must* be dealt with at
compile time (either by having separate configuration dependent units
and some kind of conditional build tools or by having conditional
compilation.) I'll bet you've even encountered things like a given
declaration that works fine on one compiler but doesn't work on another
or a statement that is legal and compiles for one compiler but is
illegal for another. There are all sorts of allowed compiler differences
- without even bringing up the subject of trying to get around compiler
bugs.
So if there's issues that have to be resolved at compile time and I
can't guarantee that there is some external configuration management
and/or build tools available to make maintaining separate units possible
(if not always desirable) then I want some kind of conditional
compilation to help me maintain a single body of code that works for
more than one configuration.
MDC
Georg Bauhaus wrote:
> What kind of difficulties do you see that could be better solved
> by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
> versa? Dependence on pragmata?)
>
> I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p.
> Ada source text is chopped where necessary using make.
> (Operating) System specific routines are are assembled into a
> package hierarchy (which I naively had top-level-named "System" (and
> that triggers a bug box in GCC 34 after looping (the maintainers
> say that, obviously, a library unit should not be modified...)))
> Then a branch renames package Systems.Windows, another renames
> package Systems.UNIX (or similarly).
>
> The problem that leads GNAT 3.15p to reject another unit is
> apparently a bug in GNAT 3.15p that has been fixed in GCC 34.
> I like this better than having to construct sources around a
> compiler bug/limitation using hopefully temporary preprocessor #ifs.
>
--
Marin David Condic
domains, it takes you more time to learn the domain than to learn the
language. Managers love to hire guys who already have experience in the
domain for exactly that reason.
But that doesn't really address the issue that a manager has when
choosing a language. Training people is *part* of the cost, but by no
means all of it. If you're building things using sensors and actuators
and control algorithms like I am, then you're probably talking about
very long-lived systems that are extremely expensive to verify.
Especially in some environment like that, a manager doesn't want to be
sitting on top of a dead-end language. If it becomes mostly non-existant
in ten years and his control has to live for another 30 years, he is
most eggregiously sexually penetrated when he has to switch to something
else in mid-project.
I'll reiterate: Give the poor manager something he can have some
confidence in and believe it will solve his problems and maybe he'll
start making the decisions you want him to make. He lives or dies by
things like cost, schedule, time-to-market, risk reduction, etc.
Selecting some niche language with an uncertain future, a lack of
industry support, a poverty of tools/libraries (compared to other
choices) and a profound disinterest on the part of most of the available
programmers out there just doesn't look like a career-enhancing move.
Fix that and maybe he'll show more interest in the language.
MDC
Stephen Leake wrote:
>
> In my field, the time it takes to learn Ada is quite small compared to
> the time it takes to learn how to write useful programs. The later
> involves data structures, real-time scheduling, the physics of
> actuators and sensors, and control algorithms. None of those things
> are "main stream" :).
>
> And yet the managers still say "we can't teach people new programming
> languages".
>
--
Dmitry A. Kazakov
<nob...@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.
Jean-Pierre Rosen
"Marin David Condic" <nob...@noplace.com> a écrit dans le message de news:40111AC2...@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.)
> 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.
Alexandre E. Kopilovitch
> ... 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 a...@vib.usr.pu.ru
Saint-Petersburg
Russia
Warren W. Gay VE3WWG
> On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic
> <nob...@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
...
>>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
> 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
> 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
> Warren W. Gay VE3WWG <war...@ve3wwg.tk> wrote:
> : MDC pointed out that you cannot conditionally do "with"
> : as one example.
>
> Withing or not cannot be an option unless another possibly
> related conditional requires a unit or not.
> If there is no other conditional text, renaming an empty
> package will do.
Perhaps I don't understand your point here, but if I
supply a parameter on the command line to the compiler
that says I am compiling with GNAT (or PDcurses or
whatever), then I can at compile time choose what
packages I am going to "need". I don't find any
reason to see prevent a conditional compile condition
here.
> : Implementation defined pragmas are
> : another area of difficulty. Optional features are
> : a pain to deal with since there is no way to feed
> : values into a compile process (using make),
> : without creating make "steps" that process the
> : source code before hand (ie. this becomes a manual
> : preprocessing step).
>
> So what is the greater pain?
> To me, placing conditionals near the conditional sections is
> tempting, but usually leads to #ifs all over the place.
If you have #ifs all over the place, it is because you
need them ;-) Granted much of this abuse on the C/C++
side is related to how C/C++ works in the first place.
So drawing parallels to C should be done carefully.
There is still a strong need for conditional compilation.
Not for embedded work, since you have very specific
targets for that code. But if Ada is to support the
general purpose computing environment, and to support
portability, it must have better facilities for the
portability issues that come up.
> It is
> like writing tasking constructs without language support, or
> like wrting your own dispatcher. If we had a way to declare for
> any of the 2**N compilations which conditions are to be met, and
> which parts of the program text have to be in place for one of the
> compilations, configuration could be done in a systematic manner,
> with the help of a computer program that does configuration checking,
> and with a readable statement (declarative in style) of the programs
> dependences.
Tell me, how do you solve the situation where API call to your
OS requires 3 parameters on one platform, and 2 on another? No
if statement can solve that for you.
Jeffrey Carter
>
> 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
Jeffrey Carter
>... 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.
Larry Hazel
> 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.
Leon Winslow
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Warren W. Gay VE3WWG
> 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 ;-)
Randy Brukardt
news:QEcQb.20015$cQ6.8...@news20.bellglobal.com...
> Dmitry A. Kazakov wrote:
> >>I'd like to be able to hand off a collection of source code and say
> > 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
Randy Brukardt
> 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.
tmo...@acm.org
>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
offered that. If so, how did it work out?
Jeffrey Carter
>>
>> 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
Marin David Condic
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
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
relates to some breadboard version of the system that dummies up some
stuff that exists differently on the "real" hardware. Or I might want to
make a version of some of the code that operates on a workstation by
faking out hardware that exists in the real unit. Or I might have
multiple turns of a hardware board that each have peculiarities that
need to be coded around. Or I might have multiple versions of an RTOS
with variations on system calls that change from one version to the next.
I've encountered all of these in real-world situations and sometimes I
might have dealt with them by having separate bodies (often really
difficult to manage in practice) or I dealt with them via conditional
compilation because I was using C. I just know it happens enough where
conditional compilation would be a useful thing and not always a matter
of abuse. If someone thinks it isn't really needed because it can be
dealt with via some kind of CM or build process - I'd suggest they need
to work in some of the environments I've been in where you either don't
have the tools or there are all sorts of complications that make this
really hard to do.
Conditional compilation isn't always pretty - but then neither are rep
clauses or other things that are regularly done because that's the
easiest way to get the job done.
MDC
Warren W. Gay VE3WWG wrote:
>
> There is still a strong need for conditional compilation.
> Not for embedded work, since you have very specific
> targets for that code. But if Ada is to support the
> general purpose computing environment, and to support
> portability, it must have better facilities for the
> portability issues that come up.
>
--
Marin David Condic
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
Robert I. Eachus
> 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
Randy Brukardt
news:4011CF46...@noplace.com...
...
> I've encountered all of these in real-world situations and sometimes I
> might have dealt with them by having separate bodies (often really
> difficult to manage in practice) or I dealt with them via conditional
> compilation because I was using C. I just know it happens enough where
> conditional compilation would be a useful thing and not always a matter
> of abuse. If someone thinks it isn't really needed because it can be
> dealt with via some kind of CM or build process - I'd suggest they need
> to work in some of the environments I've been in where you either don't
> have the tools or there are all sorts of complications that make this
> really hard to do.
You want to change the language because you've had to work in poorly managed
shops with insufficient tools? Sure, we all do what we have to do to get the
job done, but that hardly justifies a major language change (and one where
no obvious workable solution springs to mind).
> Conditional compilation isn't always pretty - but then neither are rep
> clauses or other things that are regularly done because that's the
> easiest way to get the job done.
I think you're comparing apples to oranges. Rep clauses are an elegant way
of getting the job done; the only alternative is bit mask operations and
those are a lot harder to understand. And they certainly aren't about just
interfacing to hardware - I use them a lot to reduce storage use without
making critical parts too slow. So I guess I'd say that rep. clauses ARE
pretty. You'd be better off picking on Access_to_Address_Conversions or
something like that -- except that no one much uses any of those packages.
Perhaps because they are ugly.
I'm not personally against conditional compilation, I just don't see any way
to integrate a useful form of it into the language. (I don't think it is
necessary in an ideal world, but the world is hardly ideal - people write
gibberish in C and Java after all.) The form that Janus/Ada has (and we no
longer use in new code because it isn't flexible enough) is a pure binary
in-or-out scheme intended solely for marking debugging code. ('@' is either
compiled as a comment "--" or as a space ' ' depending on the command line
options.) Pragmas have a number of problems: they can't be used in some
parts of the code (for example, formal_parts and discriminant_parts); such a
pragma would violate "good taste in pragmas" as laid out in 2.8; and enough
people think that they're ugly to prevent them from being used this way.
(GNAT's pragma Debug was considered and discarded for this reason.) Some
sort of syntax would be needed, and that seems like it would be pretty
heavy. (And I have no idea what it ought to look like.)
If you want to propose something, feel free, but remember that the ARG is
not taking new topics anymore, so unless you can find a way to coordinate it
with an existing AI, it will have to wait for Ada 1Z.
Randy.
All-in-all, it seems like there
Robert I. Eachus
> 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
> 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
> Tell me, how do you solve the situation where API call to your
> OS requires 3 parameters on one platform, and 2 on another? No
> if statement can solve that for you.
Of course it can, see above. I sometimes feel dirty having two Ada
templates bound (by the linker) to the same C function, and depending on
configuration constants to insure that I make call with the correct
parameters for this environment. But I do it.