Choice of variant record discriminant (design question)

Choice of variant record discriminant (design question)

[Jacob Sparre Andersen]

I have declared a record type like this:

   type Preprocessed_Parameters (Measurement_Count : Natural := 0) is
      record
         case Measurement_Count is
            when 0 =>
               null;
            when others =>
               Mean_Value      : Scalar;
               Scaled_Variance : Scalar;
         end case;
      end record;

I would like to return an object of that type from a function using
this piece of code:

   if Count = 0 then
      return (Measurement_Count => 0);
   else
      [...]
      return (Measurement_Count => Count,
              Mean_Value        => Mean,
              Scaled_Variance   => Sum);
   end if;

I can't do this, since the discriminant has to be static.  The obvious
solution to the problem is to change the record declaration into:

   type Preprocessed_Parameters (Empty : Boolean := True) is
      record
         case Empty is
            when True =>
               null;
            when False =>
               Measurement_Count : Positive;
               Mean_Value        : Scalar;
               Scaled_Variance   : Scalar;
         end case;
      end record;

but I have a feeling there ought to be a more elegant solution.  Does
somebody have a suggestion or two?

Jacob
-- 
ACRONYM: A Contrived Reduction Of Nomenclature Yielding Mnemonics

Re: Choice of variant record discriminant (design question)

[christoph.grein]

Jacob Sparre Andersen wrote:
> I have declared a record type like this:
>
>    type Preprocessed_Parameters (Measurement_Count : Natural := 0) is
>       record
>          case Measurement_Count is
>             when 0 =>
>                null;
>             when others =>
>                Mean_Value      : Scalar;
>                Scaled_Variance : Scalar;
>          end case;
>       end record;
>
> I would like to return an object of that type from a function using
> this piece of code:
>
declare
  Parm: Preprocessed_Parameters (Measurement_Count => Count);
begin
>    if Count = 0 then
       null;
>    else
>       [...]
       Parm.Mean_Value := Mean;
       Parm.Scaled_Variance := Sum;
       return Parm;
>    end if;
> 
> I can't do this, since the discriminant has to be static.

Re: Choice of variant record discriminant (design question)

[Jacob Sparre Andersen]

christoph.grein@eurocopter.com writes:

> declare
>   Parm: Preprocessed_Parameters (Measurement_Count => Count);
> begin
>>    if Count = 0 then
>        null;
>>    else
>>       [...]
>        Parm.Mean_Value := Mean;
>        Parm.Scaled_Variance := Sum;
>        return Parm;
>>    end if;

Thanks!  (I wonder why I didn't remember that)

Jacob
-- 
"The three principal virtues of a programmer are Laziness,
 Impatience, and Hubris"                       -- Larry Wall

Re: Choice of variant record discriminant (design question)

[Jeffrey R. Carter]

Jacob Sparre Andersen wrote:

> I have declared a record type like this:
> 
>    type Preprocessed_Parameters (Measurement_Count : Natural := 0) is
>       record
>          case Measurement_Count is
>             when 0 =>
>                null;
>             when others =>
>                Mean_Value      : Scalar;
>                Scaled_Variance : Scalar;
>          end case;
>       end record;

Your record has 2 variants, so your discriminant should have 2 values.

> I can't do this, since the discriminant has to be static.  The obvious
> solution to the problem is to change the record declaration into:
> 
>    type Preprocessed_Parameters (Empty : Boolean := True) is
>       record
>          case Empty is
>             when True =>
>                null;
>             when False =>
>                Measurement_Count : Positive;
>                Mean_Value        : Scalar;
>                Scaled_Variance   : Scalar;
>          end case;
>       end record;
> 
> but I have a feeling there ought to be a more elegant solution.  Does
> somebody have a suggestion or two?

Now you have a discriminant with 2 values controlling a record with 2 variants. 
I find that more elegant than your 1st version.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Choice of variant record discriminant (design question)

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:m2acgwmpsu.fsf@hugin.crs4.it...
...
> but I have a feeling there ought to be a more elegant solution.  Does
> somebody have a suggestion or two?

I have to wonder if the variant is worth it. There is not going to be any
space savings, and in typical use, there isn't going to be much increase in
safety, either. So I'd probably give up on the variant in this case, because
I'd rather keep the aggregates (they are big help when a component needs to
be added). But only you can weight that trade-off, because the relative
value of the two options is something that depends on the components and the
intended uses. (If the "empty" variant wasn't going to be empty in future
version, for instance, the variant would make more sense.)

                        Randy.

Re: Choice of variant record discriminant (design question)

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> I have to wonder if the variant is worth it. There is not going to
> be any space savings,

Right.  But I hardly ever use variant records to save space.

> and in typical use, there isn't going to be much increase in safety,
> either.

Not that much, no.  But I prefer to let the code match the logic of
the problem.

> So I'd probably give up on the variant in this case, because I'd
> rather keep the aggregates (they are big help when a component needs
> to be added). But only you can weight that trade-off, because the
> relative value of the two options is something that depends on the
> components and the intended uses. (If the "empty" variant wasn't
> going to be empty in future version, for instance, the variant would
> make more sense.)

In this case, the null variant is most unlikely to end up containing
data later, so I can not use the argument that I may save space later
using this design.

If I didn't use that Ada allows me to encode the logic of my problem
in the source, couldn't I just as well use C or Fortran?

Thanks for the advice,

Jacob
-- 
"Only Hogwarts students really need spellcheckers"
                                -- An anonymous RISKS reader