Re: SI Units Checked and Unchecked

["Dan'l Miller" <optikos@verizon.net>]

On Thursday, August 9, 2018 at 2:42:47 PM UTC-5, Dmitry A. Kazakov wrote:
> 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

Actually, I am talking about compile-time checks within Ada source code for a gauge as would be utilized on the GUI control screen of a chemical plant or a nuclear reactor, not some toy string-processing app that is the analogue of GNU Units.

> >> 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

It looks like a string-processing library to support a toy units converter app, which is the X Window analogue of GNU Units*.  This doesn't look at all like compile-time units-of-measure enforcement via strong-typing.  A mere string-processing interpreter helping the UI/UX level is missing the •entire• point of this whole thread, including the OPer's OPing.  This mere string-processing interpreter thoroughly misses the entire point of strong typing each scalar datum in throughout all millions of lines of Ada source code of a compiled imperative programming language in a large software-controls-hardware-within-a-physics-device product.

Dmitry, this work is impressive for what it is, but a string-processing toy unit-conversion calculator is far far off-topic (as is GNU Units* too).

* https://en.wikipedia.org/wiki/GNU_Units

> 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