Re: SI Units Checked and Unchecked

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

On 2018-08-09 19:32, Dan'l Miller wrote:
> On Thursday, August 9, 2018 at 10:51:59 AM UTC-5, Dmitry A. Kazakov wrote:
>> 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 bland 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
>>> bland unitless-clueless(-at-engineering-/compile-time) gauge of which you speak.
>>
>> No, I am speaking about a widget that checks and enforces measurement
>> units.
> 
> as am I
> 
>> If you look how GUI widgets are constructed you would notice
>> adjustment objects,
> 
> which should utilize the compile-time-enforced strongly-typed types, not unitless scalars

The scalars are not unitless. The unit is a discriminant:

    http://www.dmitry-kazakov.de/ada/units.htm

The point is that like in the design proposed by Christoph the 
constraint is not static.

[...]

>> 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.
> 
> So you can't use /this/ name instead of /that/ name of type.  Gee, your keyboard is so weird that it won't let you type /this/ strongly-typed identifier instead of /that/ weakly-typed identifier in app-domain declarations of instantiations.

There is no usable design based on unrelated types [*]. There must exist 
dimensioned objects capable to hold values of different units. Similarly 
to class-wide objects this by no means constitutes weak typing.

>> 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.
> 
> where “works with” is defined as having an overtly-instantiated converter object between them, where the converter object again assures compile-time physics-correct enforcement of strongly-typed input units of measure to strongly-typed output units of measure.

No converter objects needed. Operations are defined directly on the 
dimensioned values. You can add 5 m/s to 10 km/h, the result is always 
physically correct.

This design has its drawbacks, e.g. it would prevent use of fixed-point 
types, because you would lose control over precision.

> Just like the rule of not hardcoding a single iterator/cursor into a container, don't hardcode conversions or prohibitive lack thereof into the compile-time-enforced strong-typing units-of-measure dimension types.

As I said there no hard-coded conversions whatsoever.

>> And I don't remember a single customer who ever wanted
>> his HMI showing speed in SI's m/s.
> 
> Why in the world would a GUI widget library dictate the requirements to the customer, as a tail wagging the dog?

Right. That is why the measurement unit of a widget cannot be a part of 
its type and why the widgets cannot deploy a fixed system of units.

> The strongly-type GUI widget library should present a physics-correct plethora of options to the customer so that the customer speaks the language of the customer, not of some library designer (who sought effort reduction).  The purpose of engineering is to serve the customer's expectations, not to the library designer's whim.

That is one of the requirements, which BTW precludes type-based 
solutions. All production code used in automation systems is based on 
subtypes.

----------------------
* Note that dimensioned types could build a class. Then they would be 
related and there would be class-wide objects to hold values of any 
dimension. This sort of design is thinkable, but it would possibly 
require even deeper changes of the Ada type system than a design based 
on subtypes/constraints.

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