From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: SI Units Checked and Unchecked Date: Thu, 9 Aug 2018 17:51:57 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <9381f30a-a957-4477-b037-b2d60041e83e@googlegroups.com> NNTP-Posting-Host: IzvqdhUtDGKIMCldyDtZ+w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:54110 Date: 2018-08-09T17:51:57+02:00 List-Id: 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