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 X-Received: by 2002:a02:b572:: with SMTP id z47-v6mr1874994jaj.18.1533852725054; Thu, 09 Aug 2018 15:12:05 -0700 (PDT) X-Received: by 2002:aca:de07:: with SMTP id v7-v6mr128004oig.5.1533852724897; Thu, 09 Aug 2018 15:12:04 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!g24-v6no37200iti.0!news-out.google.com!k71-v6ni15itk.0!nntp.google.com!g24-v6no37198iti.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 9 Aug 2018 15:12:04 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <9381f30a-a957-4477-b037-b2d60041e83e@googlegroups.com> <60ddd5ae-57e1-45e8-929c-302fabaa24ef@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: SI Units Checked and Unchecked From: "Dan'l Miller" Injection-Date: Thu, 09 Aug 2018 22:12:05 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54120 Date: 2018-08-09T15:12:04-07:00 List-Id: 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 wro= te: > >> 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 t= hat 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 wit= h 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. > >=20 > > 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 analo= gue of GNU Units. > >> If you look how GUI widgets are constructed you would notice > >> adjustment objects, > >=20 > > which should utilize the compile-time-enforced strongly-typed types, no= t unitless scalars >=20 > The scalars are not unitless. The unit is a discriminant: >=20 > 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 al= l like compile-time units-of-measure enforcement via strong-typing. A mere= string-processing interpreter helping the UI/UX level is missing the =E2= =80=A2entire=E2=80=A2 point of this whole thread, including the OPer's OPin= g. This mere string-processing interpreter thoroughly misses the entire po= int 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=20 > constraint is not static. >=20 > [...] >=20 > >> 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. > >=20 > > 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/ w= eakly-typed identifier in > > app-domain declarations of instantiations. >=20 > There is no usable design based on unrelated types [*]. There must exist= =20 > dimensioned objects capable to hold values of different units. Similarly= =20 > to class-wide objects this by no means constitutes weak typing. >=20 > >> One of the requirements of sane design is that all compatible units we= re > >> allowed. E.g. an adjustment object in kPa should work with a barograph > >> indicating mm Hg. > >=20 > > where =E2=80=9Cworks with=E2=80=9D is defined as having an overtly-inst= antiated converter object between them, where > > the converter object again assures compile-time physics-correct enforce= ment of strongly-typed input > > units of measure to strongly-typed output units of measure. >=20 > No converter objects needed. Operations are defined directly on the=20 > dimensioned values. You can add 5 m/s to 10 km/h, the result is always=20 > physically correct. >=20 > This design has its drawbacks, e.g. it would prevent use of fixed-point= =20 > types, because you would lose control over precision. >=20 > > Just like the rule of not hardcoding a single iterator/cursor into a co= ntainer, don't hardcode > > conversions or prohibitive lack thereof into the compile-time-enforced = strong-typing units-of-measure > > dimension types. >=20 > As I said there no hard-coded conversions whatsoever. >=20 > >> And I don't remember a single customer who ever wanted > >> his HMI showing speed in SI's m/s. > >=20 > > Why in the world would a GUI widget library dictate the requirements to= the customer, as a tail > > wagging the dog? >=20 > Right. That is why the measurement unit of a widget cannot be a part of= =20 > its type and why the widgets cannot deploy a fixed system of units. >=20 > > The strongly-type GUI widget library should present a physics-correct p= lethora 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. >=20 > That is one of the requirements, which BTW precludes type-based=20 > solutions. All production code used in automation systems is based on=20 > subtypes. >=20 > ---------------------- > * Note that dimensioned types could build a class. Then they would be=20 > related and there would be class-wide objects to hold values of any=20 > dimension. This sort of design is thinkable, but it would possibly=20 > require even deeper changes of the Ada type system than a design based=20 > on subtypes/constraints. >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de