Dimensions (was Re: Another Idea for Ada 20XX)

["Mark Lundquist" <mlundquist2@attbi.com>]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C0EF0A0.9F42EDB4@adaworks.com...
>
> I don't believe it requires a change to the language.  Rather, it begs
> for a
> simple object-oriented programming solution, along with some
> old-fashioned
> encapsulation.
>
>          package Metric_Number is
>               type Metric_Type is private;
>               -- export services for arithmetic on this type
>               function "+"(L,  R : Metric_Type) return Metric_Type;
>               -- more arithmetic and boolean functions
>          private
>               -- full definition for the Metric_Type;
>               -- helper type to avoid recursion during implementation
>          end Metric_Number;

I have no idea what you're getting at with the "helper type to avoid
recursion"... :-)  But in any case, the "good old-fashioned encapsulation"
isn't enough (see below)...

>
> In this way, we can control the behavior of each function with some
> exactness
> instead of depending only on the predefined behavior of ALRM Chapter 4
> for
> numeric types.   Of course, if we also had pre- and post-conditions as
> part of
> the language, this contract could be made even more robust.

I don't see how pre- and post-conditions are relevant... ???

But anyway...

All these schemes that rely on hiding the representation have some serious
weaknesses.  First of all, the public view is not scalar.  So

(a) your type is not compatible with generics that take scalar formals --
you are limited to formal private types; and

(b) you cannot declare subtypes with range constraints.

(In my opinion (b) is by far the worse of these).

(c) it's way labor-intensive

But the worst is still to come :-).  These schemes are quite brittle and
unscalable, because:

(d) you have to define all your visibly quasi-numeric operations on every
combination of types for base and derived units, so you have a
multiplicative explosion on your hands

(e) the explosion continues if you want more than one unit per dimension.
It explodes in both new overloadings of the quasi-numeric operations, and
also in the unit conversions.

(f) all the unit types that you wish to be interoperable must be declared in
the same package, since they are private, and you can't use child packages
for this because then the operations are no longer primitive.  It requires
"prescience/ominiscience" on the part of the designer, so unless you are
really God but you just go by "Richard Riehle" on Usenet :-), it could only
be considered for self-contained software where you're "rolling your own"
and in complete control of all the code.

(g) if you wanted to have multiple types with the same unit relationships
but different representations, e.g. different delta, decimal or fixed-point
types, you are hosed -- the scheme becomes totally unmanageable at that
point.

Best Regards,
Mark