Why should the value for a discriminant be static?

Why should the value for a discriminant be static?

[Jacob Sparre Andersen]

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)

Greetings,

Jacob
-- 
�You have to blow things up to get anything useful.�
                                  -- Archchancellor Ridcully

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

[Randy Brukardt]

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

Anyway, does that answer your question, or was this in some other context?

                 Randy Brukardt

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

[Niklas Holsti]

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

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

[Jeffrey Carter]

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. 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 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 :)
is
    Result : Activities (Day => Day);
begin -- F
    Result.Work := Work;
    return Result;
end F;

Of course, they really had a parameter of type Days, and had to build 
results for every variant, for much larger variants, so this got pretty 
hairy.

For your particular example, I would always recommend a type for the 
discriminant:

type Day_Kind_ID is (Busy_Day, Idle_Day);

You could have 2 types for the actual day in question, or a single type 
with 2 subtypes; to differ from your example as much as possible, let's 
choose the former:

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

type Activity_Info (Day_Kind : Day_Kind_ID) is record
    case Day_Kind is
    when Busy_Day =>
       Work_Day : Busy_Day_Name;
       Work     : Work_Info;
    when Idle_Day =>
       Play_Day : Idle_Day_Name;
       Play     : Play_Info;
    end case;
end record;

Then your function would be

function F (Day : Busy_Day_Name; Work : Work_Info) return Activity_Info
is
    -- null;
begin -- F
    return Activity_Info'(Day_Kind => Busy_Day, -- Static.
                          Work_Day => Day,
                          Work     => Work);
end F;

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

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

[Niklas Holsti]

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

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

[Jeffrey Carter]

Niklas Holsti wrote:

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

Not at all. There's a software engineering principle that one thing 
should serve one purpose, and this violates that: it serves both to 
identify the 2 classes and to provide the specific information for each 
class.

> 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 compile-time check exists at the point of the call to the function 
in this case, but in the general case that doesn't hold. On the other 
hand, when designed properly, you do get the compile time check.

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

So, I guess the language must be faulty to allow static subtypes for 
variants.

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

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

[Niklas Holsti]

Jeffrey Carter wrote:
> Niklas Holsti wrote:
> 
>> 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.
> 
> 
> Not at all. There's a software engineering principle that one thing 
> should serve one purpose, and this violates that: it serves both to 
> identify the 2 classes and to provide the specific information for each 
> class.

So the "fault" is philosophical. From your interpretation of that
principle, you could argue against any use of "derived properties
of objects", and insist on a separate component to hold each such
derived property. Not attractive to me, but as I said, we can
disagree on what is desirable, even if we agree that the current
Ada rules are asymmetrical in this area.


-- 
Niklas Holsti
Tidorum Ltd

niklas holsti tidorum fi
       .      @       .

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

[Jacob Sparre Andersen]

Randy Brukardt <randy@rrsoftware.com> writes:
> 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.

Yes.  That was also what I ran into today.

> There, the limitation is necessary so that compiler can know the set
> of components for the aggregate.

That makes sense.

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

Yes.

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

True.  And although I think I also had the record components correct
the first time around (except for the non-static discriminant), the
changed code is probably safer.

> Anyway, does that answer your question, or was this in some other
> context?

It answers my question.  And I think it is enough to make me remember
this rule in the future.  Thanks.

Jacob
-- 
�By becoming continuous, war has fundamentally changed its character.
 In past ages, a war, almost by definition, was something that sooner
 or later came to an end, usually in unmistakable victory or defeat.�
                               -- Nineteen Eighty-Four, George Orwell
�I don't think you can win [the war on terror].�    -- George W. Bush