Re: SI Units Checked and Unchecked

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

On Thursday, August 9, 2018 at 9:07:23 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-08-09 15:47, Dan'l Miller wrote:
> 
> > Shouldn't the •entire• point of a units-of-measurement library (or feature of language) be
> > compile-time errors, not run-time exceptions/errors.
> 
> No, because in most cases the unit is unknown.

No, apparently in “most cases” you are writing either some sort of toy calculator or some sort of excessively over-generalized library marketed to too-wide of an audience.  Apparently in “most cases” you are not writing the •app-domain• controls for actual hardware deployed into an actual physical environment, where the units of measure are a settled topic, not pulled out of thin air on a changing whim.

Well, factually incorrect opinions like yours above would be the reason for losses similar to the Mars Climate Orbiter in the future, even if coded is so-called ‘safety-critical’ Ada.

http://www.cnn.com/TECH/space/9909/30/mars.metric.02

Thinking that units of measure is a run-time choice (instead of an end-to-end agreed-upon engineering-time choice) would cause other such epic engineering failures for no good reason other than units of measure not being strongly-typed in the programming language.

> Consider a widget library 

Yep, library.

> with instruments indicating dimensioned values, dimensioned calculator, 
> serialization of dimensioned data etc.

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.

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