Re: Consider her way -- Re: Dimensionality Checking

["Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>]

"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