Another Idea for Ada 20XX

Another Idea for Ada 20XX

[James Rogers]

In scientific terms a measurement is done in terms of some unit.
For instance, distance is in meters, microns, feet or furlongs.
Speed is then calculated as a distance per unit time. Acceleration
is the second derivative of speed.

I would like to have this notion of measurement units and their
relationships supported in a language. This would require the language
to perform unit analysis while performing static or run-time 
calculations. Because of the added computational overhead, there must
be a way to choose or reject unit analysis for defined types.

Perhaps a new keyword for unit-analyzed types could be introduced,
along the lines of the keyword "tagged" added to Ada 95. A unit-
analyzed type would carry its own unit description tag to 
facilitate unit analysis. Any numeric type without such a tag
would not be subject to unit analysis.

Possible declarative syntax might be:

type Meters is unit range (0.0..1.0E380);
type Hours is unit range (0.0..9.99E30);
type Speed is unit(Meters / Hours);

The advantage for the software developer is in the usage:

Vehicle_Speed : Speed;
Track_Distance : Meters;
Lap_Time : Hours;

Speed := Track_Distance / Lap_Time;

This approach would allow the appropriate mixing of data types, which
is currently forbidden by Ada, in a meaningful and correct manner.

I know this proposal places a heavy burden upon compiler writers.
I also suspect it would be very useful for ensuring the correctness
of programs, particularly in embedded systems. 

Note that a lot of the unit analysis could be performed statically.
This would allow minimal performance penalty at run time.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Preben Randhol]

On Sun, 02 Dec 2001 16:01:22 GMT, James Rogers wrote:
> type Meters is unit range (0.0..1.0E380);
> type Hours is unit range (0.0..9.99E30);
> type Speed is unit(Meters / Hours);

Shouldn't these also be allowed to be negative?

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: Another Idea for Ada 20XX

[Patrick Hohmeyer]

James Rogers wrote :

> In scientific terms a measurement is done in terms of some unit.
> For instance, distance is in meters, microns, feet or furlongs.
> Speed is then calculated as a distance per unit time. Acceleration
> is the second derivative of speed.

Acceleration is the second derivative of *distance*. ;-)

> The advantage for the software developer is in the usage:
> 
> Vehicle_Speed : Speed;
> Track_Distance : Meters;
> Lap_Time : Hours;
> 
> Speed := Track_Distance / Lap_Time;
> 
> This approach would allow the appropriate mixing of data types, which
> is currently forbidden by Ada, in a meaningful and correct manner.
> 

Hmm, this can very easly be achived with overloading of "/" :

function "/" (Dist : Meters; Time : Hours) return Speed is
--...

And I have a huge problem with the name of the type Speed.
Speed is not a unit, but an concept.

Would be more interesting :

type Distance is basic concept with basic unit Meters;
type Time is basic concept with basic unit Seconds;
type Speed is concept (Distance / Time);

Vehicle_Speed : Speed; -- ok
Track_Distance1 : Meters; -- ok
Track_Distance2 : Meters := 12.5; -- ok
Lap_Time1 : Time; -- ok
Lap_Time2 : Time := Seconds(34.3); -- ok

Lap_Time3 : Time := 34.3; 
-- 2 possibles reactions :
-- 1. won't compile as the unit isn't specified !!! (my favor)
-- 2. uses the basic unit for the concept (Seconds)
--     (but generates a compiler warning)

Vehicle_Speed := Track_Distance1 / Lap_Time1; --ok

Internally a concept type would be something as
record
  Value : Double;
  Unit : Unit_type;
end record;

Unit somehow describes how we can transform the value
into a value in the basic units. (an access to a function?)
and vice-versa.

The great part are unit extentions :

type Hours is Time unit 3600 Seconds;

S : Seconds := 3954.3;
H : Hours := S;

And the compiler would automagicly put 3954.3 / 3600 into H.
As would the cast Hours(S) return 3954.3 / 3600;

Especially for Space programs between US and Europe this would
be a *huge* benefit.
Just declare :

type Inchs is Distance unit x Meters;

and the compiler will do all unit conversions for you.

And of course :
type Temperature is basic concept with basic unit Kelvin;
type Celsius is Temperature unit 1 Kelvin + 273.15;

And a non-basic concept : 
type Mass is basic concept with basic unit Kilogram;
type Acceleration is concept Speed / Time;
type Force is concept Mass * Acceleration;

type Newton is Force unit 1 (Kilogram * Meters * Seconds**(-2)); 
(Note that :
  type Newton is Force unit 1
  (Kilogram * Meters * Seconds**(-1) * Hours**(-1));
would also be syntaxly correct, you can mix 2 time units in a
composed unit.)

I think that this could be fun, but may be to complicated to
implement and if you really need it, can already be done with
a record and an access to fonction for the unit type,
and a lot of overloaded functions.

But what do you think ?

-- 
Patrick Hohmeyer

Re: Another Idea for Ada 20XX

[Lutz Donnerhacke]

* James Rogers wrote:
>In scientific terms a measurement is done in terms of some unit.
>For instance, distance is in meters, microns, feet or furlongs.
>Speed is then calculated as a distance per unit time. Acceleration
>is the second derivative of speed.

>Note that a lot of the unit analysis could be performed statically.
>This would allow minimal performance penalty at run time.

http://www.iks-jena.de/mitarb/lutz/ada/units/

I�m going to provide automatic unit optimization. Please stay tuned.

Re: Another Idea for Ada 20XX

[James Rogers]

Preben Randhol wrote:
> 
> On Sun, 02 Dec 2001 16:01:22 GMT, James Rogers wrote:
> > type Meters is unit range (0.0..1.0E380);
> > type Hours is unit range (0.0..9.99E30);
> > type Speed is unit(Meters / Hours);
> 
> Shouldn't these also be allowed to be negative?

Under certain circumstances units do make sense as negative values.

Sometimes they do not.

I simply tried to supply a possible syntax example, not all possible
examples.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Patrick Hohmeyer]

And Lutz Donnerhacke has spoken :

> * James Rogers wrote:
> >In scientific terms a measurement is done in terms of some unit.
> >For instance, distance is in meters, microns, feet or furlongs.
> >Speed is then calculated as a distance per unit time. Acceleration
> >is the second derivative of speed.
> 
> >Note that a lot of the unit analysis could be performed statically.
> >This would allow minimal performance penalty at run time.
> 
> http://www.iks-jena.de/mitarb/lutz/ada/units/
> 
> I�m going to provide automatic unit optimization. Please stay tuned.

Interesting approach, but at first glance I dont see how 
you'll solve the Celsius = Kelvin + 273.15 problem.

This solution seams only to work with units where zero in one unit
equals zero in the other as well.

I think an approach :

type Conversion is access function(value : Accuracy) return Accuracy;

type Unit_Description is record
      toSI : Conversion;
      fromSI : Conversion;
      -- some text ???
end record;

type Quantity is tagged record
      value : Accuracy;
      Unit : Unit_Description;
end record;

offers more flexibility than your idea of a Dimension.

-- 
Patrick Hohmeyer

RE: Another Idea for Ada 20XX

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: James Rogers et al.
A package to do this, A Broad-Based Environment for Test (ABBET), was
created by William A Whitaker, Ph.D. There is also a collection of packages
by Dmitry A. Kazakov.

I believe that it might be possible to have either the compiler optimize
away the unit checking for objects where the units are constant and/or
create a class of assertions that are only checked at compile time. Fresh
ideas on this subject should have a high priority for Ada 200X.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of James Rogers
Sent: Sunday, December 02, 2001 8:01 AM
To: comp.lang.ada@ada.eu.org
Subject: Another Idea for Ada 20XX


In scientific terms a measurement is done in terms of some unit.
For instance, distance is in meters, microns, feet or furlongs.
Speed is then calculated as a distance per unit time. Acceleration
is the second derivative of speed.

I would like to have this notion of measurement units and their
relationships supported in a language. This would require the language
to perform unit analysis while performing static or run-time
calculations. Because of the added computational overhead, there must
be a way to choose or reject unit analysis for defined types.

Perhaps a new keyword for unit-analyzed types could be introduced,
along the lines of the keyword "tagged" added to Ada 95. A unit-
analyzed type would carry its own unit description tag to
facilitate unit analysis. Any numeric type without such a tag
would not be subject to unit analysis.

Possible declarative syntax might be:

type Meters is unit range (0.0..1.0E380);
type Hours is unit range (0.0..9.99E30);
type Speed is unit(Meters / Hours);

The advantage for the software developer is in the usage:

Vehicle_Speed : Speed;
Track_Distance : Meters;
Lap_Time : Hours;

Speed := Track_Distance / Lap_Time;

This approach would allow the appropriate mixing of data types, which
is currently forbidden by Ada, in a meaningful and correct manner.

I know this proposal places a heavy burden upon compiler writers.
I also suspect it would be very useful for ensuring the correctness
of programs, particularly in embedded systems.

Note that a lot of the unit analysis could be performed statically.
This would allow minimal performance penalty at run time.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Robert Dewar]

James Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3C0A5054.E74A82E7@worldnet.att.net>...
> I would like to have this notion of measurement units and > their relationships supported in a language.

James, if you are interested in proposing something here,
you need first to do some homework. This subject has been
*extensively* discussed in the past, including the analysis
and discussion of several different schemes for getting units analysis
of the kind you are proposing within the
current language.

I suggest you study these existing schemes first, to see
whether

a) they meet your requirements
b) if they do not, exactly why not

There have also been proposals for language extensions
that have been thoroughly discussed in the past, and you
should dig up these discussions.

I realize that there are many new players on CLA who don't
necesarily have the history here, but this is definitely an area where
it makes no sense to start another discussion
from scratch.

Re: Another Idea for Ada 20XX

[James Rogers]

Robert Dewar wrote:
> 
> James, if you are interested in proposing something here,
> you need first to do some homework. This subject has been
> *extensively* discussed in the past, including the analysis
> and discussion of several different schemes for getting units analysis
> of the kind you are proposing within the
> current language.

Thank you for the notice. I hoped that someone had already done work
in this area. 

I will look into the histories as well as current language proposals.

Again, thank you.

> I realize that there are many new players on CLA who don't
> necesarily have the history here, but this is definitely an area where
> it makes no sense to start another discussion
> from scratch.

Jim Rogers
Colorado Springs, Colorado USA

Re: Another Idea for Ada 20XX

[Wilhelm Spickermann]

--On Sunday, December 02, 2001 18:49:24 -0500 Patrick Hohmeyer 
<pi3_1415926536@yahoo.ca> wrote:

> Interesting approach, but at first glance I dont see how
> you'll solve the Celsius = Kelvin + 273.15 problem.
>
> This solution seams only to work with units where zero in one
> unit equals zero in the other as well.

This problem is not a programming problem -- and it has been 
solved already.

Units in physics may not carry any offset information as they 
are not capable to do this. Doing it would destroy the 
fundamental concept of equality being a replacement permission: 
"The outside temperature is 10 degrees celsius, that´s 10 
degrees celsius less than the temperature of my room.". If 10 
Degrees Celsius would be equal to 283.15 Kelvin, it would have 
to be possible to replace *both* occurences. Giving: "The 
outside temperature is 283.15 Kelvin, that´s 283.15 Kelvin less 
than the temperature of my room." Wow, too hot for me.

The solution is (IFAIR it´s from the International Conference on 
Measurements and Units... in 1972): "The temperature is 10 
Degrees Celsius" is just a lax abbreviation for: "The 
celsiustemperature is 10 Kelvin". So it´s a different physical 
value with the same unit and not the same physical value with a 
different unit. Note that the conversion between celsius 
temperature and absolute temperature can now be expressed in a 
simple equation: TC = TA + 273.15 K

The same holds for pseudo units like the old german "atü" (car 
tires) and "Vss"(TV electronics).

So it´s not a problem of unit conversion, but a problem occuring 
in the user interface, where you will have to deal with pseudo 
units.

Wilhelm

Re: Another Idea for Ada 20XX

[Lutz Donnerhacke]

* Patrick Hohmeyer wrote:
>And Lutz Donnerhacke has spoken :
>> I�m going to provide automatic unit optimization. Please stay tuned.
>
>Interesting approach, but at first glance I dont see how 
>you'll solve the Celsius = Kelvin + 273.15 problem.

Calculation is only possible in SI.

>I think an approach :
[Conversion]

Work in progress. But using a sligthly different approach. A new html
version is only generated if the program runs all the tests successfully.

Re: Another Idea for Ada 20XX

[Dirk Dickmanns]

James Rogers schrieb:

> I will look into the histories as well as current language proposals.

Besides the work of Lutz, I have:
http://users.erols.com/whitaker/iss_418.htm
http://www.dmitry-kazakov.de/ada/units.htm

Regards,

Dirk

-- 
Dirk.Dickmanns@BMW.de, Dr.rer.nat. xx49-89-382-46422, Fax -44988
Computer Vision and Sensor Data Fusion
BMW Group, Vehicle Research, EV-20, D-80788 Munich

Re: Another Idea for Ada 20XX

[Thomas Koenig]

Patrick Hohmeyer  <pi3_1415926536@yahoo.ca> wrote:
>And Lutz Donnerhacke has spoken :

>> I�m going to provide automatic unit optimization. Please stay tuned.

>Interesting approach, but at first glance I dont see how 
>you'll solve the Celsius = Kelvin + 273.15 problem.

I don't think that this is a problem that wants solving as badly as
the case of normal units.

Define Celsius as a separate type, and provide conversion functions
to and from Kelvin.

Re: Another Idea for Ada 20XX

[Mark Lundquist]

Yes.  Units do need to be primitive.

I've been thinking about this for a while too, but haven't had the chance to
write it up.  The idea frankly never occurred to me until Ehud suggested it
in a post a few months back.  At first I thought "that's nuts".  But it
isn't :-)...

We now have type-safe programming in Ada.  But there are two things wanting:
(1) unit-safe programming, and (2) automatic unit conversion.  These cannot
be provided without augmenting the language.  (Note: "automatic" does not
mean "implicit", it means the compiler does the work for you).

This would really complete Ada's support for scalar abstraction.

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3C0A5054.E74A82E7@worldnet.att.net...
>
[snip...]
>
> Possible declarative syntax might be:
>
> type Meters is unit range (0.0..1.0E380);
> type Hours is unit range (0.0..9.99E30);

Something like that.  I don't think this is going to cut it, but you're on
the right track....  Unit declarations need to be independent of types.
Then a dimensioned type would be created by combining a unit with a
representation later on, in the type definition.  You need to defer the
"binding" of a type to a unit in order to achieve the right level of
abstraction.

> type Speed is unit(Meters / Hours);

I think the correct approach would involve declaring a unit (but not a type)
in terms of Meters and Hours (in your example).  The programmer would want
to call this unit "Meters_Per_Hour", not "Speed".

Mark Lundquist

Re: Another Idea for Ada 20XX

[Lutz Donnerhacke]

* Mark Lundquist wrote:
>> type Speed is unit(Meters / Hours);
>
>I think the correct approach would involve declaring a unit (but not a type)
>in terms of Meters and Hours (in your example).  The programmer would want
>to call this unit "Meters_Per_Hour", not "Speed".

I beg to differ.

Re: Another Idea for Ada 20XX

[chris.danx]

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:KoMO7.2339$Px.45566@rwcrnsc54...
>
> Yes.  Units do need to be primitive.
>
> I've been thinking about this for a while too, but haven't had the chance
to
> write it up.  The idea frankly never occurred to me until Ehud suggested
it
> in a post a few months back.  At first I thought "that's nuts".  But it
> isn't :-)...
>
> We now have type-safe programming in Ada.  But there are two things
wanting:
> (1) unit-safe programming, and (2) automatic unit conversion.  These
cannot
> be provided without augmenting the language.  (Note: "automatic" does not
> mean "implicit", it means the compiler does the work for you).
>
> This would really complete Ada's support for scalar abstraction.
>
> "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:3C0A5054.E74A82E7@worldnet.att.net...
> >
> [snip...]
> >
> > Possible declarative syntax might be:
> >
> > type Meters is unit range (0.0..1.0E380);
> > type Hours is unit range (0.0..9.99E30);
>
> Something like that.  I don't think this is going to cut it, but you're on
> the right track....  Unit declarations need to be independent of types.



> Then a dimensioned type would be created by combining a unit with a
> representation later on, in the type definition.  You need to defer the
> "binding" of a type to a unit in order to achieve the right level of
> abstraction.

> > type Speed is unit(Meters / Hours);
>
> I think the correct approach would involve declaring a unit (but not a
type)
> in terms of Meters and Hours (in your example).  The programmer would want
> to call this unit "Meters_Per_Hour", not "Speed".

Dimensionality Checking (Ada 20XX)

[Nick Roberts]

I really like this idea. I'd like to throw in a suggestion.

I think probably the facility should only be applied to fixed-point types.
All floating-point types would remain 'undimensioned' and there would be
conversions and other operations between all floating-point, integer, and
fixed-point types as usual (whose results would be undimensioned).

There would be a new package, Ada.Physics, in which the following types and
constants would be declared:

   type Physical_Dimension is (Mass, Distance, Time);

   type Dimensionality is array (Physical_Dimension) of Integer;

   Meter_Dimensionality: constant Dimensionality := (1,0,0);
   Metre_Dimensionality: constant Dimensionality := (1,0,0);

   Second_Dimensionality: constant Dimensionality := (0,0,1);
   -- etc.

A programmer may then construct a package with unit declarations appropriate
to a specific application domain, e.g.:

   package My_Physics is

      Foot_Dimensionality:
         constant Ada.Physics.Dimensionality := (1,0,0);

      generic
         type Feet is delta <>;
         type Meters is delta <>;
      function Generic_Feet_to_Meters (X: in Feet) return Meters;
      pragma Inline(Generic_Feet_to_Meters);

      -- etc.

   end;

Then, in application code, the following could be used:

   -- TURD: Traditional Ultrasonic Ranging Device

   type TURD_Distance is delta 17.0/16200 range 1.0/12 .. 17.0;
   -- in feet

   pragma Dimensionality
      ( Type_Name  => TURD_Distance,
        Dimensions => My_Physics.Foot_Dimensionality );

By supplying a Dimensionality pragma for the type T, dimension checking
would then be applied to the "+", "-", "*", "/", and "**" operations of T as
appropriate. The dimensionality of the result would be checked against: in
an assignment, the target object; for an actual parameter, the corresponding
formal. Of these operations, if either actual parameter (apart from the
righthand one of "**") is undimensioned, no check would be applied (and the
result is undimensioned). The checks would be entirely static. The pragma
must occur before the type is frozen. The value of the Dimensions parameter
must be static, and of type Ada.Physics.Dimensionality.

These facilities could be defined in an optional annex. If a program which
uses dimensionality checking were to be ported to a compiler which doesn't
support it, the program should still compile and work as before, except only
that the dimensionality checking would not be done.

I would suggest that scaling and offset are done using existing Ada
facilities.

--
Nick Roberts

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On Mon, 3 Dec 2001 21:13:38 -0000, "Nick Roberts"
<nickroberts@adaos.worldonline.co.uk> wrote:

>I really like this idea. I'd like to throw in a suggestion.
>
>I think probably the facility should only be applied to fixed-point types.
>All floating-point types would remain 'undimensioned' and there would be
>conversions and other operations between all floating-point, integer, and
>fixed-point types as usual (whose results would be undimensioned).
>
>There would be a new package, Ada.Physics, in which the following types and
>constants would be declared:
>
>   type Physical_Dimension is (Mass, Distance, Time);
>
>   type Dimensionality is array (Physical_Dimension) of Integer;
>
>   Meter_Dimensionality: constant Dimensionality := (1,0,0);
>   Metre_Dimensionality: constant Dimensionality := (1,0,0);
>
>   Second_Dimensionality: constant Dimensionality := (0,0,1);
>   -- etc.
>
>A programmer may then construct a package with unit declarations appropriate
>to a specific application domain, e.g.:
>
>   package My_Physics is
>
>      Foot_Dimensionality:
>         constant Ada.Physics.Dimensionality := (1,0,0);
>
>      generic
>         type Feet is delta <>;
>         type Meters is delta <>;
>      function Generic_Feet_to_Meters (X: in Feet) return Meters;
>      pragma Inline(Generic_Feet_to_Meters);
>
>      -- etc.
>
>   end;
>
>Then, in application code, the following could be used:
>
>   -- TURD: Traditional Ultrasonic Ranging Device
>
>   type TURD_Distance is delta 17.0/16200 range 1.0/12 .. 17.0;
>   -- in feet
>
>   pragma Dimensionality
>      ( Type_Name  => TURD_Distance,
>        Dimensions => My_Physics.Foot_Dimensionality );
>
>By supplying a Dimensionality pragma for the type T, dimension checking
>would then be applied to the "+", "-", "*", "/", and "**" operations of T as
>appropriate. The dimensionality of the result would be checked against: in
>an assignment, the target object; for an actual parameter, the corresponding
>formal. Of these operations, if either actual parameter (apart from the
>righthand one of "**") is undimensioned, no check would be applied (and the
>result is undimensioned).

There are two different "undimensioned" in your system: a) ones with
no paragma Dimensionality applied and b) ones with

   pragma Dimensionality  (Dimensions=>(others=>0));

Then:
                 case b      case a
2*2m            4               4m
2+2m        illegal            4
2m**2        4sqm          4sqm
2**2m       illegal            4

Anyway you should invent some rules for literals of dimensioned types.
Will you apply pragma Dimensionality to literals depending on the
context?

>The checks would be entirely static. The pragma
>must occur before the type is frozen. The value of the Dimensions parameter
>must be static, and of type Ada.Physics.Dimensionality.

Static unit checks would efficiently exclude "class-wide" operations
on dimensioned values like 'Value, 'Image, 'Read etc. There is IMO an
obvious analogy between dimensionality and both type tags and
discriminants. I think that there should be possible to have both
constrained (=fixed dimension) and unconstrained (class-wide) subtypes
and instances of dimensioned types. Constrained ones should be checked
at compile time the same way as String (1..3) is checked when "abc" is
assigned.

If Ada should support dimensioned types, then I think that it should
do it using the existing paradigms. As I see it there could be two
approaches: a hard-wired implementation of dimensioned units as many
have proposed and a more complicated way based on an ability to have
compile-time user-defined subroutines defined on type tags and/or
discriminants. I believe it is worth to think (for Ada 2100 (:-))
about the "more compilcated" approach because the pattern of
dimensioned units is quite wide spread. For instance, it could well be
used for matrix/vector types etc.

>These facilities could be defined in an optional annex. If a program which
>uses dimensionality checking were to be ported to a compiler which doesn't
>support it, the program should still compile and work as before, except only
>that the dimensionality checking would not be done.
>
>I would suggest that scaling and offset are done using existing Ada
>facilities.

To which of the following two types would you apply

pragma Dimensionality (Dimensions=>Second_Dimensionality);

1. Ada.Calendar.Time
2. Standard.Duration

(:-))

Regards,
Dmitry Kazakov

Unit handling (was: Another Idea for Ada 20XX)

[Wilhelm Spickermann]

--On Monday, December 03, 2001 13:34:09 +0100 Dirk Dickmanns 
<Dirk.Dickmanns@BMW.de> wrote:

...
> Besides the work of Lutz, I have:
> http://users.erols.com/whitaker/iss_418.htm
> http://www.dmitry-kazakov.de/ada/units.htm
>

May I add some of my ideas here? They could be realized as an 
optional ASIS program checker or as a compiler component and 
would not have any execution time penalty or require the tools 
to be available to do the compilation. As unit consistency is a 
program property, it´s not really necessary to have the tool on 
every platform and every site.

The idea is to define the basic SI-Units as named numbers with 
value 1.0 and using values like "5.7 * meter / second" in the 
program. (The compiler can easily optimize such expressions.)

A pragma for use by ASIS (or the compiler) defines which Units 
are to be viewed as basic.

Every variable, constant, parameter or named number will be 
associated with a derived unit upon the first assignment seen, 
by tracking the operations down to the basic units and all 
following assignments will be required to lead to the same 
result. Additionally all operations will be checked for 
consistency. (As others have already pointed out, there are not 
too many operations to be considered, as operations like taking 
the logarithm of something can never be applied to something 
having a unit)

An additional ASIS-pragma can assign a derived unit to a 
variable or parameter where the unit is not associated 
implicitly by an initial or default value.

A first sketch using SI as an example:

package Units is
   --  The 7 SI units:
   Meter : constant := 1.0;
   ...
   pragma Define_Unit (Meter, Kilogram, Second, Ampere,
                       Kelvin, Candela, Mole);
   ...
   --  SI derived units:
   Newton : constant := Meter * Kilogram / Second**2;
   ...
   --  SI accepted derived units:
   Liter : constant := 1.0e-3 * Meter**3;
   ...
end Units;

(No special handling for the child units needed, they just 
collect some definitions and try to convince programmers, that 
that it´s a bad idea to define a factor "Billion" etc.)

package Units.More is
   --  Defined (not experimentally determined) units.
   Foot : constant := 0.3048 * Meter;
   Foot_US_Survey : constant := Foot / 0.999998;
   ...
   --  experimentally determined units / constants
   Electron_Volt : constant := 1.602_177_33e-19 * Joule;
   ...
end Units.More;

package Units.Factors is
   ...
   Kilo  : constant := 1.0E3;
   ...
   Billion_US_FR : constant := 1.0E9;
   Billion_OTH : constant  := 1.0E12;
   ...
   Kilo_Binary : constant := 2.0**10;
   ...
end Units.Factors;

I think this notation is readable and could be helpful even 
without any tool to do the checks. It does not create any 
runtime penalties. It should be possible to implement the 
checker in ASIS or as an additional compiler component which may 
be switched on or off. It´s not meant as a proposal for Ada 
20XX, but if someone  would like to view it as one: it would 
only introduce conflicts in the two new pragma names.

(It will however not be able to handle units like "decibels" or 
"degrees celsius". I view these as pseudo units which only make 
mathematical reasoning impossible. They should occur only in the 
user interface as common expressions, but I´ve written that in 
another mail.)

Wilhelm

Re: Dimensionality Checking (Ada 20XX)

[Britt Snodgrass]

Perhaps this is not a new proposal but it seems to me that units
(dimensionality) in Ada code would be most naturally implemented as
attributes of objects or types.  The units of an object or type would
be specified with a representation clause.  If unspecified, the unit
attribute would default to "null" (no units).  The compiler could then
enforce unit consistency during compilation or generate runtime unit
checking code.

For example:

with Ada.Text_IO;

with Ada.Dimensionality.ISO_Metric_Units; 
-- predefined for kilograms, meters, etc.
 
with Ada.Dimensionality.My_User_Defined_Units
-- parsecs_per_picosecond, etc.

use  Ada.Dimensionality;

package body Proposed_Unit_Syntax_Example is

   type Magnitude is digits 15;

   Delta_Position : Magnitude;
   for Delta_Position'Unit use ISO_Metric_Units.Meter;

   Delta_Time : Magnitude;
   for Delta_Time'Unit use ISO_Metric_Units.Second;

   Current_Speed : Magnitude;
   for Current_Speed'Unit use 
     ISO_Metric_Units.Meter / ISO_Metric_Units.Second;

   Accel : Magnitude;
   for Accel'Unit use
     ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
     -- note use of operators in attribute definition.

begin

   Delta_Position := 500.0;  -- meters implied by unit attribute

   Delta_Interval := 10.0;  -- seconds implied by unit attribute

   Current_Speed := Delta_Position / Delta_Interval;
   -- OK, units match

   Current_Speed := Delta_Position / Delta_Interval**2;
   -- won't compile or raises a predefined Unit_Error exception;

exception

   when Unit_Error =>
      Ada.Text_IO.Put_Line
        ("Oops! I just passed Mars without stopping to orbit!");

end Proposed_Unit_Syntax_Example;


Since all of the variables in this example are of the same type, no
new arithmetic operators need to be defined.  However the compiler
would use the unit attributes to ensure that any resulting right-side
composite unit matches the left-side unit before allowing an
assignment to proceed.  Most unit inconsistencies would be caught
during compilation. If a unit mismatch can't be caught until runtime,
then a predefined Unit_Error exception would be raised (unless the
code had been compiled with Pragma Suppress (Unit_Checks) ).

Britt Snodgrass

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

In my post, I mentioned the idea of specifying units and their relationships
independent of types, then somehow "binding" units to types.  At first
glance, your idea seems promising for the "binding" part.  Very nice.  I
hadn't thought of using attributes for this, and as you say it is a natural
notation for Ada.

-- mark


"Britt Snodgrass" <britt@adapower.net> wrote in message
news:36c6f8dd.0112061152.333c9de@posting.google.com...
> Perhaps this is not a new proposal but it seems to me that units
> (dimensionality) in Ada code would be most naturally implemented as
> attributes of objects or types.  The units of an object or type would
> be specified with a representation clause.  If unspecified, the unit
> attribute would default to "null" (no units).  The compiler could then
> enforce unit consistency during compilation or generate runtime unit
> checking code.
>
> For example:
>
> with Ada.Text_IO;
>
> with Ada.Dimensionality.ISO_Metric_Units;
> -- predefined for kilograms, meters, etc.
>
> with Ada.Dimensionality.My_User_Defined_Units
> -- parsecs_per_picosecond, etc.
>
> use  Ada.Dimensionality;
>
> package body Proposed_Unit_Syntax_Example is
>
>    type Magnitude is digits 15;
>
>    Delta_Position : Magnitude;
>    for Delta_Position'Unit use ISO_Metric_Units.Meter;
>
>    Delta_Time : Magnitude;
>    for Delta_Time'Unit use ISO_Metric_Units.Second;
>
>    Current_Speed : Magnitude;
>    for Current_Speed'Unit use
>      ISO_Metric_Units.Meter / ISO_Metric_Units.Second;
>
>    Accel : Magnitude;
>    for Accel'Unit use
>      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
>      -- note use of operators in attribute definition.
>
> begin
>
>    Delta_Position := 500.0;  -- meters implied by unit attribute
>
>    Delta_Interval := 10.0;  -- seconds implied by unit attribute
>
>    Current_Speed := Delta_Position / Delta_Interval;
>    -- OK, units match
>
>    Current_Speed := Delta_Position / Delta_Interval**2;
>    -- won't compile or raises a predefined Unit_Error exception;
>
> exception
>
>    when Unit_Error =>
>       Ada.Text_IO.Put_Line
>         ("Oops! I just passed Mars without stopping to orbit!");
>
> end Proposed_Unit_Syntax_Example;
>
>
> Since all of the variables in this example are of the same type, no
> new arithmetic operators need to be defined.  However the compiler
> would use the unit attributes to ensure that any resulting right-side
> composite unit matches the left-side unit before allowing an
> assignment to proceed.  Most unit inconsistencies would be caught
> during compilation. If a unit mismatch can't be caught until runtime,
> then a predefined Unit_Error exception would be raised (unless the
> code had been compiled with Pragma Suppress (Unit_Checks) ).
>
> Britt Snodgrass

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

Britt Snodgrass wrote:
> (dimensionality) in Ada code would be most naturally implemented as
> attributes of objects or types.  The units of an object or type would
> be specified with a representation clause.  If unspecified, the unit

I think this is a very good idea.  But now to nitpick:

>    Accel : Magnitude;
>    for Accel'Unit use
>      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;

In some cases, might there be multiple ways to describe
the units?   Speed is Acceleration * Time but it is also
Distance / Time.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Wes Groleau" <wgroleau@usa.com> wrote in message
news:3C0FF376.2DC0C3E4@usa.com...
>
>
> Britt Snodgrass wrote:
> > (dimensionality) in Ada code would be most naturally implemented as
> > attributes of objects or types.  The units of an object or type would
> > be specified with a representation clause.  If unspecified, the unit
>
> I think this is a very good idea.  But now to nitpick:
>
> >    Accel : Magnitude;
> >    for Accel'Unit use
> >      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
>
> In some cases, might there be multiple ways to describe
> the units?   Speed is Acceleration * Time but it is also
> Distance / Time.

