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,cc4f25d878383cc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-04 06:00:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada Subject: Re: Dimensionality Checking (Ada 20XX) Date: Tue, 04 Dec 2001 14:00:32 GMT Message-ID: <3c0cc931.16965562@News.CIS.DFN.DE> References: <3C0A5054.E74A82E7@worldnet.att.net> <9ugs4v$8d7lj$1@ID-25716.news.dfncis.de> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) X-Trace: fu-berlin.de 1007474433 9257910 212.79.194.111 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:17380 Date: 2001-12-04T14:00:32+00:00 List-Id: On Mon, 3 Dec 2001 21:13:38 -0000, "Nick Roberts" wrote: >I really like this idea. I'd like to throw in a suggestion. > >I think probably the facility should only be applied to fixed-point types. >All floating-point types would remain 'undimensioned' and there would be >conversions and other operations between all floating-point, integer, and >fixed-point types as usual (whose results would be undimensioned). > >There would be a new package, Ada.Physics, in which the following types and >constants would be declared: > > type Physical_Dimension is (Mass, Distance, Time); > > type Dimensionality is array (Physical_Dimension) of Integer; > > Meter_Dimensionality: constant Dimensionality := (1,0,0); > Metre_Dimensionality: constant Dimensionality := (1,0,0); > > Second_Dimensionality: constant Dimensionality := (0,0,1); > -- etc. > >A programmer may then construct a package with unit declarations appropriate >to a specific application domain, e.g.: > > package My_Physics is > > Foot_Dimensionality: > constant Ada.Physics.Dimensionality := (1,0,0); > > generic > type Feet is delta <>; > type Meters is delta <>; > function Generic_Feet_to_Meters (X: in Feet) return Meters; > pragma Inline(Generic_Feet_to_Meters); > > -- etc. > > end; > >Then, in application code, the following could be used: > > -- TURD: Traditional Ultrasonic Ranging Device > > type TURD_Distance is delta 17.0/16200 range 1.0/12 .. 17.0; > -- in feet > > pragma Dimensionality > ( Type_Name => TURD_Distance, > Dimensions => My_Physics.Foot_Dimensionality ); > >By supplying a Dimensionality pragma for the type T, dimension checking >would then be applied to the "+", "-", "*", "/", and "**" operations of T as >appropriate. The dimensionality of the result would be checked against: in >an assignment, the target object; for an actual parameter, the corresponding >formal. Of these operations, if either actual parameter (apart from the >righthand one of "**") is undimensioned, no check would be applied (and the >result is undimensioned). There are two different "undimensioned" in your system: a) ones with no paragma Dimensionality applied and b) ones with pragma Dimensionality (Dimensions=>(others=>0)); Then: case b case a 2*2m 4 4m 2+2m illegal 4 2m**2 4sqm 4sqm 2**2m illegal 4 Anyway you should invent some rules for literals of dimensioned types. Will you apply pragma Dimensionality to literals depending on the context? >The checks would be entirely static. The pragma >must occur before the type is frozen. The value of the Dimensions parameter >must be static, and of type Ada.Physics.Dimensionality. Static unit checks would efficiently exclude "class-wide" operations on dimensioned values like 'Value, 'Image, 'Read etc. There is IMO an obvious analogy between dimensionality and both type tags and discriminants. I think that there should be possible to have both constrained (=fixed dimension) and unconstrained (class-wide) subtypes and instances of dimensioned types. Constrained ones should be checked at compile time the same way as String (1..3) is checked when "abc" is assigned. If Ada should support dimensioned types, then I think that it should do it using the existing paradigms. As I see it there could be two approaches: a hard-wired implementation of dimensioned units as many have proposed and a more complicated way based on an ability to have compile-time user-defined subroutines defined on type tags and/or discriminants. I believe it is worth to think (for Ada 2100 (:-)) about the "more compilcated" approach because the pattern of dimensioned units is quite wide spread. For instance, it could well be used for matrix/vector types etc. >These facilities could be defined in an optional annex. If a program which >uses dimensionality checking were to be ported to a compiler which doesn't >support it, the program should still compile and work as before, except only >that the dimensionality checking would not be done. > >I would suggest that scaling and offset are done using existing Ada >facilities. To which of the following two types would you apply pragma Dimensionality (Dimensions=>Second_Dimensionality); 1. Ada.Calendar.Time 2. Standard.Duration (:-)) Regards, Dmitry Kazakov