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

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <dewar.828333135@schonberg>, dewar@cs.nyu.edu (Robert Dewar)
writes: 
|> The trouble with mixing declarations and statements is that it blurs
|> the lines beween elaboration and execution,

These lines are already blurred in Ada, because elaboration takes place
at run time, when the flow of control reaches a declaration.  Indeed,
RM95 3.1(11) says, "The process by which a cosntruct achieves its
run-time effect is called _execution_.  One of the terms execution,
elaboration, or evaluation is defined by this International Standard for
each construct that has a run-time effect." In other words, elaboration
is one kind of execution.  There was no such passage in RM83, resulting
in the need for such circumlocutions as "The foregoing is expressed in
terms of the process that is called execution; it applies equally to the
processes that are called evaluation and elaboration" (RM83 1.6(9)).

|>                                             and can result in considerable
|> semantic confusion. Where for example would tasks be activated, and
|> what does
|>
|>   if x then a : integer; ....
|>
|> Yes, this can be given a meaning, but I don't think it is worth the
|> effort.

Rather than allowing an aribtrary interleaving of declarations and
statements as in C++, we can simply replace the rule

   sequence_of_statements ::= statement {statement}

with

   sequence_of_statements ::=
      {declarative_item} statement {statement}

and add the rule that the execution of a sequence of statements consists
of the elaboration of its declarative part followed by the execution of
its statements.  In other words,

   if P then
      X: constant Integer := ...;
      ...
      Y := X;
   else
      X: constant Integer := ...;
      ...
      Z:= X;
   end if;

becomes just a lightweight equivalent of

   if P then
      declare
         X: constant Integer := ...;
      begin
         ...
         Y := X;
      end
   else
      declare
         X: constant Integer := ...;
      begin
         ...
         Z:= X;
      end;
   end if;

(Note that if you want exception handlers inside the if statement, an
explicit block statement is still required.)

|>         Having programmed in Algol-68 a lot, this is one A68 feature
|> I can do without.

Actually, this is one aspect of C that I actually LIKE.  I always use {
and } brackets for my C compound statements to avoid accidently changing

   if (P)
      w = x;

to

   if (P)
      w = x;
      y = z;    /* Oh, dear.  Fooled by the indentation */

later.  Thus, at no extra notational cost, if a variable is to be used
only within one branch of an if statement, for example, I can declare it
locally to that if statement.  Besides making the code more readable by
bringing declarations textually closer to statements that use them, this
makes it much easier to move chunks of code around, e.g. to move part of
one function definition that has grown too large into a function
definition of its own, because a chunk of text becomes more independent
of the surrounding context.

I don't find myself doing the same thing (with block statements) in Ada
because the notation is too heavy (especially when set in bolface ;-) ).
For me at least, the lack of a shorthand equivalent is a psychological
barrier to localizing declarations.  I believe that if the shorthand were
allowed, many programmers would write more readable Ada code.

--
Norman H. Cohen    ncohen@watson.ibm.com