Re: Announce: Grace project site operational

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Think about why it is that Ada provides separate types with strong rules
about separate-but-equal treatment of them. Its about keeping things
separate that belong separate. So you need to ask the question "Should these
things (almost) never be mixed or confused with each other?" In my
produce-inventory-program I (almost) never have a good reason to mix up a
count of apples with a count of oranges - hence the archetypical example.

But if you're doing computations with velocities and accelerations and such,
then you thoroughly intend to mix them and you are then saying "I'm dealing
with general mathematical relationships between one thing and another" That
sort of calls for a common type of sufficient size to support the
anticipated calculations. After all, the common object of interest here is
the "mathematical relationship", not the not the particular items in some
specific engineering units.

I agree that a good compromise is to have subtypes that can then be freely
mixed with possible constraints as needed. This provides you with some
ability to distinguish in your code where you are dealing with one thing
versus another (velocities versus accelerations) and have the values sanity
checked by your constraints, while leaving you the ability to freely mix the
math operations. Of course, this doesn't save you from everything - e.g.
passing a velocity to a function that needs an acceleration - but you just
can't always have absolute safety. Absolute safety is for people who don't
have the balls to live in the real world. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205140718.3ddb1b2a@posting.google.com...
>
> That's the biggie. If you try to make separate types for velocities
> and accelerations, you will suddenly find that you also need separate
> types for times and distances, and perhaps even Hz and mass and forces
> and rotational orientations and velocitites and accelerations. Then
> you'll find how annoying it is to have to do type conversions on every
> factor in every formula. A more attractive option may be to write your
> own math operators that return the correct type given their two input
> types. But that causes an exponential growth in operators that you
> have to create every time you add a new unit.
>
> To do this kind of thing *right*, you'd really need a language that
> relies on structural equivalence for types, and automaticly generates
> the proper new type given the operator and the types of its operands.
> In Ada, you just can't do that.
>
> Generally, what I see Ada folk do is use *subtypes* for all this
> stuff. That way ranges are checked, but formulas don't become a chore
> (although you still have to be really careful with intermediate values
> blowing out of subtype constraints).
>
> --
> T.E.D.
> Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
> Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)