Offical Ada FAQ

Offical Ada FAQ

[David Botton]

The Official Ada FAQ

http://www.adapower.com/faq



-----------------------------------------------------------------------------

Category:
Ada Compiler Questions

-----------------------------------------------------------------------------

Question:
Is there a version of Ada for .NET?

Answer:
Yes, A# - http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

Question:
Is there a version of Ada for MacOS or OS X ?

Answer:
Yes, http://www.macada.org

Question:
Is there a GNU version of Ada?

Answer:
Yes, a free as in liberty and beer is available from 
http://libre.act-europe.fr/GNAT/. A supported version is available from 
AdaCore Technologies at http://www.gnat.com

Question:
Is there a version of Ada for Windows?

Answer:
Yes

There is a free as in liberty and beer Win32 compiler available from 
http://libre.act-europe.fr/GNAT/.

A supported version of that compiler is available from AdaCore 
Technologies at http://www.gnat.com

A Visual Studio Style produce called ObjectAda is available from Aonix

RR Software sells Janus/Ada along with CLAW a think binding to Windows 
and a CLAW GUI builder.

Question:
Is there a version of Ada for Linux?

Answer:
Yes, GNAT, the GNU Ada compiler, is part of the gcc suite of compilers 
and is included in most distributions of Linux. You can also download 
GNAT from http://libre.act-europe.fr/GNAT/

A supported version of GNAT is available from AdaCore Technologies

Aonix also has a version of ObjectAda for Linux

Question:
Is there a version of Linux for IBM OS/2 Warp?

Answer:
Yes, see http://www.unixos2.org/ada/

Question:
Is there an Ada compiler for the JVM (Java Virtual Machine)?

Answer:
Yes, the GNU GNAT compiler for the JVM, jGNAT, is available. ObjectAda 
for Windows can also compile to the JVM.

-----------------------------------------------------------------------------

Category:
Ada General Questions

-----------------------------------------------------------------------------

Question:
What is the history of Ada?

Answer:
Ada 83

In 1974, a group from each of the services independently proposed the 
adoption of a common language. The Army began a study called 
Implementation Language for Real Time Systems; the Navy called theirs 
the CS4 Program, while the Air Force effort was named the High Order 
Language Standardization Study.

After reviewing these individual efforts to reinvent the wheel, Lt. 
Col. Bill Whitaker, then with the Department of Defense for Research 
and Engineering, felt that a joint-service effort made the most sense. 
As a result, Malcom Currie, who was director of the Department of 
Defense for Research and Engineering, directed that a joint-service 
program be implemented in January 1975.

He also instructed that no further funds be expended implementing new 
programming languages in major defense systems until the problem of 
software commonality had been resolved.

George Heilmeier left OUSDRE at that time the head up the Advanced 
Research Project Administration (now DARPA), and Lt. Col. Bill Whitaker 
(USAF) went with him. A high-order language working group (HOLWG) was 
formed with Whitaker as chairman.

Other representatives included Cmdr. Jack Cooper, the Navy 
representative (along with Bernie Zempolich and Robert Kahane), Bill 
Carlson of ARPA, Maj. Tom Jarrell of the Air Force, Paul Cohen of the 
Defense Communications Agency (DCA), Lt. Col. Schamber of the Marine 
Corps, and Maj. Breault of the Army.

Each representative had another full-time job, and the working group 
met once a month. Their charter was to investigate establishing a 
minimal number of common high-order computer programming languages for 
use in the development, acquisition, and support of computer resources 
embedded within defense systems.

In particular, it was to define the technical requirements for a common 
language, compare them with existing languages, recommend adoption or 
implementation of the necessary languages, and monitor and assist those 
efforts.

Thus, the working group coordinated all the activities of the common 
language effort, but it did not participate directly in the design or 
implementation of any programming language or associated software.

By the spring of 1975, the working group had begun determining the 
characteristics of a general-purpose programming language suitable for 
embedded computer applications.

The characteristics were to be given in the form of requirements that 
would act as constraints on the acceptability of a language but would 
not dictate specific language features. The requirements were not a 
language specification, but instead they attempted to define rigorously 
the needed characteristics in a form that could be critically reviewed.

The next step was establishing a first iteration call a "Strawman." 
This was quite informal since there was no real funding at that point. 
The Strawman requirements were typed, copied, and distributed. Several 
widely accepted, general goals were listed including efficiency, 
reliability, readability, simplicity, and implementability.

None of these features was quantifiable; however, it was decided that 
no specific language features would be adopted at that time since those 
types of requirements would impose strong constraints on the form 
without necessarily increasing the effectiveness of the languages. Just 
prior to Strawman, ARPA's Bob Fox hired Dave Fisher. Just as Bill 
Whitaker was the driving political force, Dave Fisher became the 
technical force behind the Strawman.

Bill Carlson orchestrated the business side, and in a series of 
entrepreneurial maneuvers, Bill Whitaker cajoled, jaw-boned, and 
produced political support from the DDR&E, followed by funding, which 
came first in 1976 from the Navy. Then, like a skilled oral surgeon 
extracting an impacted wisdom tooth, he extracted several million 
dollars from each of the services.

One of the sad commentaries of our time is that the people who drive 
joint programs are never appreciated in their own service; typically, 
they are perceived to be boat rockers. Col. Whitaker admits that he was 
never the most popular fellow in the Air Force.

Fortunately there are still men like him who are willing to sacrifice 
their career for the nation's good. The contribution of Lt. Col. 
Whitaker's group to our DOD will be measured in billions of dollars 
saved and order-of-magnitude increases in productivity.

The next step was called the Woodenman. The reviews of the Strawman 
requirements were formed into a complete, yet tentative, set of 
requirements. Also contained were descriptions of the general, or 
nonquantifiable, desired characteristics. The Woodenman also contained 
many other welcome characteristics whose feasibility, practically, and 
mutual compatibility had not been tested.

The Woodenman was widely distributed, not only within the military, but 
also to other government agencies, the computer science research 
community, and industry. Altogether, more than 100 expert review teams 
in fifteen nations were solicited for comments.

Based on the reviews of the Woodenman requirements, the next iteration, 
named "Tinman," was derived. The Tinman removed the requirements for 
which there was no sound rationale, restricted unnecessarily general 
requirements, and modified others to be practical within existing 
technology.

In January 1976, each of the requirements in Tinman was officially 
approved for all the military departments by the assistant secretary of 
defense for research and development. The document was then circulated 
for comment, and in October of that year a workshop was held at Cornell 
University to discuss the technical issues raised by the requirements 
and to investigate their feasibility.

Concurrent with the development of Tinman, twenty-three programming 
languages were evaluated against the developing requirements. Sixteen 
companies and organizations performed these evaluations, and most of 
the languages received at least two evaluations.

It was found, however, that no language satisfied the requirements well 
enough that it could be adopted as a common language. Several of the 
languages were sufficiently compatible with the technical requirements 
so that they could be modified to produce an acceptable language.

All of the languages in this group are derivatives of Algol-68, Pascal, 
or PL/1. Without exception, the evaluators found all the 
interim-approved languages to be inappropriate as a basis for 
developing a common language. The consensus held, however, that it was 
possible to produce a single high-order language that would meet 
essentially all the Tinman requirements.

In January 1977, an Ironman version of the requirements was issued. 
These requirements were substantially the same as those of Tinman, but 
they were modified for feasibility and clarity and were presented in an 
entirely different format.

Tinman was discursive and organized around general areas of discussion. 
Ironman, on the other hand, was very brief and organized like a 
language description or manual. It was essentially a specification with 
which to initiate the design of a language.

Early in 1977, with Ironman complete, the DOD held a design 
competition, and most of the fifteen proposals received, including the 
four best, were based on Pascal. These four, Cii-Honeywell Bull, 
Intermetrics, SofTech, and SRI International, began parallel design 
efforts in August 1977, and each of the teams was coded with a color to 
preserve anonymity during the source selection.

In 1978 the four designs were evaluated by 125 design review teams from 
around the world. In addition, the contractors were required to defend 
their designs in intensive oral examinations. Two of the four initial 
contractors were chosen to proceed further, and the requirements were 
further refined to "Steelman".

After more than 900 expert review teams participated in a process that 
was held virtually in a fishbowl for continual public and scientific 
scrutiny, a winning language was selected.

The design competition's eventual winner was the Green team 
(Cii-Honeywell Bull), led by the Frenchman Jean Ichbiah. He had been 
responsible for the design of the computer language LIS in 1972, as 
well as its later revision. As a result of his role in developing Ada, 
Dr. Ichbiah was awarded the Certificate of Distinguished Service by the 
DOD and the Legion of Honor by the President of France.

The language's name, Ada, was chosen and named for the mathematician 
Lady Augusta Ada Byron (1815-1852), Countess of Lovelace and daughter 
of the poet Lord Byron. She worked with Charles Babbage, who had 
created a "difference engine" that could be "programmed" much like the 
Jacquard loom.

Since Ada often "programmed" the difference engine, she is considered 
by many to be the first programmer. The military standard specification 
MIL-STD-1815 was chosen to reflect the year of her birth.

In the meantime, HOLWG was in a transitional state. Dave Fisher became 
chairman in the summer of 1979; Maj. Ben Blood became the Army 
representative; and Lt. Col. Larry Druffel (USAF) also joined the 
group. He began looking at the programming environment and started the 
Stoneman project.

Environments can be categorized as either closed or open-ended, and the 
distinction is fundamental. In a closed environment, the user is a 
fixed set of tools that are presumably sufficient to meet all basic 
requirements.

A closed environment cannot be altered or extended, short of re-issuing 
the environment by the suppliers. The tool set in an open-ended 
environment, on the other hand, can be modified or extended at any time.

Lt. Col. Druffel decided that Stoneman would represent a firm 
commitment to an open-ended environment since this commitment is 
important at the individual user, project, and overall environment 
levels.

In an open-ended environment, individual users can develop tools that 
support their own style of working. The user may find that many tasks 
can be accomplished efficiently by an indirect programming approach, 
which involves the development of application specific tools.

A project can benefit from tools such as application environment 
simulators or preprocessors that check adherence to project coding 
standards. The overall environment's complete tool set can be upgraded 
to reflect developments in technology and to some degree this can 
protect the environment against obsolescence.

A more significant issue concerning open-ended environments is the 
complete and accurate recording of relationships among data base 
objects, even when these objects are created by user supplied tools.

Without such recording, an open-ended environment would be a liability 
rather than a benefit since it would no longer be possible to provide 
complete and accurate information throughout the life cycle.

In December 1980, the HOLWG became the Ada Joint Program Office (AJPO), 
with Lt. Col. Druffel as its interim manager. ARPA turned Druffel loose 
six months later, and he officially became manager of the AJPO.

Paul Cohen served as technical director, and Mark Grove, now with TRW 
in San Diego, led the steering committee. Other key players during 
those early years were George Heilmeier (as director of ARPA), Len 
Weissberg (later instrumental in the VHSIC program), and Bob Fossum (as 
director of DARPA).

At a convention in Boston during the summer of 1980, Bill Carlson, who 
was the keynote speaker, and Dave Fisher, who gave the wrap-up speech, 
both announced that they were leaving ARPA and joining Western Digital.

In 1978, as Dr. Ichbiah's team began developing the Ada language in 
France, an Ada project began across the sea at New York University as a 
small-scale study of optimization issues relating to Ada.

It became clear at once that Ada was, at the time, very loosely defined 
and that a more rigorous definition of the language was needed if a 
meaningful study of compilation issues was to be undertaken.

This led to the first executable semantic model of Ada, consisting of 
about 2000 lines of SETL, which is a very high-level language developed 
at NYU. Its basic constructs are those of the theory of sets. It is an 
imperative, sequential language with assignment, weak typing, dynamic 
storage allocation, and the usual atomic types, numeric types, 
booleans, strings, and generated atoms (Gensyms).

Thus, it is relative of LISP, Snowbol, and APL. This model described 
the executable aspects of the language in the form of an interpreter 
for an ad hoc intermediate representation dubbed AIS (Ada Intermediate 
Source).

In the following two months, an LALR (Look Ahead from Left to Right) 
parser was added that generated AIS for correct Ada programs only. In 
the course of the following six months, static semantic checks were 
progressively added so that when the 1980 definition of Ada was 
released, Ada/Ed was a working model of most of its static dynamic 
semantics.

Several features that clearly could not be implemented in their 
preliminary Ada description (e.g., discriminants and subprogram 
derivation) were purposefully left out and were added when the 1980 
standard appeared.

On the other hand, the semantics of tasking, including rendezvous, task 
activation, and abort and select statements, were faithfully described 
from the beginning. At that point it became clear the Ada/Ed could 
serve both as a prototype translator and as a rigorous definition of 
Ada, and both goals were subsequently pursued.

The latter use is a consequence of (1) the compactness of the system 
(25,000 lines of subtl, including documentation), (2) the very abstract 
model chosen to represent the run-time environment, and (3) the 
demonstrable agreement between Ada/Ed and the Ada Compiler Validation 
Capability (ACVC) tests, which constitute an additional de facto 
definition of the language.

Within six months, Ada/Ed was adapted to reflect the 1982 reference 
manual, and in early 1983 it was further modified to reflect in the 
final changes that led to the ANSI (American National Standards 
Institute) standard document.

Ada/Ed was validated by the AJPO in April 1983. Only 100 man-months 
were expended from the inception of the 1979 NYU Ada project to the 
validation of the 1983 ANSI Ada/Ed

(AdaIC Flyer H031-0291c)

Ada 95

Ada 95 was designed and developed from an international process of 
unprecedented scale for a programming language. A Board of 
Distinguished Reviewers -- representing six different countries and 
comprised of twenty-eight world renowned leaders in academia and 
industry -- provided oversight and evaluation of the immense input from 
the international community of users. Over 750 recommendations were 
received by individuals who were invited to submit Revision Requests -- 
many from the world's leading companies. Conferences, workshops, small 
group meetings and one-on-one consultations were held with other 
segments of the Ada community, and advice was received from some of the 
world's finest software engineers and government technology leaders. 
The entire revision process required over four years to complete.

The revision retains the inherent integrity and efficiency of the 
original version of Ada, called Ada 83, as the first advanced 
building-block language to assemble a host of important features while 
adhering to the demands of modern software engineering practice. In 
addition to OOP support, the new Ada provides more efficient real-time 
programming facilities while remaining fully portable, and addresses 
vital concerns for business such as the effective integration of legacy 
systems and upward compatibility.

New features include international character sets, improved generics 
(similar to C templates), and a set of changes that will reduce the 
time needed to recompile large systems. Ada 95 remains a strongly typed 
language, with full support for encapsulation and information hiding. 
Increased functionality allows for support of smaller, more dynamic 
systems; unnecessary assumptions have been eliminated, existing 
features are generalized and special cases or restrictions have been 
removed.

The revision is an update of the 1987 ISO release and the equivalent 
1983 American National Standards Institute (ANSI) Ada standard. Drafts 
of the revised standard were formally considered by the ISO between 
September, 1993 and October, 1994; ballots were cast over a period of 
15 months by the 22 member countries, and officially tallied on 
November 1, 1994. ISO delegates accepted the revision by a vote of 18 
yes, 0 no.

(ARA press release Feb 15, 1995)

Question:
Is there a usenet newsgroup for Ada?

Answer:
Yes, a very active one. comp.lang.ada

Question:
What specific features does Ada have that makes it reliable?

Answer:
Ada has language-defined static and runtime checks for many unsafe 
conditions, such as integer overflow, dereferencing invalid pointers, 
bad array indexes (fencepost issue), etc. It also is a highly typed 
language and the implementation tries to make the programmer ensure 
that data are relevant to the operation before an operation is 
performed. Furthermore, Ada comes with a very high-level 
multiprogramming paradigm and allows simpler specification of intricate 
conditions than other languages allow.

