Re: Record type with check?

["Nick Roberts" <nickroberts@callnetuk.com>]

I'd like to throw in a couple of thoughts.

First, although it is generally good to define abstract types to enforce the
properties expected, occasionally it is better not to, either because it
would be overkill for a simple program, or (very unusual) because it would
slow down the program too much.

The other thought is that you may need to consider solitaire and null
ranges. If you enforce A < B, you will not be able to have a range that
consists of one integer. Even if you enforce only A <= B, how will you
represent a null range? If your problem does not require solitaire or null
ranges, then this point might not matter; otherwise, it will!

One further, perhaps rather esoteric, thought. You may - possibly, but not
necessarily - find that it is better to define an abstract data type (ADT)
at a level higher than for type Datum. For example, you might find it better
to define an ADT for a Datum_List - which holds a list of ranges - and have
operations for it such as below.

   type Datum_List is limited private;

   procedure Delete_All (List: in out Datum_List); -- makes empty
   procedure Add_Datum (List: in out Datum_List; Lo, Hi: in Integer);

   procedure Restart (List: in out Datum_List);
   procedure Advance (List: in out Datum_List);
   function At_End (List: in Datum_List) return Boolean;
   function Lo (List: in Datum_List) return Integer;
   function Hi (List: in Datum_List) return Integer;

Here, it is the procedure Add_Datum which checks that Lo and Hi have
mutually acceptable values. The essence of this example is that the
abstraction is at the level of the list of data, rather than the individual
datum. Sometimes it makes sense to do this, and sometimes it doesn't,
depending on the problem and the circumstances of the program. You might
like to compare this example with the way complex numbers are handled within
Ada.Numerics.Generic_Complex_Types (see RM95 Annex G).

Good luck,

--
Nick Roberts
http://www.AdaOS.org