From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f822ae7b0f7433c1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news.glorb.com!news.banetele.no!uio.no!fi.sn.net!newsfeed1.fi.sn.net!news.song.fi!not-for-mail Date: Thu, 18 Jan 2007 23:25:58 +0200 From: Niklas Holsti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Translating an embedded C algorithm References: <1168871816.263502.212100@11g2000cwr.googlegroups.com> <45acc0c3$0$22514$39db0f71@news.song.fi> <45af9c60$0$22524$39db0f71@news.song.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <45afe4a6$0$22512$39db0f71@news.song.fi> Organization: TDC Song Internet Services NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1169155239 news.song.fi 22512 81.17.205.61:32902 X-Complaints-To: abuse@song.fi Xref: g2news2.google.com comp.lang.ada:8281 Date: 2007-01-18T23:25:58+02:00 List-Id: 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 . @ .