(John Duncan)

Question:
Is there any scientific evidence that indicates Ada is more productive 
and/or safer than other languages?

Answer:
Measurement of productivity and defects in any software realm gets to 
be highly problematic. This is especially true if one wants some degree 
of scientific rigor. Why? The biggest reason is that in software 
development, we almost never build the same thing twice under the same 
conditions. Add to that the fact that there are no accepted standards 
of measurement for productivity and defects and you see how intractable 
the problem can be.

Still, a number of studies have been done that provide a significant 
amount of support to the claim that Ada improves productivity and 
reduces defects. Your humble narrator was charged with measuring both 
of these phenomena in a prior job position. We built electronic 
controls for jet and rocket engines. The team of developers were highly 
experienced, stable and versed in a variety of programming languages. 
Ada was introduced as a new language for new projects and the team had 
to learn & use it for developing embedded systems. Productivity and 
defect measurement over several years of development indicated that 
productivity approximately doubled and defects were reduced by a factor 
of four compared to projects using a variety of other languages.

Unfortunately, this being an internal study and companies often being 
reluctant to share internal information, nothing from this study was 
published. However, this was not the only source for productivity data.

Other studies have been done and (presuming the links remain valid) 
better sources for study data can be found at:

http://www.stsc.hill.af.mil/crosstalk/2000/aug/mccormick.asp 
http://www.tcsigada.org/meeting/feb99mtg.htm 
http://www.rational.com/products/whitepapers/337.jsp

The most imortant study in my mind was done by Dr. McCormic in which he 
had students in several semesters building software to run a model 
railroad. Some of the classes used C to implement their systems while 
later classes used Ada. Dr McCormick's studies come about as close to a 
controlled experiment in software productivity as I've seen. His 
experience is based on multiple groups building software to satisfy 
identical requirements under nearly identical circumstances. That, I 
think, offers a little more weight to his results than might be given 
to my own internal study. The conclusion was that the use of Ada 
significantly improved the ability of the teams to complete their 
projects on time and dramatically reduced the number of errors/defects 
in the end results. Other companies have had similar experiences (see 
the Rational white paper) so from available data, one has some 
significant evidence that Ada is more productive and less error prone 
when compared to some other languages.

One must always be careful when looking at these sorts of studies and 
realize that a lot goes into productivity, defects and project success 
beyond the language of implementation. In other words, your mileage may 
vary. The benefit of the studies that have been done is that you can 
see evidence that supports the claim of better productivity and defect 
rates with Ada. It gives one good reasons to consider Ada for future 
projects.

(Marin David Condic)

Question:
I heard tell that Ada was to blame for the Ariane V disaster. Is this true?

Answer:
The short answer is "No". Here's the long answer:

The software for the Inertial Reference System (IRS) on the Ariane 5 
was identical to the software used successfully on the Ariane 4 rocket. 
Basically, the developers took an "Off The Shelf" part (the IRS) that 
consisted of hardware and software, the design of which was used 
successfully on the Ariane 4 project, and bolted it onto the Ariane 5 
rocket completely untested. The Ariane 5 rocket had a substantially 
different flight profile than the Ariane 4 was capable of. When the 
rocket started its flight, it moved at angles that were substantially 
larger than the Ariane 4 flight path would generate. The inertial data 
exceeded the range limits of the Ariane 4 software.

The system was designed with a dual-redundant computer (two processor 
boards that are identical, running identical software.) One part of the 
software in question was performing calculations on the inertial data 
and needed to do so repeatedly in a very small amount of time. The 
original designers needed to speed up the software so they performed an 
analysis of the incoming data and concluded that within the Ariane 4 
flight profile, numbers outside of a certain range would never occur. 
If such numbers *did* occur, it would be most likely that a sensor had 
failed and was generating wildly out of range data. Hence, it was safe 
to remove any error-handling code and instead design in Failure 
Detection and Accommodation (FDA) logic.

The logic went something like this: "If a number comes in over a 
certain size, it will trigger a hardware overflow condition. The 
hardware will trap to an Interrupt Service Routine (ISR) for handling 
of that condition. The ISR presumes that if it was reached, then there 
must be a hardware fault. In the event of a hardware fault, the 
software will shut down the computer and transfer to the 'spare' 
ccomputer - which is why we have a 'spare' in the first place." All of 
this makes sense because the flight path of the Ariane 4 would never 
generate numbers large enough to cause an overflow - unless the 
hardware was broke. The whole analysis and design was in place, tested 
and flew successfully for the Ariane 4 rocket.

Now comes the bad part: The design team for the Ariane 5 looked at the 
IRS for the Ariane 4 and figured that they had a reliable piece of 
hardware that would work fine for the Ariane 5 and they could save 
money by reusing an existing design. That's what they did. Only they 
started to make unwarranted assumptions - that the unit would work on 
the Ariane 5 flight trajectory and that it didn't need to be tested in 
any way against the flight path expected. (Thus saving more money.) Had 
they run even the most rudimentary tests of the unit against the 
expected flight path of the Ariane 5, they would have triggered the 
condition and detected that they had a problem. They never did.

When the rocket flew for the first time, both dual-redundant computers 
detected the overflow condition. Both presumed that the cause was a 
hardware failure. Both shut down in an attempt to leave the other side 
in control. They did *exactly* what they were designed to do and in 
that sense behaved flawlessly.

The fact that the computers in question were programmed in Ada had 
absolutely nothing to do with the reasons for the crash. It had no more 
to do with the crash than the fact that both computers were using a 
Mil-Std-1750a microprocessor - a computer that has been used reliably 
in numerous space applications. The original software designers were 
not to blame either. They designed their software logic for the problem 
at hand and had to work within the CPU time limitations they were 
given. Their FDA logic was *perfect* for the Arriane 4 rocket.

The fault lay with the designers of the Ariane 5 and their failure to 
test their assumptions. It would be analogous to taking a tire that was 
designed to work on a Corvette and "reusing" it in the design of a 
Freightliner truck. It works *fine* when the only weight it has to 
support is a Corvette sports car. What would it likely do trying to 
support the weight of a Freightliner truck?

(Marin David Condic)

Question:
Where can I find out more about Ada 2005?

Answer:
At http://www.gnat.com/ada_2005.php

Question:
What is Ada?

Answer:
Ada is the most powerful object-oriented general purpose programming 
language. It has built-in concurrency, built-in exception handling, 
built-in generic templates, built-in distributed execution, standard 
and defacto standard interfaces to other programming languages and 
libraries, compiles to .NET, Java Byte Code and just about any OS under 
the sun, and a rich set of primitives for getting at and putting to 
work all that expertise you've embedded in your software.

Question:
Isn't Ada less "elegant" than Eiffel?

Answer:
I guess one thing that bothers me a little is that people are quick to 
say that Eiffel is "elegant" without really looking at it. I fear that 
such statements will become self-fulfilling prophecies, with those 
programmers interested in elegance migrating over to Eiffel rather than 
sticking with Ada.

