Re: Dimensionality Checking (Ada 20XX)

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

I'm liking this idea a lot!

Supposing the revision adds a package:


   package Ada.Units

      type Unit_Type is private;

      Unitless : constant Unit_Type;

      Meter    : constant Unit_Type;
      Kilogram : constant Unit_Type;
      Second   : constant Unit_Type;
      Ampere   : constant Unit_Type;
      Kelvin   : constant Unit_Type;
      Mole     : constant Unit_Type;
      Candela  : constant Unit_Type;

      function Is_Unitless (The_Unit: in Unit_Type) return Boolean;

      function "*" (Left, Right: Unit_Type) return Unit_Type;
      function "/" (Left, Right: Unit_Type) return Unit_Type;

      function "**" (Left: Unit_Type; Right: Integer) return Unit_Type;

      function "*" (Left: Unit_Type; Right: universal_real) return
Unit_Type;
      function "*" (Left: universal_real; Right: Unit_Type) return
Unit_Type;
      function "/" (Left: Unit_Type; Right: universal_real) return
Unit_Type;
      function "/" (Left: universal_real; Right: Unit_Type) return
Unit_Type;

   end Ada.Units;


We can declare our own units, e.g.:


   Foot: constant Ada.Units.Unit_Type := Meter * 0.3048;


Then we can declare a 'unit-specific' (fixed-point) type:


   type Accelerometer_Reading is
      delta 0.02 range -4.7 .. +4.7 unit Foot/Second**2;


This form has the problem of introducing a new reserved word ("unit"), but I
feel this is more appropriate, since the unit is an aspect of the 'key
abstraction' of the type (rather than just a matter of implementation or
checking). Fixed-point types could nevertheless have an attribute Unit (with
the special dispensation for reserved words accorded Range etc).

If we then declared e.g.:


   type Acceleration is
      delta 0.01 range -50.0 .. +50.0 unit Meter/Second**2;

   Reading: Accelerometer_Reading;
   Rate_of_Ascent: Acceleration;


we could convert from one type to another the normal way:


   Rate_of_Ascent := Acceleration(Reading);


which would cause a scaling multiplication (if necessary). Furthermore, view
conversions work perfectly:


   procedure Adjust_for_Wind (RoA: in out Acceleration);

   ...

   Adjust_for_Wind(Acceleration(Reading));


The appropriate scaling is performed for the variable Reading on the way in
and (the inverse scaling) on the way out.

Possibly one advantage of this scheme is that a compiler could opt out of
doing the dimension checking without causing any problem (other than the
actual lack of checking, of course!).

The standard type Duration could be declared:


   type Duration is delta ... range ... unit Ada.Units.Second;


Fixed-point types without the 'unit' part in the declaration would default
to being 'unitless'. Predefined operations between a unitless fixed-point
type and a unit-specific one would work as currently, with no dimension
checking, and the reult would also be unitless. This would be vital for
maintaining code continuity, of course, but also I suspect that unitless
fixed-point types would continue to have a vital role as intermediary types
for calculation and other processing.

I don't believe unit specification (and therefore dimension checking) is
applicable to floating-point types. They may be used for various purposes
(perhaps often when a fixed-point type ought to be used), but a
floating-point number is conceptually a ratio, and therefore implicitly
unitless (and dimension-indeterminate). If they are used for intermediate
calculations, that's too bad (a good programmer will take extra precautions
if practicable).

There's the question of private types. I feel that the requisite conversions
and other mixed operations should be provided for a private type explicitly
(in its package spec), and that these operations should do the requisite
conversion and checking, which may well be more complicated than mere
scaling and dimensionality. The unit facilities would, of course, be
applicable to those components which were of unit-specific (fixed-point)
types.

Three further notes need to be made.

(1) I am not sure if the (seven) SI units I have presented are the complete
set of basic units required in reality.

(2) Dimensional analysis could extend (from the basic MLT) to temperature,
amount of matter, and electrical current. But I don't know if it would be
practical for these 'extra' dimensions (or any others) to be included in the
checking.

(3) I have not provided for units that are offset from the SI units' zero
points (which are presumably all at the corresponding 'physical' zero
point). I believe some other post suggested that this tends to be a fairly
cosmetic matter anyway.

--
Best wishes,
Nick Roberts