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:a24:678d:: with SMTP id u135-v6mr1292445itc.55.1533827010356; Thu, 09 Aug 2018 08:03:30 -0700 (PDT) X-Received: by 2002:aca:eb15:: with SMTP id j21-v6mr106074oih.6.1533827010214; Thu, 09 Aug 2018 08:03:30 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feed.usenet.farm!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!g13-v6no2936511itf.0!news-out.google.com!g5-v6ni1603iti.0!nntp.google.com!g13-v6no2936508itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 9 Aug 2018 08:03:29 -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> 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 15:03:30 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54108 Date: 2018-08-09T08:03:29-07:00 List-Id: 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: >=20 > > Shouldn't the =E2=80=A2entire=E2=80=A2 point of a units-of-measurement = library (or feature of language) be > > compile-time errors, not run-time exceptions/errors. >=20 > No, because in most cases the unit is unknown. No, apparently in =E2=80=9Cmost cases=E2=80=9D 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 =E2=80=9Cmost cases=E2= =80=9D you are not writing the =E2=80=A2app-domain=E2=80=A2 controls for ac= tual 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 w= him. 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 =E2=80=98safety-critical=E2=80=99 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-e= nd agreed-upon engineering-time choice) would cause other such epic enginee= ring failures for no good reason other than units of measure not being stro= ngly-typed in the programming language. > Consider a widget library=20 Yep, library. > with instruments indicating dimensioned values, dimensioned calculator,= =20 > 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 ne= edle 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 t= he 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 swin= ging 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=20 > statically known constraints using compile-time static operations and=20 > removing statically known discriminants from the representation. >=20 > Note a direct analogy with classes for scalar types. Type tag is in=20 > essence just a discriminant. For some types we want static discriminants= =20 > and other constraints removed. >=20 > > I would be interested in a summary (or even better, an AI) that itemize= s 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. >=20 > The Ada type system is not capable to handle dimensioned types. I posted= =20 > a list of requirements for a dimensioned types support some years ago her= e. >=20 > There are lots of language issues to resolve first before approaching=20 > dimensioned types. As strongly-typed as Ada is, we often yearn for a more-Ada-than-Ada level o= f an even stronger-typed Ada. Even you. Even for compile-time-enforced st= rongly-typed units of measure. (Or else why would you expend that analysis= 's effort in the first place?)