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-14 11:49:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn4feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.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: <_IsS7.49745$ER5.626390@rwcrnsc52> Date: Fri, 14 Dec 2001 19:49:14 GMT NNTP-Posting-Host: 204.127.202.211 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52 1008359354 204.127.202.211 (Fri, 14 Dec 2001 19:49:14 GMT) NNTP-Posting-Date: Fri, 14 Dec 2001 19:49:14 GMT Organization: AT&T Broadband Xref: archiver1.google.com comp.lang.ada:17921 Date: 2001-12-14T19:49:14+00:00 List-Id: "Alexandre E. Kopilovitch" wrote in message news:mailman.1008344102.3072.comp.lang.ada@ada.eu.org... > "Mark Lundquist" wrote: > > > > 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. That's a good principle, and it's easy to obey in cases of self-contained programs where the entire corpus of source code is under the control of a single author. But we also have to consider the case where a program incorporates foreign libraries. One of the aims of a language that wants to encourage reuse should be to facilitate a principle of "minimal coercive power" for these reusable libraries. To some extent we always have to designing "around" the library -- that's not the point; it is still desirable for libraries to impose the mildest possible requirements on their clients. In the case of units, I think it's onerous to have libraries that say "we do everything in foobar units, and to use it you must either also do everything in foobar units, or else hand-code whatever conversions you need to-and-from foobar units and then be sure to apply those conversions to all parameters and return results." > 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. These conversions must be hand-coded. If you neglect to apply a conversion, there is no check to catch the error. And hand-coded conversions to not automatically compose; you have to hand-code all needed conversions for base and derived units (vs. defining them for a handful of base units). Nor are they reversible, i.e. for interoperability between m and km I would have to write the conversion going each way rather than simply defining the relationship between them. Some people focus on the issue mixing unit systems within a program, that this is bad practice or whatever. But that's a red herring -- the ability to mix unit systems is really not the point. Often, I would think, for reasons of scale it might be more convenient for an application to work in a given unit, but then make use of a function in a library that is written in terms of some other unit in the same unit system, e.g. mL vs. L. Unit-safe programming with automatic conversion allows this without the problems listed above. But additionally, the provision for generic formal units would make possible a much better approach, where a generic function could be written to be independent of actual units. You would then end up with instantiations which perform the calculations without errors introduced by unnecessary scaling, e.g. going from microns to meters and back again just because the function was written for meters. > > >> 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++. You may be right. I presume by "Ada++" you mean introducing all kinds of complex entanglements, special-case rules, redundancies and pitfalls. That would certainly be to be avoided. An idea like this unlikely to get anywhere without a very thorough, detailed and comprehensive proposal. If I end up trying to write such a proposal, and it looks like it is headed for "Ada++", I will surely scrap it :-). I do not think this is a feature that would be "worth it at any cost". But I believe that it could in fact be defined as a clean and orthogonal enhancement 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? Well, what is a "value"? :-) You picked a great example. The concept of unit, like that of value, is not "definable" in the language, but that is not necessary. You're getting all philosophical about it and making it harder than it really is :-). But I certainly do see an abstraction in units... > >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". Hmm? I'll grant you that much, but in my scheme there is zero probability of an unchecked error resulting from the failure to apply a conversion to a parameter or return result. > 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. Of course. Base units are arbitrary, not fundamental to the universe. I'm not losin' any sleep over that! :-) and I don't see how it creates any problems for my scheme... Best Regards, --mark -- -------------- Reply by email to: Mark dot Lundquist at ACM dot org Consulting services: http://home.attbi.com/~mlundquist2/consulting