comp.lang.ada
 help / color / mirror / Atom feed
* 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