From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,92c39a3be0a7f17d
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-03-15 08:00:04 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsfeed0.news.atl.earthlink.net!news.atl.earthlink.net!news.mindspring.net!not-for-mail
From: Richard Riehle <richard@adaworks.com>
Newsgroups: comp.lang.ada
Subject: Re: labeling (was: partitioning (was: Future))
Date: Fri, 15 Mar 2002 08:07:12 -0800
Organization: AdaWorks Software Engineering
Message-ID: <3C921C30.F5FF9CBF@adaworks.com>
References: <mailman.1016027822.21009.comp.lang.ada@ada.eu.org>
Reply-To: richard@adaworks.com
NNTP-Posting-Host: 9e.fc.c5.50
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Server-Date: 15 Mar 2002 15:59:19 GMT
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
Xref: archiver1.google.com comp.lang.ada:21290
Date: 2002-03-15T15:59:19+00:00
List-Id: <comp.lang.ada>

In my original comment about the value of labels for
many Ada constructs, I did not anticipate the many
variations on the theme that might be concocted.

My comments were a complaint that curly braces in
the C family of languages would be more useful if they
permitted scope delimiting labels that could be checked
by the compiler.    We wouldn't need these everywhere,
only where they would add clarity.

Ada already provides this feature for adding clarity.
And we can insert it anywhere we wish in long blocks
of code (not that I am recommending long blocks of code).
It is nice that the labels are checked by the compiler as
well as improving readability by humans, programmers
included.

I really don't think it is necessary to add new labeling
features to the language for selection statements, as
some have suggested.   For me, end case and end if
are quite enough.

However, it is sometimes useful to create a begin..end
block with a label for especially long constructs.   For
example,

        case X is
             when Sigma => Sigma_Process:
                                       begin
                                            sequence-of-statements
                                       end Sigma_Process;
            when Theta =>  Theta_Process:
                                      begin
                                           handled-sequence-of-statements
                                      exception
                                           sequence-of-statements
                                      end Theta_Process;
        end case;

If it is a really long case statement, the case statement can
be wrapped in a labeled begin..end block.

However, I don't favor this for compilers that support pragma
inline well.   Instead, the above code can be made more effective
by promoting it to a private child package, or enclosing the long
begin..end statements into nested inlined procedures.  Even the
case statement itself can be promoted to an inlined procedure.

        procedure P is
             -- local declarations
             procedure Theta_Process is ... begin ... end Theta_Process;
             pragma Inline(Theta_Process);
             procedure Sigma_Process is ... begin ... end Sigma_Process;
             pragma Inline(Sigma_Process);
             -- more declarations
       begin
            case X is
                when Sigma => Sigma_Process;
                when Theta =>  Theta_Process;
            end case;
      end P;