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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!inmet!stt From: stt@inmet.inmet.com Newsgroups: comp.lang.ada Subject: Re: Last Ada Diatribe for 90 Message-ID: <20600038@inmet> Date: 21 Mar 90 14:54:00 GMT References: <19480@grebyn.com> Nf-ID: #R:grebyn.com:19480:inmet:20600038:000:6710 Nf-From: inmet.inmet.com!stt Mar 21 09:54:00 1990 List-Id: In response to Ted Holden's "Last Diatribe": I am reluctant to respond since I would hate to cause Ted to violate his promise, but I felt a little bit of fairness was in order. Ada9X is intentionally a very open process, and encourages the reporting of all gripes, both serious and frivolous, about Ada83. This will certainly result in a lot of dirty laundry if there was a desire to claim that Ada83 was spotless. However, the point of Ada9X is precisely to address the problems, not to hide them. I am sure if you were to look inside the ANSI C standardization effort, you would have found large numbers of perceived problems with K&R C, and a standardization committee which did its level best to address as many as them as was practical. Similarly, the ANSI C++ standardization effort is just beginning, and it is destined to be a very interesting, heated, and hopefully productive process, with lots of dirty laundry, etc. Ada83 took a different approach from C and C++. It attempted to both break new ground from a language design and integration point of view, and rigorously standardize prior to a period of industry use. Languages which didn't standardize during their first years of use continuously evolved to address the gripes, meaning that presumably fewer gripes accumulated. Certainly C++ over the past few years has been a moving target. There were both good and bad reasons (in retrospect) for the early standardization approach of Ada83. Nevertheless, we are now at the stage of rounding up all of the big and little gripes which have accumulated during the past 8 years or so, and there are admittedly a lot of them, partly because the language has been rigidly standardized during this period of initial use. Of course, we didn't specifically ask for the list of good things about Ada, things which make it better for large-system development, for embedded-system development, for C3I development, for man-critical systems, etc., when compared to other widely available languages. We actually did receive a few unsolicited requests like "please don't change this, I like it the way it is". But by and large, most requests came from people who seriously want to continue using Ada rather than some other language, but have run into some problem or other which they would ideally like to see fixed. Just for reference, here are a few of the things which Ada83 tried to integrate into a single language. If you were to compare C, Pascal, etc. of 1980 with where languages are now, you will find that many of the ideas promoted by Ada83 have since been incorporated into C, C++, Modula-2, Concurrent C, etc, or are now being considered. Some of this was parallel evolution. Other changes in these languages were based directly on lessons from Ada's successes and problems. So here's the list: 1) Strong type checking across separate compilation, with a persistent program library structure. 2) User-defined data abstractions (private types) 3) Generic package/subprogram templates 4) Exception handling 5) Multi-tasking within the language 6) Synchronization primitives within the language 7) Inlined subprograms 8) Explicit separation between logical data structure definition and physical data representation definition 9) "Safe" pointers, with multiple heaps. 10) Complete array bounds checking, null pointer checking, scalar range checking, access-before-initialization checking, function-return-without- a-value checking, etc., carefully specified as part of the language definition. The net effect of all of these language features is that Ada is an excellent language for the building of large systems, providing excellent interface definition and control, and catching many errors at compile-time, and most remaining errors at run-time very close to the point of the defect. However, the size and sophistication of the language posed more problems for compiler-writers than was originally anticipated. In retrospect, the "let the compiler do it" and/or "just throw fancier instruction sets / more horsepower at the problem" attitudes had perhaps been taken too far (remember CISC was still king in the early 80's). We now know RISC is king, and small and fast is better than big and fancy. However, there is no denying by anyone who has used Ada, that its features do make interface control and debugging much much easier. Ada programmers don't want to return to the arbitrary address arithmetic of C, nor its single-level global name space. Watching the evolution of C++ is highly instructive, as it tries to incorporate exceptions, generics, concurrency, etc. It will be a real struggle to fit C++ 3.0 on an old-style PC. The challenge for the designers of Ada9X is to retain the existing features of Ada83, while achieving better run-time and compile-time efficiency. We believe this is possible by "simplifying through extension" and providing a small but complete set of additional safe low-level primitives. Simplifying through extension means removing special cases and limitations in the language, and unifying the capabilities so that all reasonable operations are applicable to all reasonable objects. This has the potential for both simplifying the compiler, and making the language more flexible for the programmer. Providing a small, complete set of safe low-level primitives may require no more than a carefully designed set of standard packages, with minimal additional linguistic support. "Safe" means that the new primitives should avoid introducing situations where random memory can be clobbered, or other "erroneous" unpredictable behaviour can occur. Ada83 is excellent at "damage control", where a bug in a program is detected at or very near its occurrence, before propagating failures to other parts of the program. Any new set of low-level primitives should preserve this important attribute. As a final point, the Ada9X process is attempting to address the compiler availability issue from the very beginning. There will be about three funded user/implementor teams, which will be paid to evaluate and implement the language changes as they are proposed. In addition, we anticipate structuring the changes so that those which address the most critical problems will be implemented first, as an incremental change to existing compilers, rather than as a major rewrite. This should mean that these most critical fixes will be available, at least for trial use, within the next few years. The more forward-looking changes may not be available until later, but presumably these are less critical today. S. Tucker Taft stt@inmet.inmet.com Ada9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138