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.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1ea19776e3073a96 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: C/C++ programmer giving Ada95 a chance -- writing an emulator. Date: 2000/03/29 Message-ID: <8bsm6k$ejp$1@nnrp1.deja.com> X-Deja-AN: 603797700 References: <38e148e2.5089627@news.shreve.net> <38e19656.17008608@news.shreve.net> <8bs49i$baq1@news.cis.okstate.edu> X-Http-Proxy: 1.0 x33.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Wed Mar 29 10:33:56 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-03-29T00:00:00+00:00 List-Id: In article <8bs49i$baq1@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > On Wed, 29 Mar 2000 05:39:20 GMT, jross wrote: > >values. Actually the entire array can be a constant (don't know if > >that would help with optimizing the compiled code). > > >Just a note about the RM95 -- who wrote this stuff? My head > >hurts reading this!!! Ouch! :) > > You do realize probably half the authors of the RM95 are > reading this > message? :-) Honestly, I've found the RM95 pretty easy reading > compared to some of the other standards I've tried to read. > (ISO 7185: Basic Pascal comes to mind as a fairly painful > standard.) The important thing to understand is that the RM is a language definition, NOT a text book. Almost no one could learn the language from the RM, and no one is expected to. You do not read the RM until you know the language, that is what the "reference" in the title means. Now there are sections which are more accessible than others, e.g. Annex A is straightforward and can be used as a text book for the standard library. But you cannot expect to read much of the body of the RM without a thorough understanding of Ada. There is always a trade off in a language standard between readability/accessibility and precision. Many standards are FAR harder to read than the Ada standard, e.g. the PL/1 standard, or the Algol-68 revised report, the latter being a fully formal definition, which you have to be a skilled mathematician to read. The original Ada 83 report was designed to be as readable as possible while still meeting the fundamental requirements for precision. It was a success and a failure depending on your point of view: a) it was a success because for the first time since Algol-60, ordinary practicing programmers read the language Standard. (by comparison, virtually no C, C++, or COBOL programmers have a copy of the standard or have read it, and of course there does not even exist a standard for Java, or Visual Basic or Delphi). b) it was a failure in the view of some (not me) because it was not felt to be formal enough and precise enough. There was a very concious effort in Ada 95 to make the document more precise, even if at the expense of readability and accessibility. The result is that the Ada 95 document is indeed more precise, but it is also MUCH harder to read (at least I think so, and I am one of the people who can read the RM for the most part). What's the right balance? Well I prefer the Ada 83 RM, but obviously the authors, and many of the reviewers prefer the Ada 95 RM style. In any case, both the Ada 83 and Ada 95 RM are far superior to other standards, since for both languages it is normal practice for working programmers to have a copy of the RM accessible on paper or electronically (*) and to refer to it at least occasionally as a reference document. This is still not achieved with other languages. So the difference in style between 83 and 95 is minor here if we start comparing with other standards for other languages. Why do standards/definitions of languages tend to be hard to read compared to a text book. Among the reasons are: 1. Redundancy (saying the same thing more than one way) is a friend in a text book, but an enemy in a definition (in a definition it is unnecessary, and risky, because you might not say exactly the same thing each time). 2. Exploring consequences is a friend in a text book, but an enemy in a definition. What I mean here is that if you state a set of rules, and it is possible to deduce a consequential rule from these rules, then a standard does NOT need to state this consequential rule even if it is non-obvious. Again, stating it is redundant, and unnecessary. But in a text, exploring non-obvious (but often useful) consequences of rules is a very important aspect. 3. Examples and notes are just examples of redundancy, they have no place in a definition. An example is either right, in which case it tells you nothing, or wrong, in which case it is damaging. On the other hand, examples are of the essence in text books because many people like to learn by example. 4. A definition must cover 100% of the language, including highly obscure cases that no one is interested in. A text book can simplify by stating rules in a way that is not formally 100% correct, but is in practice good enough for everyone actually using the language, and thus simplify the presentation. The RM does of course have notes and examples, but they are NOT part of the definition of the language. I personally think they have no place in the RM, because I don't like learning from examples (I am one of the peculiar people who learned most languages from their reference manuals, including COBOL and Algol-68), but I recognize that people do find the examples useful. Just remember never to cite them in arguments about what the standard says. As a specific example, a typical text book for Ada will tell you explicitly when discussing FOR loops that you cannot modify the loop variable, and that is a useful rule for beginners, stated in that form. But in the definition of Ada in the RM, you will find no such rule, since it is not necessary. Why? Because in chapter 3, the definition of a "constant" includes the FOR loop entity, and other rules make it clear that you cannot modify constants. None of these rules is anywhere near the loop statement description itself. Now in this particular case, I suggested a note (right, I don't like notes, but I understand why others do), and that note can now be found in the section on loops: 10 (6) A loop parameter is a constant; it cannot be updated within the sequence_of_statements of the loop (see 3.3). But this note is not part of the definition and is entirely redundant. What would be useful to many people is an annotated version of the RM that explains what each section means in simpler terms with more examples and notes. There was a very nice version of the Fortran standard printed in large format with the standard in small print giving giant margins used for explanations and comments. The AARM (Annotated Ada Reference Manual) that exists now has some explanatory material that is at this level, but mostly is at a very different level, exploring detailed implementation consequences and weird cases that lead to various decisions. The Rationale also has some of this material, but not keyed to the RM paragraph by paragraph. However, these two documents are very useful adjunct reading, and if you don't understand something in the RM, seeing if there are AARM annotations is always a useful check. By the way, it is the lack of accessibility of the RM that makes it inadvisable in our view to put RM references in all error messages. Most of the time such RM references either lead you to sections that simply restate the rule stated in the error message, or to incomprehensible sections of the RM that will indeed make your head ache. We only put RM references in when we think they are genuinely useful (which is quite a few situations, but most ordinary error messages do not have RM references for very good reasons). Interestingly, when we have discussed the issue of RM references in GNAT error messages, most people strongly in favor of the idea base their views on experience with Ada 83 compilers and the Ada 83 RM, but that was, as I mentioned above, a much more accessible document. Even more interestingly, when we have discussed this issue, I always suggest that people give examples of messages where an RM reference would help, and that always seems to strangely end the thread :-) Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy.