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-11 14:45:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn3feed!wn4feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc53.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: <40wR7.37508$Yy.395987@rwcrnsc53> NNTP-Posting-Host: Q_vR7-215610-Yy-395784@rwcrnsc53 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc53 1008110720 Q_vR7-215610-Yy-395784@rwcrnsc53 (Tue, 11 Dec 2001 22:45:20 GMT) NNTP-Posting-Date: Tue, 11 Dec 2001 22:45:20 GMT Organization: AT&T Broadband Date: Tue, 11 Dec 2001 22:45:20 GMT Xref: archiver1.google.com comp.lang.ada:17791 Date: 2001-12-11T22:45:20+00:00 List-Id: "Alexandre E. Kopilovitch" wrote in message news:mailman.1008097622.26173.comp.lang.ada@ada.eu.org... > >[snip...] > Now let's recall the fact that the Ada is not a problem-oriented language, > but rather a "superassembler". It intentionally and carefully avoids all > paradigms that aren't closely related to the real computer architectures or > to the general software engineering, even if those paradigms are heavily used > in some significant application area. (Note that I'm speaking here about the > paradigms; the data representation issues are another matter, that is a natural > job for an assembler.) > 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? If the language did not abstract types away from its own "machine model", then wouldn't we have C-style type-equivalence instead? 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"? > > 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. See other posts in this thread, keywords "combinatoric" and "explosion" :-) (Hmmm, "explosion" might pick up that other post about pajamas being inflammable, or inflatable, or whatever that was... :-) > > Finally, I'll try to explain why the subtypes, and not the types, are the > natural carriers for the dimensionality info. Briefly, with the physical > magnitudes, all the dimensionalities are imaginary, and only the repetition > count within some underlying measurement process is real. That count is obviously > dimensionless. In fact, a dimension of physical magnitude is the abstraction > for the class of the instruments with which we can measure the magnitude. Are you just trying to say that we have base units which are arbitrary, and derived units based on those? > If you do not like such vague metaphysical arguments then consider the > following question: if X and X*X belong to the different types, how will you > treat (interpret) the usual approximations by the Taylor series? Well, I think you're almost right here... you don't have to think about Taylor series to see the problem. The fundamental glitch is that unit-safety takes you from a numeric system that is closed under multiplication to one that is not. Every expression in Ada has a value; if X is of a "dimensioned type" as we have been considering, then what is the type of the expression 'X * X'? So you're right that in the "dimensioned type" approach there has to be some relationship between the types, but it would be absolutely wrong to co-opt subtyping for this. For one, we want to save subtypes for what they are already used for (constraint checks); but more fundamentally, it just does not make sense. Given a subtype and a value, you can tell whether the value is in the subtype! The subtype is not some abstract property of the object, which is what dimensions/units would be. Best Regards, Mark