Re: Types with physical dimension

[rgilbert@orl.mmc.com (Bob Gilbert)]

In article km7@gnat.cs.nyu.edu, dewar@cs.nyu.edu (Robert Dewar) writes:
->strong typing is like anything else, fine in moderation, but dangerous to
->health if overdoses are encountered.
->
->there is a common tendency in Ada programming to assume that since strong
->typing is a GOOD THING, it must make sense to use it as much as possible.
->This leads to programs which thousands of different integer types and
->conversions all over the place. For my taste that actually decreases
->reliability, since 

{good stuff deleted}

I can't agree more with this.  

I my work, I deal with mostly embedded processors with lots of
interfaces to hardware. I have found that a very common mistake
is to over-type, especially on input data from less than reliable
sources.

As an example, we had an interface with an IRIG time code generator
which was supposed to generate a BCD format of the time.  One of
our programmers quickly set out to generate a BCD type to accomodate
the input.  Unfortunately, hardward does not always behave itself,
and on occasion the time code generator would lock up and produce
an output of all one's.  Well needless to say we got constraint
exceptions like crazy, and being a real-time system we could not
tolerate the indeterminate nature of exceptions (besides software
always has the burden of proving the hardware went south, and we
needed to know what the illegal values being sent to us were in
order to provide the necessary evidence). The solution was to just
accept the BCD time value as an array of bytes, and then perform 
explicit conversion of this array to either a string value for 
output to a terminal, or a numeric value for use in internal 
computations. The explicit routines to perform the conversions
would handle the case where illegal inputs were received without
the use of exception handling. Anyway, I have found it very 
useful to never place constaints on input data from outside 
sources, and explicitly check the data for correctness.

Now output data is a different matter. If I am generating something
like gimbal commands where hardware could possibly be damaged if
I output invalid or out of range values, then I definitely use
strong typing to guarantee my output. Here getting the rare exception
is usually much preferred, people get very upset when we software
types break hardware.  And of course the exception is rare since I
(sould) have control of the data.

I'm also usually very leery when constraint limits are placed on 
floats.  I've seen too many instances where a programmer generated
something like a float to represent a value from say 0..360 degrees
on a circle and found that some intermediate result would take the
value outside the range, or possibly rounding effects gave a value
of 360.00000001, or the like. Many times it is easier to track down
the error if you have the incorrect result rather than just an
exception at the point where the value went out of the type range.

-Bob