Re: Consider her way -- Re: Dimensionality Checking

Re: Consider her way -- Re: Dimensionality Checking

[Alexandre E. Kopilovitch]

"Mark Lundquist" <mlundquist2@attbi.com> wrote:
>>   Now let's recall the fact that the Ada is not a problem-oriented language,
>> but rather a "superassembler". It intentionally and carefully avoids all
>> paradigms that aren't closely related to the real computer architectures or
>> to the general software engineering, even if those paradigms are heavily used
>> in some significant application area. (Note that I'm speaking here about the
>> paradigms; the data representation issues are another matter, that is a natural
>> job for an assembler.)
>>   Obviously, the dimensionality paradigm is one of the kind that Ada avoids:
>> it belongs neither to a computer architecture nor to the general software
>> engineering, but to the particular application area, no matter how significant
>> it is in the real world. Therefore Ada most probably will not take any move
>> to support it directly.
>
>Well OK, but then how do you explain Ada's type system?
That facility corresponds to a major general software engineering paradigm.

>  If the language did not
>abstract types away from its own "machine model", then wouldn't we have
>C-style type-equivalence instead?
Certainly yes. 

>  Instead, in Ada we have the idea that
>"number of lines in a file" and "number of cows" can be different types.
>Isn't that pretty abstract for a "superassembler"?
Not at all. It is too abstract for an assembler (such as C, for example), but
Ada is a "superassembler", which facilitates dealing with the general software
engineering enviromnent, besides of the real computer architectures.

>>   The proper way to do the dimensional/unit analysis for the Ada programs is
>> to use the ASIS and some suitable language processor [snip...]
>
>For one thing, you would still have to code all of of your own unit conversions.
Why? Two distinct subtypes of the same type may be used together in an expression
without any conversion. Note, that I proposed to use the subtypes and not the
types for expressing of dimensionality.

>> following question: if X and X*X belong to the different types, how will you
>> treat (interpret) the usual approximations by the Taylor series?
>
>Well, I think you're almost right here... you don't have to think about
>Taylor series to see the problem.  The fundamental glitch is that
>unit-safety takes you from a numeric system that is closed under
>multiplication to one that is not.
In my opinion, the unit-safety may be based on the type system only for the
relatively simple situations, which is essentially linear. The typical example
of "apples and oranges" falls in that category.

>  Every expression in Ada has a value; if
>X is of a "dimensioned type" as we have been considering, then what is the
>type of the expression 'X * X'?  So you're right that in the "dimensioned
>type" approach there has to be some relationship between the types, but it
>would be absolutely wrong to co-opt subtyping for this.  For one, we want to
>save subtypes for what they are already used for (constraint checks);
Why "save"? You may use the subtypes for both purposes without any difficulty.
Moreover, these somtimes may be combined nicely; for example a subtype for the 
speed may have the range that corresponds to the maximal speed - either speed
of light, or (in a specific application) the speed of sound.

> but more fundamentally, it just does not make sense.  Given a subtype and a
>value, you can tell whether the value is in the subtype!
Well, but what is bad here for the dimensionality checking?

>  The subtype is not some abstract property of the object,
Even a subtype without a range? And what is it, in such a case?


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Consider her way -- Re: Dimensionality Checking

[Mark Lundquist]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008201902.27048.comp.lang.ada@ada.eu.org...
> "Mark Lundquist" <mlundquist2@nospam.com> wrote:
> >>   Obviously, the dimensionality paradigm is one of the kind that Ada
avoids:
> >> it belongs neither to a computer architecture nor to the general
software
> >> engineering, but to the particular application area, no matter how
significant
> >> it is in the real world. Therefore Ada most probably will not take any
move
> >> to support it directly.
> >
> >Well OK, but then how do you explain Ada's type system?
> That facility corresponds to a major general software engineering
paradigm.

But it has not always been so with strong typing.  I submit that it became
"general" because it was useful in practice and feasible for implementation
in a programming language.  I feel that unit-safety with automatic unit
conversion is a concept that is similarly useful and feasible.

>
> >  If the language did not
> >abstract types away from its own "machine model", then wouldn't we have
> >C-style type-equivalence instead?
> Certainly yes.
>
> >  Instead, in Ada we have the idea that
> >"number of lines in a file" and "number of cows" can be different types.
> >Isn't that pretty abstract for a "superassembler"?
> Not at all. It is too abstract for an assembler (such as C, for example),
but
> Ada is a "superassembler", which facilitates dealing with the general
software
> engineering enviromnent, besides of the real computer architectures.

I agree.  My position is, let's make it a little more "super" in this regard
(unit abstraction for numeric types).

>
> >>   The proper way to do the dimensional/unit analysis for the Ada
programs is
> >> to use the ASIS and some suitable language processor [snip...]
> >
> >For one thing, you would still have to code all of of your own unit
conversions.
> Why? Two distinct subtypes of the same type may be used together in an
expression
> without any conversion.

True, unfortunately for your scheme... if a quantity expressed in grams is
used in an expression where a quantity expressed in kilograms was meant, and
they are both the same type (because they are of the same dimensionality --
though they may be different subtypes, I expect for the benefit of your
checking metalanguage?), then no incompatibility is detected by the
compiler.  Notwithstanding the detection issue, to correct the
incompatibility you must run the value through a unit (scaling) conversion
(which I understand would not entail a type conversion in your scheme).
Where do these unit conversion functions come from?  They must be
hand-coded.

> In my opinion, the unit-safety may be based on the type system only for
the
> relatively simple situations, which is essentially linear. The typical
example
> of "apples and oranges" falls in that category.

I agree completely, in the context of trying to use the existing Ada typing
system to effect unit-safety and unit conversions.  These cannot be subsumed
by the current type system.  My proposal would be to build unit-awareness
into the type system.  That would completely change the outlook.  You would
not think of unit-safety as being "based on" the type system -- instead,
aspects of the semantics of the type system would be based on unit-safety!

Best regards,
-- mark

--
--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Re: Consider her way -- Re: Dimensionality Checking

[Alexandre E. Kopilovitch]

"Mark Lundquist" <no.spam@getalife.com> wrote:
>you have to hand-code all needed conversions for base
>and derived units (vs. defining them for a handful of base units).  Nor are
>they reversible, i.e. for interoperability between m and km I would have to
>write the conversion going each way rather than simply defining the
>relationship between them.

So you are going to introduce the explicit relationships between the types,
and some reduction rules for the statements such as
  Variable := Expression;
- right? Hmm, that will be a great job, substantial innovation, and will produce
a visible impact on the whole Ada core language. The applications of that new
feature surely will not be restricted to the unit conversions.

>> > in this regard (unit abstraction for numeric types).
>> By the way, I still don't see an abstraction here. How will you describe the
>> notion of unit as an abstraction? For example "a type is the set of possible
>> values and the set of operations" - and what is a unit?
>
>Well, what is a "value"? :-)

No problem. Let us be slightly more formal: "a type is an ordered pair of the
sets; the elements of the first set are called the values of this type; the
elements of the second set are subroutines, and they are called the operations
of this type".

>The concept of
>unit, like that of value, is not "definable" in the language, but that is
>not necessary.  You're getting all philosophical about it and making it
>harder than it really is :-).  But I certainly do see an abstraction in units...

In such a case, perhaps you are able to describe - more or less formally -
that abstraction, which you see here?


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Consider her way -- Re: Dimensionality Checking

[Dmitry A. Kazakov]

On Sat, 15 Dec 2001 05:24:53 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@vib.usr.pu.ru> wrote:

>>Well, what is a "value"? :-)
>
>No problem. Let us be slightly more formal: "a type is an ordered pair of the
>sets; the elements of the first set are called the values of this type; the
>elements of the second set are subroutines, and they are called the operations
>of this type".

>>The concept of
>>unit, like that of value, is not "definable" in the language, but that is
>>not necessary.  You're getting all philosophical about it and making it
>>harder than it really is :-).  But I certainly do see an abstraction in units...
>
>In such a case, perhaps you are able to describe - more or less formally -
>that abstraction, which you see here?

What about this:

Unit of a type is a sort of type tag. The operations +,-,*,/,** are
dispatching operations on tuples of arguments and the result
[=multiple dispatch]. Valid combinations produce a value. Invalid
combinations raise Unit_Error.

Regards,
Dmitry Kazakov

Re: Consider her way -- Re: Dimensionality Checking

[Alexandre E. Kopilovitch]

"Mark Lundquist" <no.spam@getalife.com> wrote:
>>>Ada's type system?
>> That facility corresponds to a major general software engineering paradigm.
>
>But it has not always been so with strong typing.  I submit that it became
>"general" because it was useful in practice and feasible for implementation
>in a programming language.  I feel that unit-safety with automatic unit
>conversion is a concept that is similarly useful and feasible.
I doubt that - the latter. The scaling, that is, employment of the different
units for the same magnitude in a program is a relatively rare case. And I
beleive that the general rule is that all magnitudes in a subroutine should be
uniform, that is, a certain unit must be selected for each magnitude, and all
values of that magnitude in the subroutine must be expressed using that selected
unit. Certainly, the values of the magnitude may come from the external sources
- the parameters and input streams, and those values may be expressed using
other units; in those cases the conversions should be performed at the boundaries:
all the arguments of a call must be converted to the units required by the
subroutime called (before or inside an invocation), and the incoming numbers
must be converted immediately.

>> Ada is a "superassembler", which facilitates dealing with the general software
>> engineering enviromnent, besides of the real computer architectures.
>
>I agree.  My position is, let's make it a little more "super"
I think that such additions may lead to Ada++.

> in this regard (unit abstraction for numeric types).
By the way, I still don't see an abstraction here. How will you describe the
notion of unit as an abstraction? For example "a type is the set of possible
values and the set of operations" - and what is a unit?

>> >>   The proper way to do the dimensional/unit analysis for the Ada programs is
>> >> to use the ASIS and some suitable language processor [snip...]
>> >
>> >For one thing, you would still have to code all of of your own unit conversions.
>> Why? Two distinct subtypes of the same type may be used together in an expression
>> without any conversion.
>
>True, unfortunately for your scheme... if a quantity expressed in grams is
>used in an expression where a quantity expressed in kilograms was meant, and
>they are both the same type (because they are of the same dimensionality --
>though they may be different subtypes, I expect for the benefit of your
>checking metalanguage?), then no incompatibility is detected by the
>compiler.  Notwithstanding the detection issue, to correct the
>incompatibility you must run the value through a unit (scaling) conversion
>(which I understand would not entail a type conversion in your scheme).
>Where do these unit conversion functions come from?  They must be
>hand-coded.
Yes, surely, they must be hand-coded. But as I said above, there are only two
kinds of places where those conversions are needed - at the subroutine calls
and after input statements. I do not think that the probability of an error
there is substantially higher that the probability of a mistake within a
declaration of the "unit-aware types".

>My proposal would be to build unit-awareness
>into the type system.  That would completely change the outlook.  You would
>not think of unit-safety as being "based on" the type system -- instead,
>aspects of the semantics of the type system would be based on unit-safety!
In my opinion, the main underlying problem with units is that they are all
relative. There is no absolute unit for a distance, as well as for time,
mass, resistance etc. And the abstractions for a relativities usually appear
to be quite complex things. Therefore it is difficult to believe that such
a thing may simplify or somehow facilitate real programmimg.

  The principal difference between the dimensionality and the units is that
it is very often necessary to mix the variables of different dimensionality
in a formulae, while a mix of different units (of the same dimensionality) is
a nonsense.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Consider her way -- Re: Dimensionality Checking

[Wes Groleau]

"Alexandre E. Kopilovitch" wrote:
>   The principal difference between the dimensionality and the units is that
> it is very often necessary to mix the variables of different dimensionality
> in a formulae, while a mix of different units (of the same dimensionality) is
> a nonsense.

I disagree.  We recently had a discussion of the problems
caused by mixing feet and meters.  A language feature that
either prevents that or causes it to get the right answer
would be a Good Thing.

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

Re: Consider her way -- Re: Dimensionality Checking

[Mark Lundquist]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008344102.3072.comp.lang.ada@ada.eu.org...
> "Mark Lundquist" <no.spam@getalife.com> wrote:
> >
> > I feel that unit-safety with automatic unit
> > conversion is a concept that is similarly useful and feasible.
>
> I doubt that - the latter. The scaling, that is, employment of the
different
> units for the same magnitude in a program is a relatively rare case. And I
> beleive that the general rule is that all magnitudes in a subroutine
should be
> uniform, that is, a certain unit must be selected for each magnitude, and
all
> values of that magnitude in the subroutine must be expressed using that
selected
> unit.

That's a good principle, and it's easy to obey in cases of self-contained
programs where the entire corpus of source code is under the control of a
single author.  But we also have to consider the case where a program
incorporates foreign libraries.  One of the aims of a language that wants to
encourage reuse should be to facilitate a principle of "minimal coercive
power" for these reusable libraries.  To some extent we always have to
designing "around" the library -- that's not the point; it is still
desirable for libraries to impose the mildest possible requirements on their
clients.  In the case of units, I think it's onerous to have libraries that
say "we do everything in foobar units, and to use it you must either also do
everything in foobar units, or else hand-code whatever conversions you need
to-and-from foobar units and then be sure to apply those conversions to all
parameters and return results."

> Certainly, the values of the magnitude may come from the external sources
> - the parameters and input streams, and those values may be expressed
using
> other units; in those cases the conversions should be performed at the
boundaries:
> all the arguments of a call must be converted to the units required by the
> subroutime called (before or inside an invocation), and the incoming
numbers
> must be converted immediately.

These conversions must be hand-coded.  If you neglect to apply a conversion,
there is no check to catch the error.  And hand-coded conversions to not
automatically compose; you have to hand-code all needed conversions for base
and derived units (vs. defining them for a handful of base units).  Nor are
they reversible, i.e. for interoperability between m and km I would have to
write the conversion going each way rather than simply defining the
relationship between them.

Some people focus on the issue mixing unit systems within a program, that
this is bad practice or whatever.  But that's a red herring -- the ability
to mix unit systems is really not the point.  Often, I would think, for
reasons of scale it might be more convenient for an application to work in a
given unit, but then make use of a function in a library that is written in
terms of some other unit in the same unit system, e.g. mL vs. L.  Unit-safe
programming with automatic conversion allows this without the problems
listed above.  But additionally, the provision for generic formal units
would make possible a much better approach, where a generic function could
be written to be independent of actual units.  You would then end up with
instantiations which perform the calculations without errors introduced by
unnecessary scaling, e.g. going from microns to meters and back again just
because the function was written for meters.

>
> >> Ada is a "superassembler", which facilitates dealing with the general
software
> >> engineering enviromnent, besides of the real computer architectures.
> >
> >I agree.  My position is, let's make it a little more "super"
> I think that such additions may lead to Ada++.

You may be right.  I presume by "Ada++" you mean introducing all kinds of
complex entanglements, special-case rules, redundancies and pitfalls.  That
would certainly be to be avoided.

An idea like this unlikely to get anywhere without a very thorough, detailed
and comprehensive proposal.  If I end up trying to write such a proposal,
and it looks like it is headed for "Ada++", I will surely scrap it :-).  I
do not think this is a feature that would be "worth it at any cost".  But I
believe that it could in fact be defined as a clean and orthogonal
enhancement to Ada.

>
> > in this regard (unit abstraction for numeric types).
> By the way, I still don't see an abstraction here. How will you describe
the
> notion of unit as an abstraction? For example "a type is the set of
possible
> values and the set of operations" - and what is a unit?

Well, what is a "value"? :-)  You picked a great example.  The concept of
unit, like that of value, is not "definable" in the language, but that is
not necessary.  You're getting all philosophical about it and making it
harder than it really is :-).  But I certainly do see an abstraction in
units...

> >Where do these unit conversion functions come from?  They must be
> >hand-coded.
> Yes, surely, they must be hand-coded. But as I said above, there are only
two
> kinds of places where those conversions are needed - at the subroutine
calls
> and after input statements. I do not think that the probability of an
error
> there is substantially higher that the probability of a mistake within a
> declaration of the "unit-aware types".

Hmm?  I'll grant you that much, but in my scheme there is zero probability
of an unchecked error resulting from the failure to apply a conversion to a
parameter or return result.

> In my opinion, the main underlying problem with units is that they are all
> relative. There is no absolute unit for a distance, as well as for time,
> mass, resistance etc.

Of course.  Base units are arbitrary, not fundamental to the universe.  I'm
not losin' any sleep over that! :-)  and I don't see how it creates any
problems for my scheme...

Best Regards,

--mark
--

--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting

Consider her way -- Re: Dimensionality Checking

[Alexandre E. Kopilovitch]

Recent discussion about the dimensions/unit analysis seems to me... well, not
directed by the spirit of the Ada language. As far as I understand, all
participants of the discussion presume that if the dimensional/unit analysis
should be done for an Ada program then it must be performed entirely with the
facilities of Ada language itself. I think that that assumption is plain wrong.

  Let us consider what the dimensional/unit analysis is, in general terms.
For every dimension/unit U we have the mapping Deg_U, which assigns the
rational numbers to the subtypes (that is, the domain of the Deg_U is the set
of all subtypes in our Ada program, and the range of the Deg_U is the set of
rational numbers). We extend this mapping to the variables and user-defined
functions, using the subtype of a variable and the subtype that a function
returns. The mapping Deg_U is "logarithmic", that is, for any variables (or 
user-defined functions) X, Y, Z:
  Z is compatible with X * Y implies Deg_U(Z) = Deg_U(X) + Deg_U(Y), and
  Z is compatible with X / Y implies Deg_U(Z) = Deg_U(X) - Deg_U(Y),
Then we require for all assignments (including an argument passing), additions
and subtractions in our program, that the values of the mapping Deg_U for the
right operand (side) must be equal to the corresponding value for the left
operand. This requirement permits us to define Deg_U over the rational
expressions. Taking into account that the "logarithmic" rule effectively
determines the values of the mapping for the square root, we conclude that 
the mapping Deg_U is defined over the algebraic expressions. The final step
is to assign zero value to all standard (predefined) transcendent functions
(such as Sin etc.). So, the mapping Deg_U is defined for all expressions,
and the condition to be verified is already formulated: for each assignment,
addition and subtraction the value of the mapping Deg_U on the right operand
must be equal to the corresponding value on the left operand.
  This is a definition of the basic "linear" dimensional analysis. One may
construct other, more sophisticated forms of the dimensional analysis for the
specific purposes.

  Now let's recall the fact that the Ada is not a problem-oriented language,
but rather a "superassembler". It intentionally and carefully avoids all
paradigms that aren't closely related to the real computer architectures or
to the general software engineering, even if those paradigms are heavily used
in some significant application area. (Note that I'm speaking here about the
paradigms; the data representation issues are another matter, that is a natural
job for an assembler.)
  Obviously, the dimensionality paradigm is one of the kind that Ada avoids:
it belongs neither to a computer architecture nor to the general software
engineering, but to the particular application area, no matter how significant
it is in the real world. Therefore Ada most probably will not take any move
to support it directly.

  The proper way to do the dimensional/unit analysis for the Ada programs is
to use the ASIS and some suitable language processor, I guess that the SML
might be the best for this purpose (because it is well-suited for the
manipulations with the algebraic type systems). So the configuration of the
whole tool chain may look like that:

       dimension/unit values for the subtypes
                       |
                       |
                      \|/
                       |
  |------|         |---------|	      |-------------|
  | ASIS | ------> | SML     | ------ | SML         |
  | tool |         | program |        | interpreter |
  |------|         |---------|        |-------------|
     |                 |
    /|\                |
     |                \|/
     |                 |
  |----------|    diagnostic output
  | Ada      |      
  | compiler |
  |----------|
     |
    /|\
     |
     |
 program to be verified
   

  Finally, I'll try to explain why the subtypes, and not the types, are the
natural carriers for the dimensionality info. Briefly, with the physical
magnitudes, all the dimensionalities are imaginary, and only the repetition
count within some underlying measurement process is real. That count is obviously
dimensionless. In fact, a dimension of physical magnitude is the abstraction
for the class of the instruments with which we can measure the magnitude.
  If you do not like such vague metaphysical arguments then consider the
following question: if X and X*X belong to the different types, how will you
treat (interpret) the usual approximations by the Taylor series?
  And as for the units, I hope everyone will agree that there is no fundamental
difference (in physics) between miles and kilometers.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Consider her way -- Re: Dimensionality Checking

