Re: Translating an embedded C algorithm

[Niklas Holsti <niklas.holsti@nospam.please>]

Robert A Duff wrote:
> ...
> 
> Also, I think it would be overkill to put both ways of dealing with
> invalid results in an example in a book.  I'd suggest just using the
> exception method, and ignore the rather complex idea of variant
> records.

You may be right that having both methods is too much for this example, 
but I see an important difference in capability and applications between 
variant records and exceptions:

- Exceptions are dynamic and evanescent; they are useful for
   forcing the program to take immediate note of an unexpected
   situation that makes it impossible or incorrect to continue
   with business as usual. In this example, the exception says
   "your present attempt to convert this ADC count into a
   temperature is impossible and I will not let you continue
   as if it had succeeded".

- Variant records can be static and persistent; they are useful
   for recording the fact that some data are available, others
   not. In this example, an ADC.Thermometer.Reading_T could
   be stored in some status record, or telemetry packet, and
   could be consulted later, by other parts of the program, to
   get the temperature or notice the out-of-range condition.
   A value with In_Range = False says "no current temperature
   is available because the last attempt to read the temperature
   gave an out-of-range result".

Thus I think that both methods have their uses, often in the same 
program but at different points.

Of course one could store a non-variant record with a Boolean in-range 
flag and a temperature component, but this would not prevent some part 
of the program from accessing the temperature component even if its 
value is wrong because of an out-of-range condition. As you know (but 
the OP perhaps does not) the variant record form guards against such 
errors by raising Constraint_Error if the program tries to access a 
component that is not present in the current variant.

The variant record approach could also be extended a bit to bring 
enumerated types into the example. Instead of the current Boolean 
discriminant (which is a bit ugly in the "case" constructs) we could 
define, in ADC.Thermometer:

    type Status_T is (Out_Of_Range, In_Range, Under_Min, Over_Max);
    --
    -- The general status of an ADC thermometer reading.
    --
    -- Out_Of_Range
    --    The ADC count was not within the expected range,
    --    and saturation was not requested, so no temperature
    --    is available.
    -- In_Range
    --    The ADC count was within the expected range so the
    --    temperature is available.
    -- Under_Min
    --    The ADC count was below the minimum expected value.
    --    The temperature was saturated at its minimum value.
    -- Over_Max
    --    The ADC count was above the maximum expected value.
    --    The temperature was saturated at its maximum value.

    type Reading_T (Status : Status_T := Out_Of_Range) is record
       case Status is
       when Out_Of_Range =>
          null;
       when In_Range | Under_Min | Over_Max =>
          Temperature : Temperatures.Celsius_T;
       end case;
    end record;

(I expect someone will object that one should use the discriminant only 
to discriminate the variant forms (temperature available or not) and not 
to differentiate other status (temperature saturated or not). That is a 
valid philosophy, and I certainly consider that alternative when I 
design a variant record type, but I defend my right to use the above 
approach, too, when it suits me. :-)

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