Re: some questions re. Ada/GNAT from a C++/GCC user

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <Dp6y67.MI9@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

  > No, I'm absolutely serious.  No joke.  I really do think the extra
  > verbosity damages readability, and there's "no good reason" for it.
  > Don't get me wrong -- I don't think is really a big deal.
  
   There is "good reason" for it, and it was well thought out.
However, this discussion has tended to focus on the exceptions,
rather than the rule.

   When Ada 83 was being standardized, one quick measure of how good
your programming style was was to measure the ratio of statements to
subprogram declarations.  Anything over 20 was bad, and I think the
original ROLM Ada compiler weighed in at nine.

   Given this and that the "innermost enclosing scope" for
significantly more than fifty percent of the source was expected to be
a declarative part, not a sequence of statements, it made sense to
collect all of the (rare) statements in one place.  The only
declarations allowed to be mixed with statements were the implicit
declarations of statement labels, loop and block names, and loop
parameters.  (Quick, when was the last time you used a block name in
Ada?  For that matter when was the last time you used a statement
label?  I've only used two in the last fifteen years, outside of
compiler tests.)

  The Ada 83 rule which was a royal pain however, was the one that
split a declarative part into _basic_declarative_items_ and
_later_declarative_items_.  Thankfully this is gone in Ada 95.  Ever
hoist a type or variable declaration out of a body in a package body
to share it with another subprogram, and discover you have to move it
back five pages?

  > Another point: The extra verbosity also encourages people to declare
  > things up at the top of the procedure, rather than at the innermost
  > statement list in which they're used.  For example, I believe I saw a
  > post from Norman Cohen a while back, saying that (in some particular
  > example), the extra verbosity of declare/begin/end just isn't worth it.
  > That's sad, because when you move the thing up to the top, you make the
  > declaration harder to understand:

  >    - Its scope is larger, so to see how it's used, you have to read
  >	 more code.
 
  See above.  I've even used nested packages to get objects more
closely associated with the related subprograms or tasks.

  >    - In many cases, the initial value of the variable is not known at
  >	 the top of the procedure -- it's something that gets calculated
  >	 along the way.  So you have to initialize it with an assignment
  >	 statement.  That's bad, because it becomes harder to understand
  >	 whether the variable is properly initialized.

  If the initial value really isn't available at the top of the
subprogram, I will consider a separate subprogram or a declare block.
Usually it does indicate a (often minor) flaw in my design.

  >    - In many cases, making the scope bigger than it needs to be causes
  >	 the object to be a variable, rather than a constant.  Constants
  >	 are easier to understand than variables.

  I've never seen this.  Much more common in my experience is the
issue of how closely nested a variable should be.  There are times
when proper design hoists a constant to an enclosing scope, where the
constant is a variable.  When I run across this, I usually pass the
variable as a formal in parameter so that it is a constant in the
inner scope.  Unfortunately, this allows aliasing to occur, unless you
can order the declarations so that the variable is not in scope of the
inner body. ;-( Fortunately with the fix mentioned above, I can fix
this in Ada 95--it just occaisionally looks a little strange in the
code:

  package body Foo is
    ...
    procedure Bar (X: in Count; Y...) is ...end Bar;
    ...
    X: Count := 0; 
    ...
    procedure Foob is
    ...
    begin
      Bar(X,Z);
      ...
    end Foob;
    ...
  end Foo;

  > So here's a case where trying to FORCE people to write good code
  > backfires.  Norm Cohen is not some evil doer who revels in terse,
  > arcane notations!

   I agree, but I have yet to see even a minor problem.  The latter
declarative part thing was much more serious, and still not a serious
problem.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...