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

[Richard Riehle <richard@adaworks.com>]

Mark Lundquist wrote:

> "Richard Riehle" <richard@adaworks.com> wrote in message
> news:3C0EF0A0.9F42EDB4@adaworks.com...
>
> >
> >          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"... :-)

In implementing the infix operators for an experimental version of this
package, I found myself having to solve the problem of having the
full definition of the type as a numeric type itself.

> But in any case, the "good old-fashioned encapsulation"
> isn't enough (see below)...

> 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

Granted.  One would be required to write one's own versions of the generics
and that would be a really bad idea.   Once again, I experimented with this
and ended up with some truly baroque code; workable but baroque.

> (b) you cannot declare subtypes with range constraints.

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

Actually, I think (a) is worse than (b).   One could define the package
as generic and include generic formal parameters for the range constraints.

> (c) it's way labor-intensive

In experimenting with this idea, I found that I could factor out some properties

to make it less labor-intensive than it might seem to be at first glance.
Nevertheless,
you are correct that it is more labor intensive than the more straigthforward
approach
orginally suggested.

> 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

In fact, I designed some generics to test this and found that the real problems
are: 1)  no notion of zero,  2) difficult to determine the 'Last and 'First, and

3) most other normally available attributes are not available.

> (e) , (f), and (g) from your posting.

I give you the points on those.

My suggestion, however, does work for some situations.  In experimenting with
this
idea, I decided to export the appropriate mathematical functions after
instantiating
the generic elementary functions within the body for the abstract number.   I
agree
that the final numeric package is very specialized but it seems to have a small
range of applicability for some circumstances.

Meanwhile, I am experimenting with other options that might permit a solution
without new language features.   I will report on my findings if they are at all

interesting.

Richard Riehle