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

[bobduff@world.std.com (Robert A Duff)]

In article <3160E91E.1627@lfwc.lockheed.com>,
Ken Garlington  <garlingtonke@lfwc.lockheed.com> wrote:
>OK - I'll walk out onto the limb you've so kindly offered. I suspect that,
>if you find yourself creating a new scope in "real" code that has no purpose
>sufficiently cohensive as to be named, that you need to review your program
>structure.

I don't see why the desire to declare a local variable necessarily
implies that this section of code is "sufficiently cohensive as to be
named".  Here's an example:

    function Binary_Search(A: Some_Array_Type; E: Element_Type) return Boolean is
        Low: Index_Type := A'First;
        High: Index_Type := A'Last;
    begin
        while Low < High loop
            declare
                Midpoint: constant Index_Type := (Low + High) / 2;
            begin
                if A(Midpoint) = E then
                    return True;
                elsif ...
                else
                    ... -- etc.
                    -- I won't bother typing in the whole algorithm,
                    -- because then I'll be embarrassed when I get it
                    -- wrong.  ;-)
                end if;
            end;
        end loop;
        return False;
    end Binary_Search;

It doesn't seem to me that the declare block above needs a name -- it's
not that big, and its function is intimately tied to the surrounding
loop, rather than being stand-alone.

I admit that it wouldn't kill me to put Midpoint up at the top of the
procedure, but then it couldn't be a constant, which, IMHO, would damage
the readability.  No big deal, but still damage.

>(And out come the saws... :)

;-)

>True, just like it can't tell if any user-defined identifier has the meaning
>it should. I think the consistency checking alone is very useful. Consider:
>
>if ... then -- scope_1
>   ...
>   if .. then -- scope_a
>      ...
>   end if; -- scope_1
>   ...
>end if; -- scope_a
>
>Get a page/screen break in just the wrong place, and you can easily mislead
>the reader as to the structure of your program. It would be nice if Ada
>allowed the naming of if/case statements, just like loops/blocks.

Agreed.  Of course, you can always put in a block_statement if you
really want a name.  The GNAT sources often put a block_statement in
each branch of a big case_statement, purely to give a name to each
when-clause.  These block_statements often have *no* declarations and
*no* exception handlers -- they're pure syntactic sugar, which is fine.

I would like to be able to declare very-local objects without a named
scope, and without declare/begin/end.  But I agree with you -- if a name
is appropriate, it's nice to have that option as well.

>The fact that local scope naming is optional isn't relevant, in my mind.
>For that matter, putting a name on the end of most scopes is optional.
>If I'm writing a quickie example, I might not put a name on the end of
>my subprograms. But for maintainable code, I always put a name on the
>end (and a comment on the begin, for that matter.)

I actually would prefer if the name at the end of a subprogram was *not*
optional.  For quickie examples, my editor types it in automatically, so
it's not painful.  No big deal, though.

>By the way, do you have a problem with the "begin" keyword in a subprogram?
>I suppose it would also be considered unnecessary, if I understand your
>position correctly.

I'm not sure.

(Now *that's* no way to keep an argument going.  ;-) )

>... What about the "exception" keyword, either in block
>statements or subprograms?

I have no problem with the exception keyword.  To me, an exception
handler is much more of a "big deal" than a plain old variable
declaration.

However, if you look at the syntax rules for Ada 95, you'll see that the
exception handlers are *not* attached to the block,subprogram,whatever,
as they were in Ada 83.  They are attached to the statement list.  This
makes sense, since the handler applies only to exceptions raised during
the statement list.  Compare the stuff in chap 11, RM83 and RM95, and
you'll see that the description of which handler applies to what part of
the code, is somewhat simpler in RM95, because of this syntax change.
(Not really a change to the syntax, only a change to the form of the
rules.)

- Bob