Re: Why should the value for a discriminant be static?

[Niklas Holsti <nobody@nowhere.fi>]

Randy Brukardt wrote:
> "Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
> news:rlszmyd956d.fsf@jacob.crs4.it...
> 
>>Occasionally I run into the limitation that the value for a
>>discriminant be static.  I can design my way around the limitation
>>(when I remember it), but I would like to know the reason.  (also
>>because it might make it easier for me to remember the rule)
> 
> 
> The only place I know of off-hand where there is such a limitation is with
> aggregates. There, the limitation is necessary so that compiler can know the
> set of components for the aggregate. Otherwise, it would be impossible to
> check that components are given, which is *the* major benefit of using an
> aggregate over a series of component assignments.
> 
> I suppose such a check could be done at runtime, but that would be
> substantially less safe, as errors could exist in a program for a long time
> and occur only in unusual conditions after deployment.

I agree with the safety advantages of the static rule, but I have often 
wished that an aggregate would allow an expression with a statically 
known subtype as the discriminant *when* this subtype uniquely 
determines the set of components. For example:

    type Days is (
       Monday, Tuesday, Wednesday, Thursday, Friday,
       Saturday, Sunday);

    subtype Busy_Days is Days range Monday .. Friday;
    subtype Idle_Days is Days range Saturday .. Sunday;

    type Activity (Day : Days) is record
       case Day is
       when Busy_Days => Work : Work_Type;
       when Idle_Days => Play : Play_Type;
       end case;
    end record;

(I know this is unlike reality, where some of us work on week-ends, but 
this is just an example :-) I would like to be able to write an 
aggregate with the discriminant given by a non-static expression of a 
statically known subtype, for example:

    function Do_A_Job (Today : Busy_Days; Job : Work_Type)
    return Activity
    is
    begin

       -- NOT ALLOWED NOW:

       return (
          Day  => Today, -- Statically known to be in Busy_Days,
          Work => Job);  -- therefore this component exists.

    end Do_A_Job;

If, instead, the Today parameter is "Today : Days", I would like to be 
able to write the same aggregate with a conversion:

       -- NOT ALLOWED NOW:

       return (
          Day  => Busy_Days (Today),
          Work => Job);

This would include a run-time check that Today is in Busy_Days.

Would this be horribly messy to implement? The latter form with a 
conversion seems quite unambiguous. Without a conversion the 
discriminant expression should perhaps be required to be just a 
"statically constrained object" as defined in LRM 4.9(32).


-- 
Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .