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

[John G. Volan <John_Volan@ccmail.dayton.saic.com>]

In article <Dp3G4u.KEA@world.std.com> Robert A Duff, bobduff@world.std.com
writes:
>In article <4jhe1v$m0g@dayuc.dayton.saic.com>,
>John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>>A C programmer would complain about having to introduce an extra
>>begin/end block in order to introduce variables.  Isn't the scope
>>of a variable well-defined in C, even without this extra baggage?
>>It just extends from the declaration to the end of whatever block
>>you're already in.
>
>Well, at least one Ada programmer (namely, me) would agree with the C
>programmer in this case.
>
>>An Ada programmer would counter that, in Ada, some variables might be
>>instances of _task_ types. ...
>
>Sorry to keep disagreeing with you, John, ...

Don't be.  Keeps things interesting! :-)

>...but this seems like the tail
>wagging the dog.  If the reason I'm required to add 3 extra junk lines
>of code, just to declare a simple variable, is because of tasks, then
>that's just poor language design.  If you need a place to activate the
>tasks, fine, put in an "Activate_Tasks_Here" statement.  Don't
>complicate the job for some poor guy who has no tasks, and just wants to
>declare an Integer or String variable.

Okay, maybe the tasking issue was a bit of a stretch.  With respect to
tasks, I still feel that it's important to be able to distinguish the
difference between elaboration and execution, but I agree that this
doesn't give us a _comprehensive_ rationale for for Ada's strict rules
separating declarations from statements.

Okay, then, can anybody who was in on the Ada83/Ada95 design process
give us a more comprehensive rationale for this strict separation, one
consequence of which being the need for declare statements?  Warning: It
may not be sufficient to say that we need the blocks in order to define
the scope of the declarations, since as I pointed out, it might be
possible to come up with a coherent definition of the scope of a
declaration even with C's scheme (C manages it somehow, after all).

One difficulty I see with intermingling declarations and statements is
how to interpret declarations within conditional or iterative constructs.
For instance:

    -- This is NOT Ada, this is CRAPOLA (C-Reminiscent Ada-like Perversion
    -- Of Language Aspects)  :-) :
    begin
        ...
        if Smaller then
            X : Integer;
            ...
        elsif Bigger then
            X : Long_Integer;
            ...
        end if;
        ...
        -- is X in scope here, and if so, what the heck is it?
        ...
        
        ... loop
            Y : Integer;
            Get (Y);
            type A is array (1 .. Y) of Integer;
            package P is new Generic_P (A);
            -- do these things get elaborated & destroyed every iteration?
            ...
        end loop ... ;
        ...
        -- are Y, A, and P still in scope here?
    end ... ;
    

I assume that the only thing that would make sense would be to treat
every structured statement as the moral equivalent of a begin/end.
So wherever Ada has a sequence_of_statements, CRAPOLA would have a 
"block", in which statements and declarations can be intermingled,
but the scope of the declarations would be limited to that "block".
So the two X's above would only be in scope within their respective
then-parts, and Y, A, and P would only be in scope for one iteration
of the loop (i.e., they'd be created and destroyed with each iteration).

(I may not be able to follow up for a while folks, going on travel
tomorrow ... hey, don't everybody cheer at once! :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------