Ada case-statement

Ada case-statement

[Stephen Davies]

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.

Re: Ada case-statement

[Dmitry A. Kazakov]

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada case-statement

[Robert I. Eachus]

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.)

Re: Ada case-statement

[Dan'l Miller]

On Wednesday, March 14, 2018 at 7:57:57 PM UTC-5, Robert Eachus wrote:
> The compiler probably will convert to an if statement, 

For dense case statements that utilize all or most of an enumerated type's enumerated values, a jump table is the most likely on most processors to achieve O(1) growth [instead of if-statement-based O(n) growth, where n is the quantity of enumerated values in an enumerated type].

https://stackoverflow.com/questions/39875452/assembly-jump-branch-lookup-tables-instead-of-lots-of-cmp-je

In IA-32, a jump table can be transliterated fairly directly from a case-statement over a dense utilization of an enumerated type.  Indeed, if the quantity of enumerated values in the enumerated type is small enough, a case statement that sparsely utilizes only a relative few of the enumerated values also can be transliterated to a jump table, where the unmentioned enumerated values conflate to unhandled case.
jmp  [jump_table + si]
jump_table:
   dw   .F_1,  .F_2, ...

Re: Ada case-statement

[J-P. Rosen]

Le 15/03/2018 à 04:10, Dan'l Miller a écrit :
> For dense case statements that utilize all or most of an enumerated
> type's enumerated values, a jump table is the most likely on most
> processors to achieve O(1) growth [instead of if-statement-based O(n)
> growth, where n is the quantity of enumerated values in an enumerated
> type].
Long time ago, as I was working on Ada/ED, my shelf had a PHD thesis
entirely on how to generate code for case statements. Various techniques
depending on the number of values, the density of mentionned values in
the subtype, etc.

Of course, you had the if/elsif and plain jump table techniques, but
also hashed jump tables, jump tables indexed by intervals, various mixes
(if/elsif to eliminate sparse cases, then tables for the rest)...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada case-statement

[Niklas Holsti]

On 18-03-15 07:54 , J-P. Rosen wrote:
> Le 15/03/2018 à 04:10, Dan'l Miller a écrit :
>> For dense case statements that utilize all or most of an enumerated
>> type's enumerated values, a jump table is the most likely on most
>> processors to achieve O(1) growth [instead of if-statement-based O(n)
>> growth, where n is the quantity of enumerated values in an enumerated
>> type].
> Long time ago, as I was working on Ada/ED, my shelf had a PHD thesis
> entirely on how to generate code for case statements. Various techniques
> depending on the number of values, the density of mentionned values in
> the subtype, etc.
>
> Of course, you had the if/elsif and plain jump table techniques, but
> also hashed jump tables, jump tables indexed by intervals, various mixes
> (if/elsif to eliminate sparse cases, then tables for the rest)...

And soon we will have processors with the "Mill" architecture, which can 
execute up to five conditional jumps in _parallel_, in each CPU cycle... 
brings a whole new set of possibilities for case-statement codde :-)

https://millcomputing.com/docs/switches/

BTW, the Mill architecture would be good at running Ada programs: very 
good at controlling the handling arithmetic errors, also good at 
subprogram calling, threading, emphasis on security (octet-granularity 
memory protection), etc. As a statically scehduled processor, it _could_ 
also be the only hope left for a powerful architecture with somewhat 
deterministic execution timing, for use in critical real-time systems, 
although the Mill developers currently do not describe it as a real-time 
processor.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada case-statement

[Dan'l Miller]

On Thursday, March 15, 2018 at 2:56:55 AM UTC-5, Niklas Holsti wrote:
> And soon we will have processors with the "Mill" architecture, which can 
> execute up to five conditional jumps in _parallel_, in each CPU cycle... 
> brings a whole new set of possibilities for case-statement codde :-)
> 
> https://millcomputing.com/docs/switches/
> 
> BTW, the Mill architecture would be good at running Ada programs: very 
> good at controlling the handling arithmetic errors, also good at 
> subprogram calling, threading, emphasis on security (octet-granularity 
> memory protection), etc. As a statically scehduled processor, it _could_ 
> also be the only hope left for a powerful architecture with somewhat 
> deterministic execution timing, for use in critical real-time systems, 
> although the Mill developers currently do not describe it as a real-time 
> processor.

Hmmmmmm.  At 30 subinstructions per wide-issue and the DSP-like belt/bypass, Mill is apparently a VLIW DSP retort to Itanium.  

https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing

Your goal of deterministic execution timing is eroded by the aspect of Itanium that most-singlehandedly undermined the entire multibillion-dollar EPIC/Itanium effort more than any other aspect:

“• Load responses from a memory hierarchy which includes CPU caches and DRAM do not have a deterministic delay. This makes static scheduling of load instructions by the compiler very difficult.”

Mill will succeed or fail on how well Mill makes astronomically-nondeterministic DRAM accesses to L1 cache, L2 cache, L3 cache, Rambus-esque serial-bus DRAM banks, and DDR-family parallel-bus DRAM banks all look deterministic to compilers trying to fill (at compile-time!) 30-subinstruction-wide instructions by figuring out (months or years a priori!) which subthread activities are ready to go whenever a datum-not-in-a-register is needed.  The problem could be solvable with an immense amount of registers.  Imagine the processor as a nano-mainframe:  load up batch-esque processing in registers, let 'er rip while predicting (all of!) the memory accesses for the next batch of processing long in advance.  If Mill fails to solve this problem, then Mill's fate is the same as Itanium's, and for precisely the same reason/fundamental-flaw.

Btw, VLIW DSPs don't have this problem, because they work on highly-predictable realtime information flows to perform a rather few highly-repetitive mathematical operations (hence leveraging the batch-processing analogy)—not general-purpose computing.  Software on VLIW DSPs actually can accurately predict precisely which memory/comm-channel data-arrival rates are needed to never cause a stall.

Mill processor (Was: Re: Ada case-statement)

[Niklas Holsti]

On 18-03-15 14:21 , Dan'l Miller wrote:
> On Thursday, March 15, 2018 at 2:56:55 AM UTC-5, Niklas Holsti
> wrote:
>> And soon we will have processors with the "Mill" architecture,
>> which can execute up to five conditional jumps in _parallel_, in
>> each CPU cycle... brings a whole new set of possibilities for
>> case-statement codde :-)
>>
>> https://millcomputing.com/docs/switches/
>>
>> BTW, the Mill architecture would be good at running Ada programs:
>> very good at controlling the handling arithmetic errors, also good
>> at subprogram calling, threading, emphasis on security
>> (octet-granularity memory protection), etc. As a statically
>> scehduled processor, it _could_ also be the only hope left for a
>> powerful architecture with somewhat deterministic execution timing,
>> for use in critical real-time systems, although the Mill developers
>> currently do not describe it as a real-time processor.
>
> Hmmmmmm.  At 30 subinstructions per wide-issue and the DSP-like
> belt/bypass,  Mill is apparently a VLIW DSP retort to Itanium.

If you dive deeper into the Mill, you will see that the designers are 
very well aware of the VLIW, DSP, and Itanium predecessors, and aim to 
avoid their mistakes and draw-backs.

Their general claim is that the Mill architecture delivers DSP-like 
MIPS/Watt for general (not necessarily DSP-like) applications.

>  Your goal of deterministic execution timing is eroded by the aspect
> of Itanium that most-singlehandedly undermined the entire
> multibillion-dollar EPIC/Itanium effort more than any other aspect:
>
> “• Load responses from a memory hierarchy which includes CPU caches
> and DRAM do not have a deterministic delay. This makes static
> scheduling of load instructions by the compiler very difficult.”

The Mill load instructions have novel means to combat this effect:

https://millcomputing.com/docs/#memory

The Mill also has a scratchpad memory for local storage, avoiding some 
memory accesses.

Cache behaviour (miss/hit/unknown classification, worst-case access 
times) is one aspect of complex processors that _can_ be analysed 
statically, although with some approximation. Works well for instruction 
caches, less well for data caches -- depending on the program to be 
analysed, of course.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada case-statement

[Randy Brukardt]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message 
news:p8cgeh$1v7d$1@gioia.aioe.org...
...
> 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.

Actually, we considered that in variants, but it turns out that it would 
cause an incompatibility. I forget the details, but it has something to do 
with the completeness checks (which we would not want to lose). We tried a 
number of options, but they were worse than the original problem. So we 
decided not to do it. In any case, it's a lot more than "syntactic sugar", 
it would substantially change the semantics.

                              Randy.

Re: Ada case-statement

[Mehdi Saada]

I appreciate the parallel with exception handlers.
And I would like it if it were easier in those, to run a general sequence of statements before selective ones, without that ugly construct:
exception when others =>
   begin
      do_something;
      raise;
   exception when ...
   end;
end;
like you would do:
when Weekend : Sat | Sun =>
   ...
   case Weekend is
        when Sat =>
            ...
        when Sun =>
            ...
   end case;

Re: Ada case-statement

[Randy Brukardt]

"Stephen Davies" <joviangm@gmail.com> wrote in message 
news:365d65ea-5f4b-4b6a-be9b-1bba146394ab@googlegroups.com...
...
> Ok, I know this isn't going to happen, I just wanted to
> put it out there anyway.

Since the deadline for suggestions for Ada 2020 was January 15th, you are 
right. ;-)

OTOH, someone made a fairly similar suggestion before the deadline; it was 
folded into existing AI12-0214-1. (As usual, no one is really doing a good 
job of explaining the "problem" rather than proposing a cool "solution". The 
ARG is perfectly capable of inventing a half-dozen solutions to any problem. 
:-) This matters mainly because we want to minimize the number of 
"solutions" in a language update.)

The problem is that we have far more "problems" and suggestions than we have 
time to implement in the Standard. We are trying to figure out right now how 
to prioritize the 60+ problems/solutions on our plate. Some worthy ideas are 
certainly going to go nowhere, even though they might be fine.

In any case, you can get what you want with some additional text, so I would 
guess that the priority of such a change would be relatively low:

declare
  Selector : Day_Type renames Calculate_Day;
  subtype Weekend_Subtype is Day_Type range Sat .. Sun;
     -- Or use a static predicate if the range is discontiguous.
begin
  case Selector is
      when Mon .. Fri =>
         ...
      when  Sat | Sun =>
         ...
         case Weekend_Subtype'(Selector) is -- A type conversion works, too.
            when Sat =>
               ...
            when Sun =>
               ...
         end case;
   end case;
end;

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.

Currently, the "id :" notation occurs in three places without an explicit 
subtype (block ids, loop ids, exception occurrences). The first two have 
types that don't even have names (and id can only be used in a handful of 
circumstances). The third has a well-defined composite type that has no 
subtypes (so there is no semantic information to be gained by writing it 
out).

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.

We have been considering making the subtype name in an object renames 
optional -- the subtype is a lie anyway (since it is ignored semantically), 
and other important properties of the renamed object like "constant" are 
omitted. That's about as far as I will go for typeless declarations (and 
perhaps even that is too far).

But - I am not the ARG, I'm just one member. The actual language agreed on 
may differ. :-)

                                     Randy.

Re: Ada case-statement

[gautier_niouzes]

Le jeudi 15 mars 2018 00:16:29 UTC+1, Randy Brukardt a écrit :

> declare
>   Selector : Day_Type renames Calculate_Day;
>   subtype Weekend_Subtype is Day_Type range Sat .. Sun;
>      -- Or use a static predicate if the range is discontiguous.
> begin
>   case Selector is
>       when Mon .. Fri =>
>          ...
>       when  Sat | Sun =>

You can even write "when Weekend_Subtype =>" there instead of "when Sat | Sun =>".
And if you write above "subtype Weekend is Day_Type range Sat .. Sun", then you have a nice "when Weekend =>" in the case statement.

Re: Ada case-statement

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> 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.

Agreed.

> We have been considering making the subtype name in an object renames
> optional -- the subtype is a lie anyway (since it is ignored
> semantically), and other important properties of the renamed object
> like "constant" are omitted. That's about as far as I will go for
> typeless declarations (and perhaps even that is too far).

Wouldn't it be more informative for the reader, if one was forced to use
the name of the first subtype in object renames?  (Yes.  I know.  Not
backwards compatible.)