In particular, although I like the assertion stuff in Eiffel, I think 
the language has a number of "inelegant" aspects. For example:
exception handlers only at the top level of a routine, with the only 
way to "handle" an exception being by retrying the whole routine.
No way to return from a routine in the middle. This makes it a pain in 
the neck to search through a list for something in a loop, and then 
return immediately when you find what you want. (I have never found the 
addition of extra boolean control variable a help to the understanding 
of an algorithm.)
Namespace control handled by a separate sublanguage, and no real higher 
level concept of "module" or "subsystem."
An obscure notation like "!!" being used for an important and frequent 
operation (construction).
No way to conveniently "use" another abstraction without inheriting from it.
No strong distinctions between integer types used for array indexing.
Using the same operator ":=" for both (aliasing) pointer assignment, 
and for value assignment, depending on whether the type is "expanded." 
(Simula's solution was far preferable, IMHO).

And most critically:
No separate interface for an abstraction. You can view a interface by 
running a tool, but this misses completely the importance of having a 
physical module that represents the interface, and acts as a contract 
between the specifier or user of an abstraction and its implementor. In 
Eiffel, one might not even be truly aware when one is changing the 
interface to an abstraction, because there is no particular physical 
separation between interface and implementation.
I consider many of the above problems quite serious, with some of them 
being real throwbacks to the old style of programming languages where 
there were no well defined interfaces or modules.

Hence, I cringe a bit when people say that Eiffel is the "most elegant" 
OOP and that they would use it if only it were practical to do so. In 
many ways, I think Ada is much better human-engineered than Eiffel, 
with important things like range constraints built into the language in 
a way that makes them convenient to use. Although general assertions 
are nice, they don't give you the kind of line-by-line consistency 
checks that Ada can give you.

To summarize --
Although Eiffel certainly has a number of nice features, I don't 
consider it ready for prime time as far as building and maintaining 
large systems with large numbers of programmers. And from a human 
engineering point of view, I think Ada is significantly better.

(Tucker Taft)

Question:
I keep hearing that Ada is a "strongly typed language", but it seems 
different from what's meant in C++. Are they different?

Answer:
I certainly agree that ANSI C and C++ are statically typed languages, 
but I would debate the "strength" of their typing.

Essentially any support for implicit conversion (implicit "casting," 
"promotion", "usual" arithmetic conversions, etc.) "weakens" a type 
system (but also makes it "friendlier" in some ways).

C allows implicit conversion between all integer types and all 
enumeration types. C++ at least cuts off implicit conversion to 
enumeration types, but retains implicit conversion among all integer 
(and floating-point) types. Also, in both C and C++, typedefs for 
pointer/array types are essentially "macros"; all pointer types with 
the same target type are implicitly interconvertible.

Finally C++ allows the user to define a number of their own implicit 
conversion operators, which basically allows the user to "weaken" the 
type system as they see fit.

Of course, all of this implicit conversion serves a purpose, but it 
does tend to move C/C++ toward the "weaker" end of the weak vs. strong 
typing spectrum.

Note that the "strong" distinctions between integer types helps 
dramatically in catching (at compile-time) array indexing errors in Ada 
programs, by making sure that if you have an array indexed by a count 
of apples, you don't index into it with a count of oranges (without an 
*explicit* conversion). The advantages of "strongly" distinguishing 
enumeration types is even more obvious (and the designers of C++ 
recognized this).

The strong distinctions between access types (pointer types) in Ada 
also has advantages, allowing access types to be represented as offsets 
within their storage pool rather than as addresses, and giving more 
high-level control over storage management.

Strong typing can be carried too far, and some amount of implicit 
conversion is essential to make OOP palatable. But note that in Ada 95, 
even with OOP, we don't allow implicit conversions that truncate the 
extension part of a record (this is a relatively common mistake in C++ 
when passing parameters by value). Instead, in Ada 95, the language 
distinguishes between a specific type T and the class-wide type 
T'Class, and allows implicit conversions to T'Class from T or any of 
its derivatives, but not to the specific type T. Conversions to the 
class-wide type never implicitly truncate the extension part. 
Conversions to a specific type can truncate, and hence must be explicit.

Note also that in Ada there are three distinct kinds of conversions, 
implicit ones, explicit ones, and unchecked ones. Only the unchecked 
ones are potentially unsafe. The explicit ones are safe, with either 
compile-time or run-time checks to ensure that. In C there are only 
implicit and explicit/unchecked conversions. C++ has recently added a 
checked, explicit "dynamic" cast, but still it will be common to use 
"normal" explicit casts for both checked and unchecked conversions, 
thereby making it more difficult to identify places where the type 
system might be compromised.

Hence, the bottom line is that the type checking is (objectively) 
"stronger" in Ada than C/C++, though that doesn't necessarily mean 
"better" -- whether one is "better" for a particular style of 
programming than the other is a "religious" issue IMHO. I know my 
religion currently favors the stronger checking of Ada in most cases 
[except perhaps for multiply/divide, where I personally believe the 
checking should either be weaker, or directly support the concept of 
"units"/"dimensions"].

(Tucker Taft)

-----------------------------------------------------------------------------

Category:
Ada Programming Questions

-----------------------------------------------------------------------------

Question:
Why doesn't Ada use 'dot' notation for OO?

Answer:
If you are used to the notion of an abstract data type, defined by a 
type and a set of operations, and then you decide you want to support 
extensibility of abstract data types, then you end up at something very 
much like Ada 95, Haskell, or CLOS, with the "operation(operand, 
operand, ...)" or "operand operand" or "object := operation(operand, 
operand,...)" syntax familiar from theoretical mathematics and logic.

If you instead focus on updating objects as the primary operations of 
interest, then you end up with the . syntax.

In some ways, the Ada 95 syntax is more sympathetic with the 
"value-oriented" (i.e. functional) way of thinking than the 
"object-oriented" (i.e. side-effecting) way of thinking.

The net effect, in any case, is that you can more easily write in a 
"functional" style in Ada 95 where there is less use of heap-resident 
read/write objects, and more use of values (rather than objects) of an 
abstract type being passed around, assigned, declared, etc.

(Tucker Taft)

Question:
Where can I find an Ada bindings for X?

Answer:
A comprehensive collection of all known Ada bindings and libraries on 
the net is kept at http://www.adapower.com/reuse/

Question:
Are classes first class objects?

Answer:
In Ada-speak, you mean to say "Are types first class objects?" The 
answer is no.

However, this is one of those times where you have to say what it is 
you're trying to accomplish. For that problem, the language probably 
has other mechanisms to solve it.

(Matthew Heaney)

Question:
Can you access super methods?

Answer:
Do you mean "call the operation of the type's parent"?

The answer is yes, by converting the object to the parent type, and 
then invoking the operation.

For example, suppose I have some special kind of bounded stack:


generic
package Stacks.Bounded_G.Special_G is

  type Stack_Type is new Bounded_G.Stack_Type with private;

  procedure Push (...);

end;



-- instantiate the special stack package --

Now let's call the parent Push operation:


 declare
   Stack : Integer_Stacks.Bounded.Special.Stack_Type;
 begin
   Push (1234, On => Bounded.Stack_Type (Stack));
   ...
 end;



Even though the Stack object is of specific type Special.Stack_Type, 
which has its own version of Push, the Push operation of its parent is 
invoked.

No, Ada95 does not have a way to say "invoke my parent's operation."

(Matthew Heaney)

Question:
Does Ada provide Strings facilites or a string library?

Answer:
Ada provides three string packages:


Ada.Strings.Fixed - operations on the builtin String type
Ada.String.Bounded - Varying size strings, with a maximum length
Ada.Strings.Unbounded - Varying strings that can be extended, so long 
as memory permits.
(Ehud Lamm)

Question:
How do I print an Integer, Float, enumeral using Text_IO or otherwise 
obtain a string representation of a scalar type?

Answer:
The simplest way to deal with string representations of any scalar type 
is with the attributes 'Image and 'Value. These attributes act as 
functions that return the string representation of a scalar object or 
return the scalar value of a string representation respectively. An 
example is below:
X : Integer ;
...
X := Integer'Value ("1234") ;

Ada.Text_IO.Put_Line (
    Item => "The image of X is: " & Integer'Image (X)) ;

Note that the attribute is associated with the data type. For a Float, 
you would use Float'Image and Float'Value. Likewise for Boolean, you 
have Boolean'Image and Boolean'Value. These attributes work for all 
scalar types, regardless of if they are predefined or user defined 
types.

Alternatively, the generic packages for scalar text input and output 
provide the ability to perform I/O either to files or strings with a 
little bit better control of the representation and format. They are 
somewhat more complicated, but provide more power to the user. Packages 
you should look at are: Ada.Text_IO.Integer_IO, Ada.Text_IO.Modular_IO, 
Ada.Text_IO.Float_IO, Ada.Text_IO.Enumeration_IO where you have 
procedures that are of the form:
Get (
    Item    => X) ;
Get (
    File    => Some_File,
    Item    => X) ;
Get (
    From    => Some_String,
    Item    => X,
    Last    => Some_Positive) ;

(Similar services available for Put procedures, but with more options 
for formatting the output)

Pre-instantiated packages exist for the standard numeric types with 
names like Ada.Integer_Text_IO and Ada.Float_Text_IO, but there is some 
dependency on implementation. (Some compilers may have an 
Ada.Long_Long_Float_Text_IO and others, not. See the ARM and your 
compiler documentation.)

References:

ARM 3.5 (11), ARM A.10, ARM K (88-91), ARM K (264-267)

(Marin David Condic)

Question:
Does Ada have an XML parser?

Answer:
There are a few Ada XML parsers available.

See http://www.adapower.com/reuse

On Windows, you can also use the MSXML COM object via GNATCOM

Question:
Does Ada have multiple inheritance?

Answer:
Ada supports multiple inheritance with a building block approach rather 
than a language construct. Most uses of multiple inheritance fall into 
one of three idioms� each of which can be implemented in Ada:

Combining Implementation and Abstraction:

Combining two classes, one that defines the protocol of the component, 
and another that provides an implementation. In Ada, one may implement 
one type in terms of another, and hide that implementation as a private 
type.

Mixin Inheritance:

One of the parent classes cannot have instances of its own and exists 
only to provide a set of properties for classes inheriting from it. Ada 
95 can provide mixin inheritance using tagged type extension (single 
inheritance) and generic units. The generic template defines the mixin. 
The type supplied as generic actual parameter determines the parent.

Multiple Views:

The derived type or class is truly a derivative of more than one parent 
and clients of that type want to "view it" as any of its parents. This 
may be accomplished in Ada 95 using access discriminants which 
effectively enable us to parameterize one record with another.

An access discriminant can be used to enable a component of a record to 
obtain the identity of the record in which it is embedded. This enables 
complex chained structures to be created and can provide multiple views 
of a structure.

(T.E.D)

Question:
Is it possible to use COM/DCOM from Ada?

Answer:
Yes, see GNATCOM

Question:
Can I use Active X controls with Ada?

Answer:
Yes, see GWindows

Question:
Can I create Web Services and SOAP objects with Ada?

Answer:
Yes, see AWS

Question:
Can I use CORBA with Ada?

Answer:
Yes, see AdaPower.com: Ada Libraries: Distributed Computing

Question:
Why does Ada have "tagged types" instead of classes?

Answer:
In C++, the term "class" refers to three different, but related things: 
a language construct, that encapsulates the definitions of data 
members, member functions, nested types, etc.;

a particular kind of type, defined by a class construct (or by "struct" 
which is a special case of "class");

a set of types consisting of a type and all of its derivatives, direct 
and indirect.

In Ada 95, the term "class" refers only to the third of the above 
definitions. Ada 95 (and Ada 83) has three different terms for the 
concepts corresponding to the above three things:
"package" encapsulates the definitions of types, objects, operations, 
exceptions, etc which are logically related. (The operations of a type 
defined immediately within the package where the type is declared are 
called, in Ada 95, the "primitive operations" of the type, and in some 
sense, define the "primitive" semantics of the type, especially if it 
is a private type.)
"type" is characterized by a set of values and a set of primitive 
operations (there are a million definitions of "type," unfortunately, 
but you know what I mean...);
"class" is a set of types with similar values and operations; in 
particular, a type and and all of its derivatives, direct and indirect, 
represents a (derivation) class. Also, the set of integer types form 
the integer "class," and so on for the other language-defined classes 
of types in the language.
Some OOP languages take an intermediary position. In CLOS, a "class" is 
not an encapsulating construct (CLOS has "packages"). However, a 
"class" is both a type and a set of types, depending on context. 
(Methods "float" freely.)

The distinction Ada 95 makes between types and classes (= set of types) 
carries over into the semantic model, and allows some interesting 
capabilities not present in C++. In particular, in Ada 95 one can 
declare a "class-wide" object initialized by copy from a "class-wide" 
formal parameter, with the new object carrying over the underlying type 
of the actual parameter. For example:
     procedure Print_In_Bold (X : T'Class) is
       -- Copy X, make it bold face, and then print it.
       Copy_Of_X : T'Class := X;
     begin
        Make_Bold (Copy_Of_X);
        Print (Copy_Of_X);
     end P;

In C++, when you declare an object, you must specify the "exact" class 
of the object -- it cannot be determined by the underlying class of the 
initializing value. Implementing the above procedure in a general way 
in C++ would be slightly more tedious.

Similarly, in Ada 95 one can define an access type that designates only 
one specific type, or alternatively, one can define one that can 
designate objects of any type in a class (a "class-wide" access type). 
For example:
     type Fancy_Window_Ptr is access Fancy_Window;
       -- Only points at Fancy Windows -- no derivatives allowed
     type Any_Window_Ptr is access Window'Class;
       -- Points at Windows, and any derivatives thereof.

In C++, all pointers/references are "class-wide" in this sense; you 
can't restrict them to point at only one "specific" type.

In other words, C++ makes the distinction between "specific" and 
"class-wide" based on pointer/reference versus object/value, whereas in 
Ada 95, this distinction is explicit, and corresponds to the 
distinction between "type" (one specific type) and "class" (set of 
types).

The Ada 95 approach we believe (hope ;-) gives somewhat better control 
over static versus dynamic binding, and is less error prone since it is 
type-based, rather than being based on reference vs. value.

In any case, in Ada 95, C++, and CLOS it makes sense to talk about 
"class libraries," since a given library will generally consist of a 
set of interrelated types. In Ada 95 and CLOS, one could alternatively 
talk about a set of "reusable packages" and mean essentially the same 
thing.

(Tucker Taft)

Question:
Why are Controlled types so, well, strange?

Answer:
We considered many approaches to user-defined finalization and 
user-defined assignment. Ada presents challenges that make it harder to 
define assignment than in other languages, because assignment is used 
implicitly in several operations (by-copy parameter passing, function 
return, aggregates, object initialization, initialized allocators, 
etc.), and because Ada has types whose set of components can be changed 
as a result of an assignment.

For example:
     type T (D : Boolean := False) is record
       case D is
         when False => null;
         when True => H : In_Hands;
       end case;
     end record;

     X,Z : T;
     Y : T := (True, H => ...);

     ...

     X := Y;   -- "X.H" component coming into existence
     Y := Z;   -- "Y.H" component going out of existence

With a type like the one above, there are components that can come and 
go as a result of assignment. The most obvious definition of assignment 
would be:
     procedure ":=" (Left : in out In_Hands; Right : in In_Hands);

Unfortunately, this wouldn't work for the "H" component, because there 
is no preexisting "In_Hands" component to be assigned into in the first 
case, and in the second case, there is no "In_Hands" component to 
assign "from."

Therefore, we decided to decompose the operation of assignment into 
separable pieces: finalization of the left hand side; simple copying of 
the data from the right hand side to the left hand side; and then 
adjustment of the new left hand side. Other decompositions are probably 
possible, but they generally suffer from not being easily composable, 
or not handling situations like the variant record above.

Imagine a function named ":=" that returns a copy of its in parameter. 
To do anything interesting it will have to copy the in parameter into a 
local variable, and then "fiddle" with that local variable (essentially 
what "Adjust" does), and then return that local variable (which will 
make yet another copy). The returned result will have to be put back 
into the desired place (which might make yet another copy). For a large 
object, this might involve several extra copies.

By having the user write just that part of the operation that "fiddles" 
with the result after making a copy, we allow the implementation to 
eliminate redundant copying. Furthermore, some user-defined 
representations might be position dependent. That is, the final 
"fiddling" has to take place on the object in its final location. For 
example, one might want the object to point to itself. If the 
implementation copies an object after the user code has adjusted it, 
such self-references will no longer point to the right place.

So, as usual, once one gets into working out the details and all the 
interactions, the "obvious" proposal (such as a procedure ":=") no 
longer looks like the best answer, and the best answer one can find 
potentially looks "clumsy" (at least before you try to work out the 
details of the alternatives).

(Tucker Taft)

Question:
What is meant by upcasting/expanding and downcasting/narrowing?

Answer:
Here is the symmetric case to illustrate upcasting and downcasting.
     type A is tagged ...;   -- one parent type

     type B is tagged ...;   -- another parent type

     ...

     type C;   -- the new type, to be a mixture of A and B

     type AC (Obj : access C'Class) is
       new A
       with ...;
       -- an extension of A to be mixed into C

     type BC (Obj : access C'Class) is
       new B
       with ...;
       -- an extension of B to be mixed into C

     type C is
       tagged limited record
         A : AC (C'Access);
         B : BC (C'Access);
         ... -- other stuff if desired
       end record;

We can now pass an object of type C to anything that takes an A or B as 
follows (this presumes that Foobar and QBert are primitives of A and B, 
respectively, so they are inherited; if not, then an explicit 
conversion (upcast) to A and B could be used to call the original 
Foobar and QBert).
     XC : C;
   ...
     Foobar (XC.A);
     QBert (XC.B);

If we want to override what Foobar does, then we override Foobar on AC. 
If we want to override what QBert does, then we override QBert on BC.

Note that there are no naming conflicts, since AC and BC are distinct 
types, so even if A and B have same-named components or operations, we 
can talk about them and/or override them individually using AC and BC.

Upcasting (from C to A or C to B) is trivial -- A(XC.A) upcasts to A; 
B(XC.B) upcasts to B.

Downcasting (narrowing) is also straightforward and safe. Presuming XA 
of type A'Class, and XB of type B'Class:
     AC(XA).Obj.all downcasts to C'Class (and verifies XA in AC'Class)
     BC(XB).Obj.all downcasts to C'Class (and verifies XB in BC'Class)

You can check before the downcast to avoid a Constraint_Error:
     if XA not in AC'Class then -- appropriate complaint

     if XB not in BC'Class then -- ditto

The approach is slightly simpler (though less symmetric) if we choose 
to make A the "primary" parent and B a "secondary" parent:
     type A is ...
     type B is ...

     type C;

     type BC (Obj : access C'Class) is
       new B
       with ...

     type C is
       new A
       with record
         B : BC (C'Access);
         ... -- other stuff if desired
       end record;

Now C is a "normal" extension of A, and upcasting from C to A and 
(checked) downcasting from C'Class to A (or A'Class) is done with 
simple type conversions. The relationship between C and B is as above 
in the symmetric approach.

Not surprisingly, using building blocks is more work than using a 
"builtin" approach for simple cases that happen to match the builtin 
approach, but having building blocks does ultimately mean more 
flexibility for the programmer -- there are many other structures that 
are possible in addition to the two illustrated above, using the access 
discriminant building block.

For example, for mixins, each mixin "flavor" would have an access 
discriminant already:
     type Window is ...  -- The basic "vanilla" window

     -- Various mixins
     type Win_Mixin_1 (W : access Window'Class) is ...

     type Win_Mixin_2 (W : access Window'Class) is ...

     type Win_Mixin_3 (W : access Window'Class) is ...

Given the above vanilla window, plus any number of window mixins, one 
can construct a desired window by including as many mixins as wanted:
     type My_Window is
       new Window
       with record
         M1 : Win_Mixin_1 (My_Window'access);
         M3 : Win_Mixin_3 (My_Window'access);
         M11 : Win_Mixin_1(My_Window'access);
         ... -- plus additional stuff, as desired.
       end record;

As illustrated above, you can incorporate the same "mixin" multiple 
times, with no naming conflicts. Every mixin can get access to the 
enclosing object. Operations of individual mixins can be overridden by 
creating an extension of the mixin first, overriding the operation in 
that, and then incorporating that tweaked mixin into the ultimate 
window.

I hope the above helps better illustrate the use and flexibility of the 
Ada 95 type composition building blocks.

(Tucker Taft)

Question:
What is the difference between a class-wide access type and a "general" 
class-wide access type?

Answer:
What is exactly the difference between

type A is access Object'Class;

and
type B is access all Object'Class;

In the RM and Rationale only definitions like B are used. What's the 
use for A-like definitions ?

(Tucker Taft answers)

The only difference is that A is more restrictive, and so presumably 
might catch bugs that B would not. A is a "pool-specific" access type, 
and as such, you cannot convert values of other access types to it, nor 
can you use 'Access to create values of type A. Values of type A may 
only point into its "own" pool; that is only to objects created by 
allocators of type A. This means that unchecked-deallocation is 
somewhat safer when used with a pool-specific type like A.

B is a "general" access type, and you can allocate in one storage pool, 
and then convert the access value to type B and store it into a 
variable of type B. Similarly, values of type B may point at objects 
declared "aliased."

When using class-wide pointer types, type conversion is sometimes used 
for "narrowing." This would not in general be possible if you had left 
out the "all" in the declaration, as in the declaration of A. So, as a 
general rule, access-to-classwide types usually need to be general 
access types. However, there is no real harm in starting out with a 
pool-specific type, and then if you find you need to do a conversion or 
use 'Access, the compiler should notify you that you need to add the 
"all" in the declaration of the type. This way you get the added safety 
of using a pool-specific access type, until you decide explicitly that 
you need the flexibility of general access types.

In some implementations, pool-specific access types might have a 
shorter representation, since they only need to be able to point at 
objects in a single storage pool. As we move toward 64-bit address 
spaces, this might be a significant issue. I could imagine that 
pool-specific access types might remain 32-bits in some 
implementations, while general access types would necessarily be 
64-bits.

(Tucker Taft)

Question:
Does Ada have automatic constructors and destructors?

Answer:
In Ada 95, functions with controlling results are inherited (even if 
overriding is required), allowing their use with dynamic binding and 
class-wide types. In most other OOPs, constructors can only be called 
if you know at compile time the "tag" (or equivalent) of the result you 
want. In Ada 95, you can use the tag determined by the context to 
control dispatching to a function with a controlling result. For 
example:
     type Set is abstract tagged private;
     function  Empty return Set is abstract;
     function  Unit_Set(Element : Element_Type) return Set is abstract;
     procedure Remove(S : in out Set; Element : out Element_Type) is abstract;
     function  Union(Left, Right : Set) return Set is abstract;
  ...

     procedure Convert(Source : Set'Class; Target : out Set'Class) is
       -- class-wide "convert" routine, can convert one representation
       --   of a set into another, so long as both set types are
       --   derived from "Set," either directly or indirectly.

       -- Algorithm:  Initialize Target to the empty set, and then
       --             copy all elements from Source set to Target set.

        Copy_Of_Source : Set'Class := Source;
        Element : Element_Type;
     begin
        Target := Empty;  -- Dispatching for Empty determined by Target'Tag.

        while Copy_Of_Source /= Empty loop
                       -- Dispatching for Empty based on Copy_Of_Source'Tag

            Remove_Element(Copy_Of_Source, Element);

            Target := Union(Target, Unit_Set(Element));
                       -- Dispatching for Unit_Set based on Target'Tag
        end loop;
     end Convert;

The functions Unit_Set and Empty are essentially "constructors" and 
hence must be overridden in every extension of the abstract type Set. 
However, these operations can still be called with a class-wide 
expected type, and the controlling tag for the function calls will be 
determined at run-time by the context, analogous to the kind of 
(compile-time) overload resolution that uses context to disambiguate 
enumeration literals and aggregates.

(Tucker Taft)

Question:
What is the "Beaujolais Effect"?

Answer:
The term "Beaujolais Effect" comes from a prize (a bottle of 
Beaujolais) offered by Jean Ichbiah during the original Ada design 
process to anyone who could find a situation where adding or removing a 
single "use" clause could change a program from one legal 
interpretation to a different legal interpretation. (Or equivalently, 
adding or removing a single declaration from a "use"d package.)

At least one bottle was awarded, and if the offer was still open, a few 
more might have been awarded during the Ada 9X process. However, thanks 
to some very nice analysis by the Ada 9X Language Precision Team (based 
at Odyssey Research Associates) we were able to identify the remaining 
cases of this effect in Ada 83, and remove them as part of the 9X 
process.

The existing cases in Ada 83 had to do with implicit conversion of 
expressions of a universal type to a non-universal type. The rules in 
Ada 95 are subtly different, making any case that used to result in a 
Beaujolais effect in Ada 83, illegal (due to ambiguity) in Ada 95.

The Beaujolais effect is considered "harmful" because it is expected 
that during maintenance, declarations may be added or removed from 
packages without being able to do an exhaustive search for all places 
where the package is "use"d. If there were situations in the language 
which resulted in Beaujolais effects, then certain kinds of changes in 
"use"d packages might have mysterious effects in unexpected places.

(Tucker Taft)

Question:
What about the "Ripple Effect"?

Answer:
We have eliminated all remnants of the Beaujolais Effect, but we did 
debate various instances of the "Ripple" effect during the language 
revision process (apologies to Gallo Ripple Wine enthusiasts ;-).

In brief, the (undesirable) Ripple effect was related to whether the 
legality of a compilation unit could be affected by adding or removing 
an otherwise unneeded "with" clause on some compilation unit on which 
the unit depended, directly or indirectly.

This issue came up at least twice. One when we were considering rules 
relating to use of attributes like 'Address. In Ada 83 as interpreted 
by the ARG, if a compilation unit contains a use of 'Address, then 
there must be a "with" of package System somewhere in the set of 
library unit specs "with"ed by the compilation unit (directly or 
indirectly).

In Ada 95, we have eliminated this rule, as it was for some compilers 
an unnecessary implementation burden, and didn't really provide any 
value to the user (if anything, it created some confusion). The rule 
now is that the use of an attibute that returns a value of some 
particular type makes the compilation unit semantically dependent on 
the library unit in which the type is declared (whether or not it is 
"with"ed).

The second place the Ripple effect came up was when we were trying to 
provide automatic direct visibility to (primitive) operators. 
Ultimately we ended up with an explicit "use type" clause for making 
operators directly visible. For a while we considered various rules 
that would make all primitive operators directly visible; some of the 
rules considered created the undesirable "Ripple" effects; others 
created annoying incompatibilities; all were quite tricky to implement 
correctly and efficiently.

(Tucker Taft)

-----------------------------------------------------------------------------

Category:
AdaPower.com

-----------------------------------------------------------------------------

Question:
Who runs AdaPower.com?

Answer:
AdaPower.com is run by David Botton and other members of the 
admin-list@adapower.com.

Question:
Can I help with AdaPower.com?

Answer:
YES! Send a message with subscribe in the subject to admin-list@adapower.com

Question:
How do I submit articles, packages for reuse, example code, tutorials, 
FAQs, links, etc. to AdaPower.com?

Answer:
We are working on an automated submission system, but for now just 
e-mail your submission directly to David@Botton.com

Question:
When did AdaPower start?

Answer:
AdaPower started in 1998 as the Ada Source Code Treasury off of David 
Botton's home page. It has since grown to be the most frequented Ada 
site on the internet. It is home to hundreds of articles, code 
snippets, and anything else that is Ada!

Question:
What is AdaPower.com?

Answer:
AdaPower.com is a repository of information, links to resources, source 
code examples and packages for reuse. AdaPower.com can be be divided in 
to the following sections:
Articles and Links
     - Articles and Links to Ada Related Topics, Ada learning materials, and
        people in the Ada on-line community

The Ada Source Code Treasury
    - Source code examples of using Ada and Ada related bindings and tools
        for both beginner and advanced students of Ada

Packages for Reuse
    - An extensive repository of categorically arranged packages for download
        and links to packages available for reuse on the internet

Ada Projects and AdaPower.net
    - Listings and hosting for Active Ada projects on the net


-----------------------------------------------------------------------------

Category:
comp.lang.ada

-----------------------------------------------------------------------------

Question:
Is it acceptable to post job openings to this newsgroup?

Answer:
Yes, it is considered acceptable to post job openings, as long as the 
following rules are followed:

The job openings have to list Ada as a required or desired skill.
The job openings cannot have been previously posted in the last month.
(T.E.D)

-----------------------------------------------------------------------------

Category:
Learning Ada

-----------------------------------------------------------------------------

Question:
Are there any Ada books on-line?

Answer:
Yes, see the on-line list of Ada books on AdaPower.com

Question:
Is there a review of Ada books?

Answer:
Yes, see Mike Feldman's Review of Ada Books

Question:
Where can I find the Ada reference manual and standards?

Answer:
See, AdaPower: Ada - Reference

Question:
Where can I learn about Ada?

Answer:
See, AdaPower: Ada - Learn for a References, Books and Tutorials

Question:
Where can I find sample Ada code?

Answer:
See, The Ada Source Code Treasury

-----------------------------------------------------------------------------

Category:
TEAM-ADA

-----------------------------------------------------------------------------

Question:
What is TEAM-ADA?

Answer:
TEAM-ADA is an informal group (any one can join by just signing up for 
the mailing list) for Ada Advocacy.

Question:
How do I join TEAM-ADA?

Answer:
Send an e-mail with the word subscribe in the body and no subject to 
team-ada@acm.org

Re: Offical Ada FAQ

[Rod Chapman]

David Botton <david@botton.com> wrote in message news:<2004112423222516807%david@bottoncom>...
> The Official Ada FAQ...

I think a whole section of FAQs about SPARK would be very useful...
we'll try to come up with some soon!
 - Rod

Re: Offical Ada FAQ

[Ching Bon Lam]

> Question:
> Is there a version of Ada for Windows?
> 
> Answer:
> Yes
> 
> There is a free as in liberty and beer Win32 compiler available from 
> http://libre.act-europe.fr/GNAT/.
> 
> A supported version of that compiler is available from AdaCore 
> Technologies at http://www.gnat.com
> 
> A Visual Studio Style produce called ObjectAda is available from Aonix
> 
> RR Software sells Janus/Ada along with CLAW a think binding to Windows
> and a CLAW GUI builder.

There is also a GCC 3.4.2 ada compiler available at www.mingw.com which 
works under windows.

CBL

Re: Offical Ada FAQ

[Manuel Collado]

Ching Bon Lam wrote:

>>Question:
>>Is there a version of Ada for Windows?
>>
>>Answer:
>>Yes
>>
>>There is a free as in liberty and beer Win32 compiler available from 
>>http://libre.act-europe.fr/GNAT/.
>>
>>A supported version of that compiler is available from AdaCore 
>>Technologies at http://www.gnat.com
>>
>>A Visual Studio Style produce called ObjectAda is available from Aonix
>>
>>RR Software sells Janus/Ada along with CLAW a think binding to Windows
>>and a CLAW GUI builder.
> 
> There is also a GCC 3.4.2 ada compiler available at www.mingw.com which 
> works under windows.

GCC/Ada has also been ported to:

Windows:      Cygwin    http://cygwin.com/              version 3.4.1
DOS/Windows:  DJGPP     http://www.delorie.com/djgpp/   version 3.4.3

-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado

Re: Offical Ada FAQ

[Georg Bauhaus]

David Botton <david@botton.com> wrote:
: Question:
: Is there a version of Linux for IBM OS/2 Warp?
 
Is there an Ada compiler (not: Linux) for IBM OS/2 Warp?

Re: Offical Ada FAQ

[David Botton]

Ok, I've added www.mingw.org, www.mingw.com is in chinese and it 
doesn't seem to be talking about  GCC, GNAT or Ada :-)

David Botton


On 2004-11-25 08:07:11 -0500, Ching Bon Lam <hmm@hmm.hmmm> said:
> 
> There is also a GCC 3.4.2 ada compiler available at www.mingw.com which 
> works under windows.

Re: Offical Ada FAQ

[David Botton]

On 2004-11-25 09:05:50 -0500, Manuel Collado <m.collado@lml.ls.fi.upm.es> said:
> GCC/Ada has also been ported to:
> 
> Windows:      Cygwin    http://cygwin.com/              version 3.4.1
> DOS/Windows:  DJGPP     http://www.delorie.com/djgpp/   version 3.4.3

As Ada is not mentioned on these sites, have you confirmed that they 
are in fact compiling in Ada. If so, I'll add the links with a mention 
that "its in there!"

David Botton

Re: Offical Ada FAQ

[Martin Krischik]

Georg Bauhaus wrote:

> David Botton <david@botton.com> wrote:
> : Question:
> : Is there a version of Linux for IBM OS/2 Warp?
>  
> Is there an Ada compiler (not: Linux) for IBM OS/2 Warp?

GNAT is available in release 3.15p for OS/2. I have used it myself and it is
quite good.

See
ftp://cs.nyu.edu/pub/gnat/3.15p/contrib/os2/gnat-3.15p-os2-bin-20021124.zip

With Regards

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

Re: Offical Ada FAQ

[Martin Krischik]

David Botton wrote:

> On 2004-11-25 09:05:50 -0500, Manuel Collado <m.collado@lml.ls.fi.upm.es>
> said:
>> GCC/Ada has also been ported to:
>> 
>> Windows:      Cygwin    http://cygwin.com/              version 3.4.1

I can confirm that Cygwin has at least version 3.3.3. I have also compiled a
3.4.2 with Cygwin myself using the 3.3.3. That confirms that Cygwin has a
compiler which can bootstrap a newer version. However, I know that the
Cygwin compiler has no DLL support and rumor has it that threads won't work
either.

With Regards

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

Re: Offical Ada FAQ

[David Botton]

On 2004-11-25 11:14:02 -0500, Martin Krischik <martin@krischik.com> said:

> ftp://cs.nyu.edu/pub/gnat/3.15p/contrib/os2/gnat-3.15p-os2-bin-20021124.zip

Added

Re: Offical Ada FAQ

[David Botton]

On 2004-11-25 09:31:59 -0500, Georg Bauhaus 
<sb463ba@l1-hrz.uni-duisburg.de> said:

> David Botton <david@botton.com> wrote:
> : Question:
> : Is there a version of Linux for IBM OS/2 Warp?
>  Is there an Ada compiler (not: Linux) for IBM OS/2 Warp?

Corrected.

David Botton

Re: Offical Ada FAQ

[Jeffrey Carter]

Too bad the history part doesn't mention MIL-STD-1815 (Ada 80), 1980 Dec 10.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: Offical Ada FAQ

[David Botton]

On 2004-11-25 15:20:14 -0500, Jeffrey Carter <spam@spam.com> said:

> Too bad the history part doesn't mention MIL-STD-1815 (Ada 80), 1980 Dec 10.

It could, send me the text ;-)

David Botton

Re: Offical Ada FAQ

[Brian May]

>>>>> "David" == David Botton <david@botton.com> writes:

    David> Strong typing can be carried too far, and some amount of
    David> implicit conversion is essential to make OOP palatable. But
    David> note that in Ada 95, even with OOP, we don't allow implicit
    David> conversions that truncate the extension part of a record
    David> (this is a relatively common mistake in C++ when passing
    David> parameters by value).

I would be curious to know more about this common mistake in C++...

    David> Question: Why doesn't Ada use 'dot' notation for OO?

Suggestion: Add reference to how this will change in Ada 2005.

    David> Question: Are classes first class objects?

Suggestion: Add definition of what is a "first class object".

    David> Question: Can you access super methods?

    David> Answer: Do you mean "call the operation of the type's
    David> parent"?

    David> The answer is yes, by converting the object to the parent
    David> type, and then invoking the operation.

Does this work with both "in", "in out" and "out" parameters?

For out parameters, what happens if the derived type has extra fields
not in the parent? Is this legal? If it is legal are the extra fields
defined?

    David> Question: How do I print an Integer, Float, enumeral using
    David> Text_IO or otherwise obtain a string representation of a
    David> scalar type?

The built in methods for integers may not always be sufficient. For
example, if you want to print 0001 (integer) or 01.0100
(float). References to a package that can meet these extended
requirements might be a good idea...

    David> Question: Does Ada have an XML parser?

    David> Answer: There are a few Ada XML parsers available.

    David> See http://www.adapower.com/reuse

    David> On Windows, you can also use the MSXML COM object via
    David> GNATCOM

Why not xmlada? http://libre.act-europe.fr/xmlada/

    David> Question: Does Ada have multiple inheritance?

I think Ada 2005 was going to add an "interface" mechanism which will
add another way of doing this.

    David> Question: Can I create Web Services and SOAP objects with
    David> Ada?

    David> Answer: Yes, see AWS

Would a reference to writing Ada CGI scripts be useful here?

    David> Question: Can I use CORBA with Ada?

    David> Answer: Yes, see AdaPower.com: Ada Libraries: Distributed
    David> Computing

Or Glade: http://libre.act-europe.fr/glade/
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Offical Ada FAQ

[David Botton]

There are numerous packages that do XML, Corba, etc. The link listed 
contains them all.

David Botton



On 2004-11-25 17:13:41 -0500, Brian May <bam@snoopy.apana.org.au> said:
> 
> Why not xmlada? http://libre.act-europe.fr/xmlada/

> Or Glade: http://libre.act-europe.fr/glade/

Re: Offical Ada FAQ

[Dmitry A. Kazakov]

On Fri, 26 Nov 2004 09:13:41 +1100, Brian May wrote:

>>>>>> "David" == David Botton <david@botton.com> writes:
> 
>     David> Strong typing can be carried too far, and some amount of
>     David> implicit conversion is essential to make OOP palatable. But
>     David> note that in Ada 95, even with OOP, we don't allow implicit
>     David> conversions that truncate the extension part of a record
>     David> (this is a relatively common mistake in C++ when passing
>     David> parameters by value).
> 
> I would be curious to know more about this common mistake in C++...

Perhaps David meant:

class A
{
public :
   int Field1;
};

void Foo (A X);

class B : public A
{
public :
   int Field2;
};

void Foo (A X)
{   
   printf ("%i", ((B*) &X)->Field2); // Surprise, surprise
}

int main ()
{
   B  Baz;

   Baz.Field2 = 123;
   Foo (Baz); // Prints garbage or crashes
   return 0;
}

But the above is NOT a mistake. It is absolutely correct behavior! The
actual error is an attempt to cast to B something what is not B. Should Ada
allow by-value parameter passing for some of tagged types (why not), the
effect would be exactly the same: truncating extra members. The only
difference to C++ would be that [view] conversion to B or B'Class would
raise Constraint_Error, while C++ cast swallows anything told.

> Does this work with both "in", "in out" and "out" parameters?
> 
> For out parameters, what happens if the derived type has extra fields
> not in the parent? Is this legal? If it is legal are the extra fields
> defined?

It is just view conversions. The tag of a tagged "out" parameter is set
before the call, so it is legal and safe (up to Constraint_Error).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Offical Ada FAQ

[Manuel Collado]

David Botton wrote:
> On 2004-11-25 09:05:50 -0500, Manuel Collado 
> <m.collado@lml.ls.fi.upm.es> said:
> 
>> GCC/Ada has also been ported to:
>>
>> Windows:      Cygwin    http://cygwin.com/              version 3.4.1
>> DOS/Windows:  DJGPP     http://www.delorie.com/djgpp/   version 3.4.3
> 
> As Ada is not mentioned on these sites, have you confirmed that they are 
> in fact compiling in Ada. If so, I'll add the links with a mention that 
> "its in there!"

Cygwin/DJGPP are Windows/MS-DOS ports (respectively) of a comprehensive 
set of GNU packages, including the whole gcc toolchain (that now 
includes Ada). I've not tested if they support all features (say tasks, 
as MS-DOS lacks multitasking support), but they certainly allow 
compilation of conventional, console-based Ada programs, at least.

Regards,
-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado