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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fe9ec916c5bbbd59 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-13 13:53:58 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.direct.ca!look.ca!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc54.POSTED!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada References: Subject: Re: Consider her way -- Re: Dimensionality Checking X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Thu, 13 Dec 2001 17:13:18 GMT NNTP-Posting-Host: 204.127.202.213 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc54 1008263598 204.127.202.213 (Thu, 13 Dec 2001 17:13:18 GMT) NNTP-Posting-Date: Thu, 13 Dec 2001 17:13:18 GMT Organization: AT&T Broadband Xref: archiver1.google.com comp.lang.ada:17879 Date: 2001-12-13T17:13:18+00:00 List-Id: "Alexandre E. Kopilovitch" wrote in message news:mailman.1008201902.27048.comp.lang.ada@ada.eu.org... > "Mark Lundquist" wrote: > >> Obviously, the dimensionality paradigm is one of the kind that Ada avoids: > >> it belongs neither to a computer architecture nor to the general software > >> engineering, but to the particular application area, no matter how significant > >> it is in the real world. Therefore Ada most probably will not take any move > >> to support it directly. > > > >Well OK, but then how do you explain Ada's type system? > That facility corresponds to a major general software engineering paradigm. But it has not always been so with strong typing. I submit that it became "general" because it was useful in practice and feasible for implementation in a programming language. I feel that unit-safety with automatic unit conversion is a concept that is similarly useful and feasible. > > > If the language did not > >abstract types away from its own "machine model", then wouldn't we have > >C-style type-equivalence instead? > Certainly yes. > > > Instead, in Ada we have the idea that > >"number of lines in a file" and "number of cows" can be different types. > >Isn't that pretty abstract for a "superassembler"? > Not at all. It is too abstract for an assembler (such as C, for example), but > Ada is a "superassembler", which facilitates dealing with the general software > engineering enviromnent, besides of the real computer architectures. I agree. My position is, let's make it a little more "super" in this regard (unit abstraction for numeric types). > > >> The proper way to do the dimensional/unit analysis for the Ada programs is > >> to use the ASIS and some suitable language processor [snip...] > > > >For one thing, you would still have to code all of of your own unit conversions. > Why? Two distinct subtypes of the same type may be used together in an expression > without any conversion. True, unfortunately for your scheme... if a quantity expressed in grams is used in an expression where a quantity expressed in kilograms was meant, and they are both the same type (because they are of the same dimensionality -- though they may be different subtypes, I expect for the benefit of your checking metalanguage?), then no incompatibility is detected by the compiler. Notwithstanding the detection issue, to correct the incompatibility you must run the value through a unit (scaling) conversion (which I understand would not entail a type conversion in your scheme). Where do these unit conversion functions come from? They must be hand-coded. > In my opinion, the unit-safety may be based on the type system only for the > relatively simple situations, which is essentially linear. The typical example > of "apples and oranges" falls in that category. I agree completely, in the context of trying to use the existing Ada typing system to effect unit-safety and unit conversions. These cannot be subsumed by the current type system. My proposal would be to build unit-awareness into the type system. That would completely change the outlook. You would not think of unit-safety as being "based on" the type system -- instead, aspects of the semantics of the type system would be based on unit-safety! Best regards, -- mark -- -------------- Reply by email to: Mark dot Lundquist at ACM dot org Consulting services: http://home.attbi.com/~mlundquist2/consulting