[Mark Lundquist]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008097622.26173.comp.lang.ada@ada.eu.org...
>
>[snip...]
>   Now let's recall the fact that the Ada is not a problem-oriented
language,
> but rather a "superassembler". It intentionally and carefully avoids all
> paradigms that aren't closely related to the real computer architectures
or
> to the general software engineering, even if those paradigms are heavily
used
> in some significant application area. (Note that I'm speaking here about
the
> paradigms; the data representation issues are another matter, that is a
natural
> job for an assembler.)
>   Obviously, the dimensionality paradigm is one of the kind that Ada
avoids:
> it belongs neither to a computer architecture nor to the general software
> engineering, but to the particular application area, no matter how
significant
> it is in the real world. Therefore Ada most probably will not take any
move
> to support it directly.

Well OK, but then how do you explain Ada's type system?  If the language did
not
abstract types away from its own "machine model", then wouldn't we have
C-style type-equivalence instead?  Instead, in Ada we have the idea that
"number of lines in a file" and "number of cows" can be different types.
Isn't that pretty abstract for a "superassembler"?

>
>   The proper way to do the dimensional/unit analysis for the Ada programs
is
> to use the ASIS and some suitable language processor [snip...]

For one thing, you would still have to code all of of your own unit
conversions.  See other posts in this thread, keywords "combinatoric" and
"explosion" :-)
(Hmmm, "explosion" might pick up that other post about pajamas being
inflammable, or inflatable, or whatever that was... :-)

>
>   Finally, I'll try to explain why the subtypes, and not the types, are
the
> natural carriers for the dimensionality info. Briefly, with the physical
> magnitudes, all the dimensionalities are imaginary, and only the
repetition
> count within some underlying measurement process is real. That count is
obviously
> dimensionless. In fact, a dimension of physical magnitude is the
abstraction
> for the class of the instruments with which we can measure the magnitude.

Are you just trying to say that we have base units which are arbitrary, and
derived units based on those?

>   If you do not like such vague metaphysical arguments then consider the
> following question: if X and X*X belong to the different types, how will
you
> treat (interpret) the usual approximations by the Taylor series?

Well, I think you're almost right here... you don't have to think about
Taylor series to see the problem.  The fundamental glitch is that
unit-safety takes you from a numeric system that is closed under
multiplication to one that is not.  Every expression in Ada has a value; if
X is of a "dimensioned type" as we have been considering, then what is the
type of the expression 'X * X'?  So you're right that in the "dimensioned
type" approach there has to be some relationship between the types, but it
would be absolutely wrong to co-opt subtyping for this.  For one, we want to
save subtypes for what they are already used for (constraint checks); but
more fundamentally, it just does not make sense.  Given a subtype and a
value, you can tell whether the value is in the subtype!  The subtype is not
some abstract property of the object, which is what dimensions/units would
be.

Best Regards,
Mark

Re: Consider her way -- Re: Dimensionality Checking

[Nick Roberts]

"Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote in message
news:mailman.1008097622.26173.comp.lang.ada@ada.eu.org...

> Recent discussion about the dimensions/unit analysis seems to me... well,
not
> directed by the spirit of the Ada language. As far as I understand, all
> participants of the discussion presume that if the dimensional/unit
analysis
> should be done for an Ada program then it must be performed entirely with
the
> facilities of Ada language itself. I think that that assumption is plain
wrong.
> ...

The reason for proposing a unit (or dimension) checking scheme as an
extension to the Ada language, is so that the portability and other benefits
of standardisation will then apply.

My reasons for associating a unit with a type rather than a subtype is to do
with explicit conversion between values of the same dimensionality but
different units.

In Ada, values of the same subtype can be used interchangeably in
expressions; the only place where the subtype matters is where a variable is
updated, in which case the new value is checked to ensure it is compatible
with the variable's subtype. This is a basic priciple in Ada, and I did't
want to change it.

With scalar values of different types, the only way to use a value, X1 say,
of one type, T1 say, in a place where another type, T2 say, is expected, is
with an explict conversion T2(X1). The converse conversion T1(X2) is always
possible, and a view conversion implies two conversions, one in each
direction. This fits perfectly with the conversion between two values of
different units (of the same dimensionality), which is assumed to be
achievable by multiplication by a certain factor: the conversion is always
bidirectional (the converse conversion is achieved by multiplication by the
inverse of the factor).

Hence, it works neatly to associate a unit with a type.

--
Best wishes,
Nick Roberts