Removing the type information completely would in my view make the
source text even harder to read.  But maybe only for people who
understand (some of) the intricacies of object renames.

Greetings,

Jacob
-- 
"There are two ways of constructing a software design. One way is to
 make it so simple that there are obviously no deficiencies. And the
 other way is to make it so complicated that there are no obvious
 deficiencies."                                    -- C. A. R. Hoare

Re: Ada case-statement

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87k1udvkuh.fsf@jacob-sparre.dk...
> Randy Brukardt wrote:
...
>> We have been considering making the subtype name in an object renames
>> optional -- the subtype is a lie anyway (since it is ignored
>> semantically), and other important properties of the renamed object
>> like "constant" are omitted. That's about as far as I will go for
>> typeless declarations (and perhaps even that is too far).
>
> Wouldn't it be more informative for the reader, if one was forced to use
> the name of the first subtype in object renames?  (Yes.  I know.  Not
> backwards compatible.)

Surely, but that still would be confusing if the first subtype is 
constrained (an object can have a different constraint, such as a slice of a 
constrained array). Static matching would be better. Ichbiah, however, 
didn't want to define static matching (John Goodenough dug out the relevant 
e-mail thread a few years back - it says precisely that). Of course, one of 
the first things Tucker and the Ada 9x group did was define static matching 
to get rid of silly runtime checks in generic instances. Once you have 
static matching, you can just require that - but, as you say, that's too 
incompatible to consider.

(Even more confusing is the fact that null exclusions are required to 
match - we didn't want even more wrong stuff. Not sure that was a good idea 
in hindsight.)

> Removing the type information completely would in my view make the
> source text even harder to read.  But maybe only for people who
> understand (some of) the intricacies of object renames.

It certainly would be better, IMHO, to have some unconstrained type 
specified so you can find the *type* information. But that would require 
declarations like:
     Obj : Integer'Base renames ...;
which would drive people crazy.

It would be better still not to have renames at all, but there are just 
enough practical uses to put up with it.

                                     Randy.

Re: Ada case-statement

[Dmitry A. Kazakov]

On 15/03/2018 00:16, Randy Brukardt wrote:

> declare
>    Selector : Day_Type renames Calculate_Day;
>    subtype Weekend_Subtype is Day_Type range Sat .. Sun;
>       -- Or use a static predicate if the range is discontiguous.
> begin
>    case Selector is
>        when Mon .. Fri =>
>           ...
>        when  Sat | Sun =>
>           ...
>           case Weekend_Subtype'(Selector) is -- A type conversion works, too.
>              when Sat =>
>                 ...
>              when Sun =>
>                 ...
>           end case;
>     end case;
> end;

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;

And this does not work with

    when Odd_Week_Day : Mon | Wed | Fri =>

> 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?

> 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.

> We have been considering making the subtype name in an object renames
> optional -- the subtype is a lie anyway (since it is ignored semantically),
> and other important properties of the renamed object like "constant" are
> omitted. That's about as far as I will go for typeless declarations (and
> perhaps even that is too far).

Yes, subtype specification in renaming is a noise, and a dangerous one, 
because it whispers lies as the language does nothing in order to 
enforce it or at least to check conformance to the constraints stated by 
it. Certainly, if the present semantics of renaming to stay, the subtype 
name *must* be removed for the sake of clarity and safety.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada case-statement

[Randy Brukardt]

"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.

Re: Ada case-statement

[Dmitry A. Kazakov]

On 15/03/2018 23:20, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p8dbcp$11bc$1@gioia.aioe.org...

>> 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.

This applies to everything:

    when Thurs =>

What is the type of Thurs? I either know or in most cases simply do not 
care.

In any case this is no change of the semantics. Today has the semantics 
of the case statement argument. You didn't specify the type there, why 
should you do here?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada case-statement

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p8g0om$1gpe$1@gioia.aioe.org...
> On 15/03/2018 23:20, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:p8dbcp$11bc$1@gioia.aioe.org...
>
>>> 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.
>
> This applies to everything:
>
>    when Thurs =>
>
> What is the type of Thurs? I either know or in most cases simply do not 
> care.

