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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Robert I. Eachus" <rieachus@comcast.net>
Newsgroups: comp.lang.ada
Subject: Re: Ada case-statement
Date: Wed, 14 Mar 2018 20:57:54 -0400
Organization: Aioe.org NNTP Server
Message-ID: <p8cgeh$1v7d$1@gioia.aioe.org>
References: <365d65ea-5f4b-4b6a-be9b-1bba146394ab@googlegroups.com>
 <p8bnbi$n0f$1@gioia.aioe.org>
NNTP-Posting-Host: fZYVf2g/avGnWJvs1xVPEA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
X-Notice: Filtered by postfilter v. 0.8.3
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:50982
Date: 2018-03-14T20:57:54-04:00
List-Id: <comp.lang.ada>

On 3/14/2018 1:49 PM, Dmitry A. Kazakov wrote:
> On 2018-03-14 18:35, Stephen Davies wrote:
>> I guess that this has probably been considered before,
>> but it would be nice if Ada allowed sub-cases, with
>> coverage checking of the appropriate alternatives.
>> This seems like a simpler change than some other recent
>> ones (e.g. conditional expressions), and would remove
>> one problem with not having non-contiguous subtypes.
>> For example:
>>
>>     case Calculate_Day is
>>        when Mon .. Fri =>
>>           ...
>>        when Weekend : Sat | Sun =>
>>           ...
>>           case Weekend is
>>              when Sat =>
>>                 ...
>>              when Sun =>
>>                 ...
>>           end case;
>>     end case;
>>
>> Ok, I know this isn't going to happen, I just wanted to
>> put it out there anyway.
> 
> Great idea, would be useful for variant records and exception handlers too.
> 
The variant record case might justify a language change.  For actual 
case statements I do:

     case Calculate_Day is
         when Mon .. Fri =>
            ...
         when Sat | Sun =>
            ...
            case Calculate_Day is
               when Sat =>
                  ...
               when Sun =>
                  ...
               when others => null; -- or raise Constrain_Error depending
                                    -- on style.
            end case;
      end case;

If Calculate_Day is a non-trivial function you might want to do:

     The_Day: Day := Calculate_Day
     ...
     case The_Day is
         when Mon .. Fri =>
            ...
         when Sat | Sun =>
            ...
            case The_Day is
               when Sat =>
                  ...
               when Sun =>
                  ...
               when others => null; -- or raise Constrain_Error depending
                                    -- on style.
            end case;
      end case;

It would be nice to allow compilers to allow the when others to be 
omitted based on what it knows about the value of The_Day but all that 
is syntactic sugar.  Or you could allow something like:
   case The_Day in Sat..Sunday is  -- very bad, better syntax needed.

What I usually end up doing in complex cases is to do:

       declare
         The_Day: constant Day := Calculate_Day;
       begin
          if The_Day in Mon..Fri then
             ...
          elsif The+Day = Saturday then
             ...
          else -- Day is Sunday
             ...
          end if;
       end;

Why? It seems to me that every time I end up with a complicated case, it 
is in the critical path of task scheduling.  (Or maybe I never need to 
look at others.)  The compiler probably will convert to an if statement, 
but by making the if statement explicit, I get to choose which case gets 
evaluated first.  (The compiler should also do any necessary branch tail 
merging.)  I might even choose to optimize for speed to get rid of the 
branches in the code.  On today's processors, branches can cost a lot 
more than other instructions.)