Re: Ada case-statement

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p8dbcp$11bc$1@gioia.aioe.org...
> On 15/03/2018 00:16, Randy Brukardt wrote:
...
> Ugh, that could be a source quite intractable bugs. If so, I use this 
> pattern time to time then:
>
> declare
>    Selector : Day_Type renames Calculate_Day;
>    subtype Weekend_Subtype is Day_Type range Sat .. Sun;
> begin
>    case Selector is
>      when Mon .. Fri =>
>         ...
>      when Weekend_Subtype =>
>         ...
>         case Weekend_Subtype'(Selector) is
>            when Sat =>
>               ...
>            when Sun =>
>               ...
>         end case;
>   end case;

You're right, that's better.

> And this does not work with
>
>    when Odd_Week_Day : Mon | Wed | Fri =>

Wrong:

   subtype Odd_Week_Day is Day_Type
      with Static_Predicate => Odd_Week_Day in Mon | Wed | Fri;

...
      when Odd_Week_Day =>
         ...
         case Odd_Week_Day'(Selector) is

The subtype is the (admittedly ugly - I wanted something cleaner) way to 
declare a set constraint. If the predicate is static, it works in loops and 
case statements with the usual rules.

>> Personally, I don't like declarations without explicit subtypes, as the
>> subtype of an object is critical for understanding the semantics. Not 
>> having
>> the subtype in the source makes it much harder to understand the 
>> semantics.
>
> Huh, it is definitely true for types, but Ada subtypes are designed for 
> exactly the opposite. On many occasions people here argued that Ada 
> subtype is not a type. Well, from that point of view it must have exactly 
> the same semantics as its base. What's is there to understand more?

You have to have the subtype in the source to know the type -- Ada does not 
have names for types.

>> Expanding the "id :" notation would definitely harm understandability of 
>> Ada
>> code, and with readability being pretty much the first priority for Ada
>> syntax, that's a bad thing.
>
> I don't see how giving a name could add anything to the semantics. Each 
> alternative exhaustively defines a constraint. No reason to contaminate 
> the name space.

How does
     when Today: Thurs =>
exhaustively define anything? It just defines a constraint, but there is not 
way to know of what. You have to look at the selecting_expression to find 
the type -- but it doesn't show it either. It might a function call as in 
this example. So then you have to look at the function to get the return 
type, but it will turn out to have been implemented in a generic or 
inherited in OOP. So now you're on 4-5 hops and you've forgotten why you 
were looking for the type in the first place. :-)

Surely a fancy IDE would help, but if you need a fancy IDE to undertstand 
your code, it isn't readable.

                              Randy.