From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 15 Feb 93 15:12:09 GMT From: enterpoop.mit.edu!hri.com!noc.near.net!inmet!spock!stt@ucbvax.Berkeley.ED U (Tucker Taft) Subject: Re: Dimensions (was: What's the difference between...) Message-ID: <1993Feb15.151209.7531@inmet.camb.inmet.com> List-Id: In article <1993Feb13.232516.5229@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: >In article <1993Feb13.191810.4452@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes: >> . . . Explicit type conversion is required (of course >>that's a bit annoying for multiplication -- we never did get >>around to putting full support for "units" into Ada). >> >You just hit a hot button of mine, Tucker. Explicit type conversion indeed >will work for multiplication, so that D := R * T is OK. But it's >worse than that: you have to hide the predefined multiplication. >Otherwise if D, D1, and D2 are all Distance, D := D1 * D2 is legal. >This is a disaster from a physical point of view. > . . . >"Never did get around to putting it in" was IMHO a mistake. Programming >languages (should) provide a vocabulary for problem solving. Many programs >in Ada's intended domain are simulations of physical phenomena that would >benefit greatly from the ease of expression that dimensioned quantities >would provide, withot the runtime overhead of the variant record solution. >How seriously was it considered? We tried various approaches. One was to require support for static calculations involving discriminants, plus an ability to define assertions associated with parameters. We even considered allowing discriminants on numeric types, but could never work out all of the details. We also proposed "cheap" inline functions whose body was a single expression, sort of like the statement functions of Fortran. These were *required* to be expanded at compile-time, with full static calculation power brought to bear. Ultimately, it seemed like we were getting too much mechanism, without sufficient proof that the solution would represent a net productivity improvement for the "average" programmer. The Ada-inspired hardware description language VHDL has an elegant "units" mechanism, but it is a major syntactic add-on. We always hoped we could come up with some more general mechanism which would allow someone to build up a statically-checked "units" mechanism, without actually building it into the syntax of the language. None of our attempts were entirely satisfactory. With the GNU NYU Ada9X Translator (GNAT) coming, we may have an excellent test-bed for investigating tricky language design issues like this one. If someone comes up with a neat way of solving the "units" problem with an elegant extension using GNAT, then it could be ready for incorporation into the standard next time. That's how other languages work, and it would be refreshing to see Ada 9X be a bit more dynamic in communities where absolute standardization is not such a huge requirement. By the way, one idea that might be worth pursuing is to define some subtype/object-specific attributes that represent units. In Ada 9X, implementation may define their own attributes (that was allowed in Ada 83 too), and then allow users to define their values via the attribute-definition clause (a generalization of the Ada 83 "length" clause). You could then have a pragma which would statically enforce units checking. Such an approach would be a "legal" extension of Ada 9X, and could even be de-facto-standardized through the Uniformity Rapporteur Group (URG) of WG9. For example, the following is "legal" Ada 9X provided the implementation supports an appropriate implementation-defined attribute "Units" (of course it is not very portable, unless such an attribute becomes widely supported): subtype Distance is Float; for Distance'Units use (1,0,0); -- attribute-definition clause subtype Mass is Float; for Mass'Units use (0,1,0); subtype Time is Float; for Time'Units use (0,0,1); cm : constant Distance := 1.0; g : constant Mass := 1.0; s : constant Time := 1.0; pragma Check_Units; . . . X : Distance := 1.0 * cm; -- Compiler checks units Y : Float := X * X; -- Compiler determines Y'Units = (2,0,0) Z : Distance := Y / X; -- Compiler verifies units matching Q : Distance := Y / Y; -- Compile-time error -- "units mismatch" subtype Velocity is Float; for Velocity'Units use Distance'Units/Time'Units; -- This presumes that X'Units is of a type with appropriate -- operators, that have been made (use) visible. subtype Energy is Float; for Energy'Units use Mass'Units * Velocity'Units**2; E : Energy; function Kinetic_Energy(M : Mass; V : Velocity) return Energy is begin return 0.5 * M * V**2; -- Compiler checks units end Kinetic_Energy; begin Y := 3.0 * cm**2; -- Compiler checks units again E := Kinetic_Energy(2.0 * g, 7.0 * cm/s); -- Compiler checks units on parameter passing and assignment Actually, that doesn't look too bad. Since it is all "legal" Ada 9X, it is possible that some implementor (or GNAT enhancer) could add it to a validated compiler as an experiment. If something like this becomes popular, then perhaps the URG might later "bless" it somehow. A slightly less elegant solution would use pragmas only. (e.g. "pragma Units(Length, 1, 0, 0);"). This would have the advantage that a compiler could just ignore all pragma Units and the program would still be legal, even though less static checking would have been performed. Hence, the program would be more portable. Of course, the above program could be made portable by simply deleting all of the attribute-definition clauses for 'Units (presuming those are the only places the 'Units attribute is referenced), once the program had been debugged. In any case, this process of experimentation and then later de-facto-standardization is somewhat similar to the way that various packages supporting "unsigned" integers appeared for Ada 83. Initial users had to live with the nonportability, but eventually the ARG and the URG got interested enough to begin work on defining a de-facto standard. >Mike Feldman S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138