Right, which is why (a) the concepts of "unit" and of "dimension" need to be
loosely coupled (this is missing from the proposals I've seen so far), and
then (b) you have to distinguish between base and derived dimensions.

We normally think of Distance and Time as being "fundamental", so typically
we would declare these as base dimensions.  Then we declare the derived
dimension Rate = Distance / Time.  That's (a).

(b) says that Rate = Distance / Time no matter the units.

The dimensionality checking would be done in terms of base dimensions, so it
makes no difference "how you got there", e.g. in terms of derived
dimensions.

Best Regards,
Mark

Re: Dimensionality Checking (Ada 20XX)

[Dmitry A. Kazakov]

On 6 Dec 2001 11:52:12 -0800, britt@adapower.net (Britt Snodgrass)
wrote:

>Perhaps this is not a new proposal but it seems to me that units
>(dimensionality) in Ada code would be most naturally implemented as
>attributes of objects or types.  The units of an object or type would
>be specified with a representation clause.  If unspecified, the unit
>attribute would default to "null" (no units).  The compiler could then
>enforce unit consistency during compilation or generate runtime unit
>checking code.
>
>For example:
>
>with Ada.Text_IO;
>
>with Ada.Dimensionality.ISO_Metric_Units; 
>-- predefined for kilograms, meters, etc.
> 
>with Ada.Dimensionality.My_User_Defined_Units
>-- parsecs_per_picosecond, etc.
>
>use  Ada.Dimensionality;
>
>package body Proposed_Unit_Syntax_Example is
>
>   type Magnitude is digits 15;
>
>   Delta_Position : Magnitude;
>   for Delta_Position'Unit use ISO_Metric_Units.Meter;
>
>   Delta_Time : Magnitude;
>   for Delta_Time'Unit use ISO_Metric_Units.Second;
>
>   Current_Speed : Magnitude;
>   for Current_Speed'Unit use 
>     ISO_Metric_Units.Meter / ISO_Metric_Units.Second;
>
>   Accel : Magnitude;
>   for Accel'Unit use
>     ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
>     -- note use of operators in attribute definition.
>
>begin
>
>   Delta_Position := 500.0;  -- meters implied by unit attribute
>
>   Delta_Interval := 10.0;  -- seconds implied by unit attribute
>
>   Current_Speed := Delta_Position / Delta_Interval;
>   -- OK, units match
>
>   Current_Speed := Delta_Position / Delta_Interval**2;
>   -- won't compile or raises a predefined Unit_Error exception;
>
>exception
>
>   when Unit_Error =>
>      Ada.Text_IO.Put_Line
>        ("Oops! I just passed Mars without stopping to orbit!");
>
>end Proposed_Unit_Syntax_Example;
>
>
>Since all of the variables in this example are of the same type, no
>new arithmetic operators need to be defined.  However the compiler
>would use the unit attributes to ensure that any resulting right-side
>composite unit matches the left-side unit before allowing an
>assignment to proceed.  Most unit inconsistencies would be caught
>during compilation. If a unit mismatch can't be caught until runtime,
>then a predefined Unit_Error exception would be raised (unless the
>code had been compiled with Pragma Suppress (Unit_Checks) ).

I would also prefer a representation clause over rather obscure
pragmas, but the question stands: how to do class-wide unit
programming? For instance, how to write [non-generic] subprogram
IntegrateTime which takes <unit>/s and returns <unit>? How to write a
subprogram that gets user input from a dialog field and returns some
dimensioned value?

Therefore I would prefer a solution based on discriminants or else
tags provided that the compiler will remove all extra data fields and
run-time checks in case when units are statically known.

Regards,
Dmitry Kazakov

Re: Dimensionality Checking (Ada 20XX)

[Wes Groleau]

Mark Lundquist wrote:
> 
> "Wes Groleau" <wgroleau@usa.com> wrote ....
> > >    Accel : Magnitude;
> > >    for Accel'Unit use
> > >      ISO_Metric_Units.Meter / ISO_Metric_Units.Second**2;
> >
> > In some cases, might there be multiple ways to describe
> > the units?   Speed is Acceleration * Time but it is also
> > Distance / Time.
> 
> Right, which is why (a) the concepts of "unit" and of "dimension" need to be
> loosely coupled (this is missing from the proposals I've seen so far), and
> then (b) you have to distinguish between base and derived dimensions.

I guess what I mean is that the compiler would have to have some smarts
to be able to figure out all the numerous ways of deriving a derived
dimension--including from other derived dimensions.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Britt Snodgrass" <britt@adapower.net> wrote in message
news:36c6f8dd.0112061152.333c9de@posting.google.com...
>
> Most unit inconsistencies would be caught
> during compilation. If a unit mismatch can't be caught until runtime,
> then a predefined Unit_Error exception would be raised (unless the
> code had been compiled with Pragma Suppress (Unit_Checks) ).

Well, I would think that unit checking would be *entirely* a compile-time
phenomenon.  Can you think of any reason why it would not be?

Also... you want to set up the proposed feature so that it can be defined
without touching the conformance rules in any way, which means that at some
point you "bury" the units in the type and then don't think about them any
more.  That point is the application of the 'Unit representation clause in
your scheme.  Assuming this, then the check that actually takes place is
just the normal type check, which of course is fully static (except for
tagged types, but the reasons for that are completely unrelated and do not
apply to scalars).

Cheers,
Mark