Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar <dewar@gnat.com>]

In article <8bs49i$baq1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> On Wed, 29 Mar 2000 05:39:20 GMT, jross
<rem.jross@rem.codemecca.com> 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.