From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FILL_THIS_FORM, FILL_THIS_FORM_FRAUD_PHISH,LOTS_OF_MONEY,MONEY_FORM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7833d36bbd0d6fcd,start X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!solaris.cc.vt.edu!news.vt.edu!news-out.cwix.com!newsfeed.cwix.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 24 Nov 2004 22:22:24 -0600 From: David Botton Newsgroups: comp.lang.ada Date: Wed, 24 Nov 2004 23:22:25 -0500 Message-ID: <2004112423222516807%david@bottoncom> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Offical Ada FAQ User-Agent: Unison/1.5.2 NNTP-Posting-Host: 66.176.74.83 X-Trace: sv3-ZHcXmVEfKczqnPeBdKrhp6+B22k4zUEdfT0+QDkPzoTuFbP5PCJNVi4Z9L/z0eIPB9ZmxXXEZJF8nIR!JLLtWQbzqIqGIhg/iaJ6PC+fVs8CkSc4Rxcb540L3LZNej5nyjFoyc8VqgkP8g== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.20 Xref: g2news1.google.com comp.lang.ada:6447 Date: 2004-11-24T23:22:25-05:00 List-Id: 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