You have to know, and you usually do with a commonly used enumeration. And 
at the same time it isn't as important to know - you almost never are going 
to use any overloaded operators (which often require qualifying something) 
in a case limb.

Once you have a general name for something, you can (and do) use it in many 
contexts, and then the type (and its name) become necessary: for "use type", 
for qualifications, for type conversions, and so on.

> In any case this is no change of the semantics. Today has the semantics of 
> the case statement argument. You didn't specify the type there, why should 
> you do here?

You're not declaring an object for the case selector; that's "consuming" a 
value rather than creating one. All objects should have their type defined 
directly next to the declaration.

                                         Randy.

Re: Ada case-statement

[Dmitry A. Kazakov]

On 2018-03-17 00:49, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p8g0om$1gpe$1@gioia.aioe.org...
>> On 15/03/2018 23:20, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:p8dbcp$11bc$1@gioia.aioe.org...
>>
>>>> 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.
>>
>> This applies to everything:
>>
>>     when Thurs =>
>>
>> What is the type of Thurs? I either know or in most cases simply do not
>> care.
> 
> You have to know, and you usually do with a commonly used enumeration.

Enumeration literals overloading works just fine. And it is really so 
that I frequently don't know the types of enumeration literals and have 
to search for in the sources.

> And
> at the same time it isn't as important to know - you almost never are going
> to use any overloaded operators (which often require qualifying something)
> in a case limb.
> 
> Once you have a general name for something, you can (and do) use it in many
> contexts, and then the type (and its name) become necessary: for "use type",
> for qualifications, for type conversions, and so on.

Literals (all of them: enumerations, numeric, strings) are 
self-contained, you don't need their types in most cases. Adding type 
specification to a literal or a set of literals is just noise, most of 
the time. [*]

>> In any case this is no change of the semantics. Today has the semantics of
>> the case statement argument. You didn't specify the type there, why should
>> you do here?
> 
> You're not declaring an object for the case selector; that's "consuming" a
> value rather than creating one. All objects should have their type defined
> directly next to the declaration.

Maybe, though some trivial type inference is OK. And I see nothing wrong 
when the type is specified as "same as above".

------------------
* Literal values, literal ranges, literal sets, literal arrays is one of 
few cases where structural type equivalence works far better than the 
named one.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada case-statement

[Stephen Davies]

On Wednesday, 14 March 2018 23:16:29 UTC, Randy Brukardt  wrote:

> declare
>   Selector : Day_Type renames Calculate_Day;
>   subtype Weekend_Subtype is Day_Type range Sat .. Sun;
>      -- Or use a static predicate if the range is discontiguous.
> begin
>   case Selector is
>       when Mon .. Fri =>
>          ...
>       when  Sat | Sun =>
>          ...
>          case Weekend_Subtype'(Selector) is -- A type conversion works, too.
>             when Sat =>
>                ...
>             when Sun =>
>                ...
>          end case;
>    end case;
> end;

Unless this has changed in more recent compilers, the static predicate
when Sat & Sun are not contiguous does not work. Gnatpro 7.0.2 complains
about missing values. Also, attempting to use "when Weekend_Subtype" in
the outer case-statement results in complaints about duplicate values.

Re: Ada case-statement

[J-P. Rosen]

Le 15/03/2018 à 16:37, Stephen Davies a écrit :
> On Wednesday, 14 March 2018 23:16:29 UTC, Randy Brukardt  wrote:
> 
>> declare
>>   Selector : Day_Type renames Calculate_Day;
>>   subtype Weekend_Subtype is Day_Type range Sat .. Sun;
>>      -- Or use a static predicate if the range is discontiguous.
>> begin
>>   case Selector is
>>       when Mon .. Fri =>
>>          ...
>>       when  Sat | Sun =>
>>          ...
>>          case Weekend_Subtype'(Selector) is -- A type conversion works, too.
>>             when Sat =>
>>                ...
>>             when Sun =>
>>                ...
>>          end case;
>>    end case;
>> end;
> 
> Unless this has changed in more recent compilers, the static predicate
> when Sat & Sun are not contiguous does not work. Gnatpro 7.0.2 complains
> about missing values. Also, attempting to use "when Weekend_Subtype" in
> the outer case-statement results in complaints about duplicate values.
> 
It IS contiguous in countries where the week starts on Monday...

BTW, for you who start the week on Sunday, isn't Sunday part of the
week-END? ;-)

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada case-statement

[Dmitry A. Kazakov]

On 2018-03-15 17:33, J-P. Rosen wrote:

> BTW, for you who start the week on Sunday, isn't Sunday part of the
> week-END? ;-)

It always puzzled me, as well as the endianness of date: 03/10/2017 = 
March 10, 2017 (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada case-statement

[Shark8]

On Thursday, March 15, 2018 at 11:01:28 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> It always puzzled me, as well as the endianness of date: 03/10/2017 = 
> March 10, 2017 (:-))

Given the DOD origins of Ada, I'm rather surprised the native date format isn't "DDMMMYY" / "DD-MMM-YY[YY]" -- proper "military date" which is unambiguous (something you need for serialization/de-serialization) -- and perhaps have an optional "ISO 8601" child-package of Calendar w/ the 95 revision.

Re: Ada case-statement

[Jeffrey R. Carter]

On 03/15/2018 07:41 PM, Shark8 wrote:
> On Thursday, March 15, 2018 at 11:01:28 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> Given the DOD origins of Ada, I'm rather surprised the native date format isn't "DDMMMYY" / "DD-MMM-YY[YY]" -- proper "military date" which is unambiguous (something you need for serialization/de-serialization) -- and perhaps have an optional "ISO 8601" child-package of Calendar w/ the 95 revision.

Ada 83 didn't have a "date format". String representations of dates were left up 
to the programmer. What it did have was Calendar.Time, which could be created 
from Year, Month, and Day numbers, each clearly labeled with what it 
represented, or queried/decomposed to obtain Year, Month, and Day numbers, again 
clearly labeled.

For the early 1980s, it was somewhat prescient in avoiding 2-digit years, 
something I recall liking when I first encountered the language.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Ada case-statement

[Robert I. Eachus]

On 3/15/2018 5:12 PM, Jeffrey R. Carter wrote:

> For the early 1980s, it was somewhat prescient in avoiding 2-digit 
> years, something I recall liking when I first encountered the language.
> 
Ada 83 has a known Doom Date of December 31, 2099.  It has since been 
updated to 2399, so don't get too worried.  Actually, the beginning of 
Ada time 1901, isn't perfect.  Some countries Russia, Turkey, and Greece 
in particular used the Julian calendar into the early 20th century.  It 
just didn't make sense for Ada to worry about THAT particular problem.

