* Q: common types?! @ 1994-09-28 15:16 Tony Leavitt 1994-09-29 11:37 ` Peter Hermann ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Tony Leavitt @ 1994-09-28 15:16 UTC (permalink / raw) I have a question for all you Ada wizards. I do not have a lot of experience with Ada (only about 3000 lines), and I have begun to start making a common types package. This package would define all kinds of types for feet, nautical miles, degrees, radians, etc, ad nuasium, for all different kinds and sizes of float and integers. Am I about to go insane by trying this? Or, does this exist already on the Internet somewhere? If I was to attempt to do this how would you recommend about doing it? Here is a sample of what I started to do: package Common_Types is type float64 is new float ; for float64'SIZE use 64 ; type float32 is new float ; for float32'SIZE use 32 ; type integer64 is new integer ; for integer64'SIZE use 64 ; type integer32 is new integer ; for integer32'SIZE use 32 ; type integer16 is new integer ; for integer16'SIZE use 16 ; type integer8 is new integer ; for integer8'SIZE use 8 ; ---------------------------------------------------------------------------- -- Linear Distance Types ---------------------------------------------------------------------------- FEET_PER_NAUTICAL_MILE : constant float := 6076.115 ; FEET_PER_STATUTE_MILE : constant float := 5280.0 ; FEET_PER_KILOMETER : constant float := 3280.8399 ; FEET_PER_METER : constant float := 3.2808399 ; type Nautical_Miles_f64 is new float64 ; subtype NM_f64 is Nautical_Miles_f64 ; type Nautical_Miles_f32 is new float32 ; subtype NM_f32 is Nautical_Miles_f32 ; type Nautical_Miles_i64 is new integer64 ; subtype NM_i64 is Nautical_Miles_i64 ; type Nautical_Miles_i32 is new integer32 ; subtype NM_i32 is Nautical_Miles_i32 ; type Nautical_Miles_i16 is new integer16 ; subtype NM_i16 is Nautical_Miles_i16 ; type Nautical_Miles_i8 is new integer8 ; subtype NM_i8 is Nautical_Miles_i8 ; type Statute_Miles_f64 is new float64 ; subtype MI_f64 is Statute_Miles_f64 ; type Statute_Miles_f32 is new float32 ; subtype MI_f32 is Statute_Miles_f32 ; type Statute_Miles_i64 is new integer64 ; subtype MI_i64 is Statute_Miles_i64 ; type Statute_Miles_i32 is new integer32 ; subtype MI_i32 is Statute_Miles_i32 ; type Statute_Miles_i16 is new integer16 ; subtype MI_i16 is Statute_Miles_i16 ; type Statute_Miles_i8 is new integer8 ; subtype MI_i8 is Statute_Miles_i8 ; type Feet_f64 is new float64 ; subtype FT_f64 is Feet_f64 ; type Feet_f32 is new float32 ; subtype FT_f32 is Feet_f32 ; type Feet_i64 is new integer64 ; subtype FT_i64 is Feet_i64 ; type Feet_i32 is new integer32 ; subtype FT_i32 is Feet_i32 ; type Feet_i16 is new integer16 ; subtype FT_i16 is Feet_i16 ; type Feet_i8 is new ---------------------------------------------------------------------------- -- Angular Distance Types ---------------------------------------------------------------------------- type Degrees_f64 is new float64 ; type Degrees_f32 is new float32 ; -- same for radians. ---------------------------------------------------------------------------- -- Earth Position Types ---------------------------------------------------------------------------- subtype Latitude_f64 is Degrees_f64 range -90.0 .. +90.0 ; subtype Latitude_f32 is Degrees_f32 range -90.0 .. +90.0 ; -- Same for Longitude, heading, bearing, etc ---------------------------------------------------------------------------- -- Functions ---------------------------------------------------------------------------- function sin ( x : Degrees_f64 ) return float64 ; function sin ( x : Degrees_f32 ) return float32 ; function sin ( x : Radians_f64 ) return float64 ; function sin ( x : Radians_f32 ) return float32 ; function convert (x : degrees_f64) return degrees_32 ; function convert (x : radians_f64) return degrees_i16 ; -- etc, etc, etc, etc, until you puke. Same for operators "*", and "+" which -- would do all kinds of type conversion and make sure the units are protected. end Common_Types ; -- Tony Leavitt Lockheed Aeronautical Systems Company Marietta, GA 30063-0670 Voice: (404) 494-7648, Fax:(404) 494-6989 Email: tony@gelac.lasc.lockheed.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Q: common types?! 1994-09-28 15:16 Q: common types?! Tony Leavitt @ 1994-09-29 11:37 ` Peter Hermann 1994-09-29 15:35 ` Tucker Taft 1994-10-05 4:40 ` Daniel Wengelin 2 siblings, 0 replies; 7+ messages in thread From: Peter Hermann @ 1994-09-29 11:37 UTC (permalink / raw) Tony Leavitt (tony@deepthought.Sgi.COM) wrote: : This package would define all kinds of types for feet, nautical : miles, degrees, radians, etc, ad nuasium, for all different kinds and sizes : of float and integers. Am I about to go insane by trying this? Or, does yes : type float64 is new float ; : for float64'SIZE use 64 ; The type float has been introduced as a predefined type which is different for each compiler/hardware and cannot be used for portable programs. Coming from other languages without typing system, the type float is offered in Ada for a first, unclean solution which will be abandoned once the typing system is understood. The above "rape" cannot work because the size of the root type is fixed and cannot be changed for a subtype, neither enlarged nor reduced. You are "deriving" in any way from another type. That means that you create a different type being incompatible the the original type. Therefore, for the same purpose, you easily write type my_float_type is digits 14 ; or type my_float_type is digits 14 range 0.0 .. 1.234e7 ; for example. -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Q: common types?! 1994-09-28 15:16 Q: common types?! Tony Leavitt 1994-09-29 11:37 ` Peter Hermann @ 1994-09-29 15:35 ` Tucker Taft 1994-10-05 4:40 ` Daniel Wengelin 2 siblings, 0 replies; 7+ messages in thread From: Tucker Taft @ 1994-09-29 15:35 UTC (permalink / raw) In article <36c1c0$lve@pong.lasc.lockheed.com>, Tony Leavitt <tony@deepthought.Sgi.COM> wrote: >I have a question for all you Ada wizards. I do not have a lot of experience >with Ada (only about 3000 lines), and I have begun to start making a common >types package. This package would define all kinds of types for feet, nautical >miles, degrees, radians, etc, ad nuasium, for all different kinds and sizes >of float and integers. Am I about to go insane by trying this? Or, does >this exist already on the Internet somewhere? If I was to attempt to do this >how would you recommend about doing it? You could simplify your life by making some of this a generic package, to be instantiated with the "base" floating point type and/or integer type of interest. Put all of the various miles, feet, degrees, etc. in such a generic package. Put the general constants into a separate package. Finally, if you really feel the need, put the numeric types into a third package, with appropriate instantiations of your generic. However, I recommend against this if you can avoid it. Having a centralized "types" package is not a wise way to organize an Ada program, IMHO. You should declare types with the operations that operate on them, in their own package. Grouping them all into one giant package is a way to create maintenance, portability, and general software engineering nightmares. >Here is a sample of what I started to do: > >package Common_Types is > > type float64 is new float ; > for float64'SIZE use 64 ; > type float32 is new float ; > for float32'SIZE use 32 ; > > type integer64 is new integer ; > for integer64'SIZE use 64 ; > type integer32 is new integer ; > for integer32'SIZE use 32 ; > type integer16 is new integer ; > for integer16'SIZE use 16 ; > type integer8 is new integer ; > for integer8'SIZE use 8 ; As someone else pointed out, the above will never work in Ada. You can't turn a 32-bit integer into an 8-bit integer by just squeezing the bits a bit. You have got to impose a range constraint as well, at which point you should declare the range when you declare the type, as follows: type integer64 is range -2**63 .. 2**63-1; type integer32 is range -2**31 .. 2**31-1; type integer16 is range -2**15 .. 2**15-1; type integer8 is range -2**7 .. 2**7-1; Similarly for floating point: type float64 is digits 15; type float32 is digits 6; Note that in Ada 9X, the language-defined package Interfaces already has these. > ... >Tony Leavitt > >Lockheed Aeronautical Systems Company >Marietta, GA 30063-0670 >Voice: (404) 494-7648, Fax:(404) 494-6989 >Email: tony@gelac.lasc.lockheed.com -Tucker Taft ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Q: common types?! 1994-09-28 15:16 Q: common types?! Tony Leavitt 1994-09-29 11:37 ` Peter Hermann 1994-09-29 15:35 ` Tucker Taft @ 1994-10-05 4:40 ` Daniel Wengelin 1994-10-12 17:39 ` gamache 2 siblings, 1 reply; 7+ messages in thread From: Daniel Wengelin @ 1994-10-05 4:40 UTC (permalink / raw) Tony Leavitt (tony@deepthought.Sgi.COM) wrote: : I have a question for all you Ada wizards. I do not have a lot of experience : with Ada (only about 3000 lines), and I have begun to start making a common : types package. This package would define all kinds of types for feet, nautical : miles, degrees, radians, etc, ad nuasium, for all different kinds and sizes : of float and integers. Am I about to go insane by trying this? Or, does : this exist already on the Internet somewhere? If I was to attempt to do this : how would you recommend about doing it? Stuff deleted.... : Tony Leavitt Hi, yes I'd think you'll go nuts trying to handle all the type conversions necessary. Here's what I think you should do: Define new basic types, such as integer and float, to facilitate portability. Define you maths stuff (according to the appropriate standard or annexe) on your new basic float. Define your physical units as subtypes, not for type checking, but for better naming. subtype Volt ... Go out and obtain packages for the complex types, such as geodetic positions. They are pretty tricky to implement if you want a full set of functions. Just my 2cents... -------------------------------------------------------------------- -- Daniel Wengelin -- Team Ada, what a nice idea.... -- -- CelsiusTech -- -- -- dawe@celsiustech.se -- -- -- -- -- -------------------------------------------------------------------- with Standard_Disclaimer; -------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Q: common types?! 1994-10-05 4:40 ` Daniel Wengelin @ 1994-10-12 17:39 ` gamache 1994-10-12 20:36 ` Kraig Hanson 1994-10-12 21:37 ` Robert Dewar 0 siblings, 2 replies; 7+ messages in thread From: gamache @ 1994-10-12 17:39 UTC (permalink / raw) Tony Leavitt (tony@deepthought.Sgi.COM) wrote: : I have a question for all you Ada wizards. I do not have a lot of experience : with Ada (only about 3000 lines), and I have begun to start making a common : types package. This package would define all kinds of types for feet, nautical : miles, degrees, radians, etc, ad nuasium, for all different kinds and sizes : of float and integers. Am I about to go insane by trying this? Or, does : this exist already on the Internet somewhere? If I was to attempt to do this : how would you recommend about doing it? : Here is a sample of what I started to do: : : package Common_Types is [snip] I was surprised by the lack of good followups to this post. Now I can't just read the right response, I have to try and write it! Anyway, the short answer is: Yes, you will go insane by trying this. The biggest problem lies not in the part of your example I snipped, but rather the title of your package. Providing implementation independent definitions of the predefined types (as shown in your example) is a good thing. However your chosen packaging literally allows for the rest of the kitchen, including the sink, to be thrown in as well. I strongly believe that this problem, one of packaging misuse, is the largest issue to be confronted on a large development effort. The issue is primarily one of cohesion and coupling which I won't go into here as they can be read about in any decent S/W Eng. text. Consider a different package name such as My_Predefined_Types. It is somewhat obvious that definitions for float_32, float_64, or integer_64 would fit within this package. It should also be clear that types for feet, radians etc. DO NOT FIT within this package! The "Common_Types" package you define will be 'withed' by virtually every package and will also HAVE AN EXCESSIVELY HIGH RATE OF MODIFICATION. That is, today someone on the program needs to add a constant to convert from natical miles to inches, tomorrow someone needs to add a new conversion between degrees and radians. This will go on and on. Since everyone 'withs' this package, everyone will need to be recompiled everytime it changes. This is a form of coupling. This is also disaster. Finally, since there will need to be operations on many of the types you enumerate, your proposed packaging contradicts the state-of-the-art in our discipline, use of object-oriented paradigms (which try to implement twenty year old ideas): In 1972, Parnas wrote, in "On the Criterial to be used in Decomposing Systems into Modules" that in particular, a "data structure, its internal linkings, accessing procedures and modifying procedures are part of a single module." Then in 1975, Liskov and Zilles wrote,a data abstraction is "a group of related functions or operations that act upon a particular class of objects, with the constraint that the behavior of the objects can be observed only by applications of the operations." Thus, if you choose to use the Ada package feature to implement the software engineering concepts it was created for, you would need to include all sorts of operations (subprograms) in an "_types" package. Again, nonesense. My advice is to create your packages top-down and to include all the operations necessary on each package to be consistent with the above quotes. In addition, to allow for easy host/target migration, yes, create a "predefined_types" package that avoids the use of implementation-dependent definitions of integer, float, etc. Finally, for any other "_type" packages that get created (please don't anyone take this post at an extreme, there are exceptions to every rule, and moderation should be the driving force) choose meaningful package names that define a set (as in set theory). This will allow inclusion of types that belong in the package, but more importantly, will keep out types that do not. -------------------------------------------------------------------- with Standard_Disclaimer; use Standard_Disclaimer; -------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Q: common types?! 1994-10-12 17:39 ` gamache @ 1994-10-12 20:36 ` Kraig Hanson 1994-10-12 21:37 ` Robert Dewar 1 sibling, 0 replies; 7+ messages in thread From: Kraig Hanson @ 1994-10-12 20:36 UTC (permalink / raw) gamache@rapnet.sanders.lockheed.com writes: >Tony Leavitt (tony@deepthought.Sgi.COM) wrote: >: I have a question for all you Ada wizards. I do not have a lot of experience >: with Ada (only about 3000 lines), and I have begun to start making a common >: types package. This package would define all kinds of types for feet, nautical >: miles, degrees, radians, etc, ad nuasium, for all different kinds and sizes >: of float and integers. Am I about to go insane by trying this? Or, does >: this exist already on the Internet somewhere? If I was to attempt to do this >: how would you recommend about doing it? >: Here is a sample of what I started to do: >: >: package Common_Types is >[snip] >I was surprised by the lack of good followups to this post. Now I can't just >read the right response, I have to try and write it! [snip] Hmmm... I never saw the original post, so I didn't get a chance to respond. As a bit of moral support, you wrote the correct response. To add more drama to it, RUN-RUN AWAY! FLEE FROM THE CONCEPT OF Common_Types! We have a package named precisely that here and it has been nothing but problems. It violates (insert any SW engineering term here). Yea, it's easier at first, but those abstractions we did properly are much easier to maintain, much easier to inspect/review, and much easier to use! The best thing you can do is to take the time now to DESIGN how your solution should be constructed, including maybe a framework of what _all_ (related) low level types must provide in terms of operations. Can anyone provide the reference for constructing software components done at Tri-Ada by some folks from Ohio State? (Murali Sitarmen (sp?) from EKU? would know.) Someone "borrowed" my copy of the paper and I haven't seen it since. I found it an excellent reference with several good ideas. (On a counter-argument note - didn't the STANFINS project have such a beast?) -- --------------------------------------------------------------------------- Kraig Hanson "I'm not a software engineer, but I play one on TV." Practitioner by day, instructor by night. hansonk@unomaha.edu hansonk@j63.stratcom.af.mil ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Q: common types?! 1994-10-12 17:39 ` gamache 1994-10-12 20:36 ` Kraig Hanson @ 1994-10-12 21:37 ` Robert Dewar 1 sibling, 0 replies; 7+ messages in thread From: Robert Dewar @ 1994-10-12 21:37 UTC (permalink / raw) The argument that the common types package will be frequently changed and frequently withed AND THEREFORE cause the whole system to be recompiled is bogus. Whether or not this occurs is a characteristic of your implementation. If you are using an incremental system like Dec or Rational, adding declarations to a common types package will not cause you to have to recompile any existing clients. This might happen in some systems, and needs to be considered, but it is wrong to assume it is true as a matter of course. P.S. GNAT currently does not have smart recompilation (probably a bvetter phrase than incremental system that I used above), but there is an interesting paper being given at Tri-Ada which will describe a smart recompilation system being built for use with GNAT. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1994-10-12 21:37 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1994-09-28 15:16 Q: common types?! Tony Leavitt 1994-09-29 11:37 ` Peter Hermann 1994-09-29 15:35 ` Tucker Taft 1994-10-05 4:40 ` Daniel Wengelin 1994-10-12 17:39 ` gamache 1994-10-12 20:36 ` Kraig Hanson 1994-10-12 21:37 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox