Re: SI Units Checked and Unchecked

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-08-09 17:03, Dan'l Miller wrote:

> So, Dmitry, you are making the mistake of excessive reuse in the app-domain of an unfinished library.  Sure, at some deep level in the library, there can be a generic gauge that skeuomorphically represents a swinging black needle on a white circle that has no idea whether it is measuring pressure or amperes or volts or speed.  But at the intended user-interface facade of the library, there should be:
> 1) a strongly-typed gauge for amperes,
> 2) a separate strongly-typed gauge for pressure,
> 3) a separate strongly-typed gauge for volts,
> 4) a separate strongly-typed gauge for speed,
> and so forth that are wrappers around the one shared white circle with swinging black needle as the generic unitless-clueless(-at-engineering-/compile-time) gauge of which you speak.

No, I am speaking about a widget that checks and enforces measurement 
units. If you look how GUI widgets are constructed you would notice 
adjustment objects, events to propagate, properties to set and query, 
MVC and dozens of other things connecting the widget to the world around 
it, all dealing with measurement units. There is no way anybody could 
design this with generics or statically typed.

It can be statically constrained though, in some few cases, because 
widgets are customary stored and restored. There might be some limited 
cases with all static layouts in avionics or medical applications, these 
are an exception from the common rule.

And note that speed and pressure are measured in dozens different units. 
One of the requirements of sane design is that all compatible units were 
allowed. E.g. an adjustment object in kPa should work with a barograph 
indicating mm Hg. And I don't remember a single customer who ever wanted 
his HMI showing speed in SI's m/s.

>> What is necessary but not sufficient is language support for handling
>> statically known constraints using compile-time static operations and
>> removing statically known discriminants from the representation.
>>
>> Note a direct analogy with classes for scalar types. Type tag is in
>> essence just a discriminant. For some types we want static discriminants
>> and other constraints removed.
>>
>>> I would be interested in a summary (or even better, an AI) that itemizes all the core-language
>>> obstacles in currently-standardized Ada to moving all the incompatible usages of units to be
>>> compile-time errors instead of raising exceptions.
>>
>> The Ada type system is not capable to handle dimensioned types. I posted
>> a list of requirements for a dimensioned types support some years ago here.
>>
>> There are lots of language issues to resolve first before approaching
>> dimensioned types.
> 
> As strongly-typed as Ada is, we often yearn for a more-Ada-than-Ada level of an even stronger-typed Ada.  Even you.  Even for compile-time-enforced strongly-typed units of measure.  (Or else why would you expend that analysis's effort in the first place?)

The issues I meant are necessary precondition to make a reasonable AI on 
dimensioned types.

As an example of such an issue consider the problem of constraint 
propagation:

    type Dimensioned is ...;
    type Dimensioned_Array (Positive range <>) of Dimensioned;

Here we want the measurement unit constraint of the array to propagate 
to its elements. And of course we don't want the elements in the array 
to keep their constraints as they must all be coming from the array (or 
a container in general case). Ada type system lacks such mechanism. Note 
that this problem is larger than the problem of measurement units. 
Actually, if the type system were fixed no specific AI might be required 
at all.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de