In the other direction, even the Gregorian calendar isn't perfect and a 
leap day will need to be skipped every few thousand years.  Probably 
either Feb. 29th, 3000 or Feb. 29th, 4000 won't occur.  My guess is that 
the latter date will win out. When it starts to become an issue in the 
late thirtieth century, it will be easier to put it off for another 
thousand years.  (I just hope I'm around to see it. ;-)

Re: Ada case-statement

[Spiros Bousbouras]

On Sun, 18 Mar 2018 01:41:05 -0400
"Robert I. Eachus" <rieachus@comcast.net> wrote:
> In the other direction, even the Gregorian calendar isn't perfect and a 
> leap day will need to be skipped every few thousand years.  Probably 
> either Feb. 29th, 3000 or Feb. 29th, 4000 won't occur.

3000 isn't a leap year because 3000 is divisible by 100 but not by 400.

> My guess is that 
> the latter date will win out. When it starts to become an issue in the 
> late thirtieth century, it will be easier to put it off for another 
> thousand years.  (I just hope I'm around to see it. ;-)

Re: Ada case-statement

[Jeffrey R. Carter]

On 03/18/2018 06:41 AM, Robert I. Eachus wrote:
>>
> Ada 83 has a known Doom Date of December 31, 2099.  It has since been updated to 
> 2399, so don't get too worried.  Actually, the beginning of Ada time 1901, isn't 
> perfect.  Some countries Russia, Turkey, and Greece in particular used the 
> Julian calendar into the early 20th century.  It just didn't make sense for Ada 
> to worry about THAT particular problem.

2099 seemed like a reasonable value for Year_Number'Last at the time. Still 
does, for most things. Better than 1999.

> In the other direction, even the Gregorian calendar isn't perfect and a leap day 
> will need to be skipped every few thousand years.  Probably either Feb. 29th, 
> 3000 or Feb. 29th, 4000 won't occur.  My guess is that the latter date will win 
> out. When it starts to become an issue in the late thirtieth century, it will be 
> easier to put it off for another thousand years.  (I just hope I'm around to see 
> it. ;-)

I'd bet on 4000, since 3000 isn't a leap year. I'd like to be around to see it, too.

-- 
Jeff Carter
"Insufficient laughter--that's grounds for divorce."
Play It Again, Sam
126

Re: Ada case-statement

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> I'd bet on 4000, since 3000 isn't a leap year. I'd like to be around
> to see it, too.

Not going to hold my breath for that. Would be counter-productiive, of
course.

Re: Ada case-statement

[Jere]

On Thursday, March 15, 2018 at 11:37:48 AM UTC-4, Stephen Davies wrote:
> On Wednesday, 14 March 2018 23:16:29 UTC, Randy Brukardt  wrote:
> 
> > declare
> >   Selector : Day_Type renames Calculate_Day;
> >   subtype Weekend_Subtype is Day_Type range Sat .. Sun;
> >      -- Or use a static predicate if the range is discontiguous.
> > begin
> >   case Selector is
> >       when Mon .. Fri =>
> >          ...
> >       when  Sat | Sun =>
> >          ...
> >          case Weekend_Subtype'(Selector) is -- A type conversion works, too.
> >             when Sat =>
> >                ...
> >             when Sun =>
> >                ...
> >          end case;
> >    end case;
> > end;
> 
> Unless this has changed in more recent compilers, the static predicate
> when Sat & Sun are not contiguous does not work. Gnatpro 7.0.2 complains
> about missing values. Also, attempting to use "when Weekend_Subtype" in
> the outer case-statement results in complaints about duplicate values.

I just tried a quick example in GNAT 6.1.1 and 7.2.0 and both seemed pretty
happy with static predicates.  I don't have 7.0.2 to check

procedure jdoodle is
    type Day is (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday);
    subtype Weekday is Day range Monday .. Friday;
    subtype Weekend is Day
        with Static_Predicate => Weekend in Saturday | Sunday;
        
    v : Day := Monday;
begin
    
    case v is
        when Weekday =>
            case Weekday(v) is
                when Monday    => null;
                when Tuesday   => null;
                when Wednesday => null;
                when Thursday  => null;
                when Friday    => null;
            end case;
        
        when Weekend =>
            case Weekend(v) is
                when Saturday => null;
                when Sunday   => null;
            end case;
    end case;
    
end jdoodle;

no warnings or errors for either version

Re: Ada case-statement

[Anh Vo]

On Thursday, March 15, 2018 at 11:50:19 AM UTC-7, Jere wrote:
> On Thursday, March 15, 2018 at 11:37:48 AM UTC-4, Stephen Davies wrote:
> > On Wednesday, 14 March 2018 23:16:29 UTC, Randy Brukardt  wrote:
> > 
> > > declare
> > >   Selector : Day_Type renames Calculate_Day;
> > >   subtype Weekend_Subtype is Day_Type range Sat .. Sun;
> > >      -- Or use a static predicate if the range is discontiguous.
> > > begin
> > >   case Selector is
> > >       when Mon .. Fri =>
> > >          ...
> > >       when  Sat | Sun =>
> > >          ...
> > >          case Weekend_Subtype'(Selector) is -- A type conversion works, too.
> > >             when Sat =>
> > >                ...
> > >             when Sun =>
> > >                ...
> > >          end case;
> > >    end case;
> > > end;
> > 
> > Unless this has changed in more recent compilers, the static predicate
> > when Sat & Sun are not contiguous does not work. Gnatpro 7.0.2 complains
> > about missing values. Also, attempting to use "when Weekend_Subtype" in
> > the outer case-statement results in complaints about duplicate values.
> 
> I just tried a quick example in GNAT 6.1.1 and 7.2.0 and both seemed pretty
> happy with static predicates.  I don't have 7.0.2 to check
> 
> procedure jdoodle is
>     type Day is (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday);
>     subtype Weekday is Day range Monday .. Friday;
>     subtype Weekend is Day
>         with Static_Predicate => Weekend in Saturday | Sunday;
>         
>     v : Day := Monday;
> begin
>     
>     case v is
>         when Weekday =>
>             case Weekday(v) is
>                 when Monday    => null;
>                 when Tuesday   => null;
>                 when Wednesday => null;
>                 when Thursday  => null;
>                 when Friday    => null;
>             end case;
>         
>         when Weekend =>
>             case Weekend(v) is
>                 when Saturday => null;
>                 when Sunday   => null;
>             end case;
>     end case;
>     
> end jdoodle;
> 
> no warnings or errors for either version

It compiles fine with GNAT-GPL-2017 running on Windows, too.

Anh Vo

Re: Ada case-statement

[Randy Brukardt]

"Stephen Davies" <joviangm@gmail.com> wrote in message 
news:c398c38e-6567-40e1-b686-7aef94e36fe3@googlegroups.com...
> On Wednesday, 14 March 2018 23:16:29 UTC, Randy Brukardt  wrote:
>
>> declare
>>   Selector : Day_Type renames Calculate_Day;
>>   subtype Weekend_Subtype is Day_Type range Sat .. Sun;
>>      -- Or use a static predicate if the range is discontiguous.
>> begin
>>   case Selector is
>>       when Mon .. Fri =>
>>          ...
>>       when  Sat | Sun =>
>>          ...
>>          case Weekend_Subtype'(Selector) is -- A type conversion works, 
>> too.
>>             when Sat =>
>>                ...
>>             when Sun =>
>>                ...
>>          end case;
>>    end case;
>> end;
>
> Unless this has changed in more recent compilers, the static predicate
> when Sat & Sun are not contiguous does not work. Gnatpro 7.0.2 complains
> about missing values. Also, attempting to use "when Weekend_Subtype" in
> the outer case-statement results in complaints about duplicate values.

It should have changed, there are a number of ACATS tests checking precisely 
this sort of thing. So far as I know, GNAT passes those tests. (And GNATPro 
7.0.2 is a looonnnng time ago, based on the ACATS tests I wouldn't expect 
much of any Ada 2012 features to work in that. I'd guess this would work in 
all of the ones I've used recently: 7.4.1, 17.1, and 18.1.)

                                                   Randy.

Re: Ada case-statement

[Stephen Davies]

On Thursday, 15 March 2018 22:24:08 UTC, Randy Brukardt  wrote:
> Stephen Davies wrote in message 
> > Unless this has changed in more recent compilers, the static predicate
> > when Sat & Sun are not contiguous does not work. Gnatpro 7.0.2 complains
> > about missing values. Also, attempting to use "when Weekend_Subtype" in
> > the outer case-statement results in complaints about duplicate values.

> It should have changed, there are a number of ACATS tests checking precisely 
> this sort of thing. So far as I know, GNAT passes those tests. (And GNATPro 
> 7.0.2 is a looonnnng time ago, based on the ACATS tests I wouldn't expect 
> much of any Ada 2012 features to work in that. I'd guess this would work in 
> all of the ones I've used recently: 7.4.1, 17.1, and 18.1.)

Fair enough, that's one less justification for my proposal :-(

Re: Ada case-statement

[marciant]

> declare
>   Selector : Day_Type renames Calculate_Day;
>   subtype Weekend_Subtype is Day_Type range Sat .. Sun;
>      -- Or use a static predicate if the range is discontiguous.
> begin
>   case Selector is
>       when Mon .. Fri =>
>          ...
>       when  Sat | Sun =>
>          ...
>          case Weekend_Subtype'(Selector) is -- A type conversion works, too.
>             when Sat =>
>                ...
>             when Sun =>
>                ...
>          end case;
>    end case;
> end;

Isn't the type conversion better withe the subtype also appearing as the first alternative:

 case Selector is
     when Mon .. Fri =>
        ...
     when Weekend_Subtype => --!!
        ...
        case Weekend_Subtype'(Selector) is
           when Sat =>
              ...
           when Sun =>
              ...
        end case;
  end case;