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

[Niklas Holsti <nobody@nowhere.fi>]

Jeffrey Carter wrote:
> Niklas Holsti wrote:
> 
>> 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;
>>
>>    function Do_A_Job (Today : Busy_Days; Job : Work_Type)
>>    return Activity
>>    is
>>    begin
>>       return (
>>          Day  => Today, -- Statically known to be in Busy_Days,
>>          Work => Job);  -- therefore this component exists.
>>    end Do_A_Job;
> 
> 
> In simple terms, this design if faulty.

Now then, that's rather harsh. It's certainly legal Ada; if you think
its philosophically faulty, you are entitled to your opinion and I am
entitled to disagree; if you think its faulty because it leads to
practical problems, the problem is just with the requirement for
static discriminants in aggregates -- which is what this thread is
about.

> It's easy to argue otherwise for 
> this simple example (7 enumeration values and 2 variants), but I've seen 
> real world examples where it's harder to argue this way. One had over 
> 200 enumeration values and about 10 variants.
> 
> I argued in that case that they really needed 11 types: and enumeration 
> type for the discriminant with about 10 values, and 10 other types, one 
> for each variant to contain the specific information for the variant.

That is of course the work-around. I have done designs both ways 
depending on the circumstances.

> That level of code modification was considered unacceptable, so I 
> pointed them to the local result variable alternative:
> 
> function F (Day : Busy_Days; Work : Works)
> return Activities -- Let's use a consistent naming policy :)

(In my own code I consistently use the suffix _T for types.)

> is
>    Result : Activities (Day => Day);
> begin -- F
>    Result.Work := Work;
>    return Result;
> end F;

Which loses the compile-check that the assigned components exist
and that all existing components are assigned. This is what I
(and others) want to avoid. Of course it can be an emergency
solution as in your anecdote.

The question is one of symmetry: since the language allows static
subtypes in the declaration of the variant parts of a record type,
it should symmetrically allow statically subtyped expressions as
discriminant values in aggregates for such record types.


-- 
Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .