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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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-14 07:35:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fr.clara.net!heighliner.fr.clara.net!freenix!enst!enst.fr!not-for-mail From: "Alexandre E. Kopilovitch" Newsgroups: comp.lang.ada Subject: Re: Consider her way -- Re: Dimensionality Checking Date: Fri, 14 Dec 2001 17:13:01 +0300 (MSK) Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: avanie.enst.fr 1008344102 9239 137.194.161.2 (14 Dec 2001 15:35:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Fri, 14 Dec 2001 15:35:02 +0000 (UTC) To: comp.lang.ada@ada.eu.org Return-Path: X-Mailer: Mail/@ [v2.44 MSDOS] Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:17910 Date: 2001-12-14T17:13:01+03:00 "Mark Lundquist" wrote: >>>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. I doubt that - the latter. The scaling, that is, employment of the different units for the same magnitude in a program is a relatively rare case. And I beleive that the general rule is that all magnitudes in a subroutine should be uniform, that is, a certain unit must be selected for each magnitude, and all values of that magnitude in the subroutine must be expressed using that selected unit. Certainly, the values of the magnitude may come from the external sources - the parameters and input streams, and those values may be expressed using other units; in those cases the conversions should be performed at the boundaries: all the arguments of a call must be converted to the units required by the subroutime called (before or inside an invocation), and the incoming numbers must be converted immediately. >> 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" I think that such additions may lead to Ada++. > in this regard (unit abstraction for numeric types). By the way, I still don't see an abstraction here. How will you describe the notion of unit as an abstraction? For example "a type is the set of possible values and the set of operations" - and what is a unit? >> >> 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. Yes, surely, they must be hand-coded. But as I said above, there are only two kinds of places where those conversions are needed - at the subroutine calls and after input statements. I do not think that the probability of an error there is substantially higher that the probability of a mistake within a declaration of the "unit-aware types". >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! In my opinion, the main underlying problem with units is that they are all relative. There is no absolute unit for a distance, as well as for time, mass, resistance etc. And the abstractions for a relativities usually appear to be quite complex things. Therefore it is difficult to believe that such a thing may simplify or somehow facilitate real programmimg. The principal difference between the dimensionality and the units is that it is very often necessary to mix the variables of different dimensionality in a formulae, while a mix of different units (of the same dimensionality) is a nonsense. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia