Supplying a parameter for "digits"

Supplying a parameter for "digits"

[Richard A. O'Keefe]

I want to write a generic package that takes two floating point types.
Within that package, I want to have a floating point type which is at
as precise as the more precise of the two parameter types.

If I could, this is what I would write:

    generic

	type Coord is digits <>;
	type Value is digits <>;

    package Example is

	type Product is digits Max(Coord'Digits, Value'Digits);

I _don't_ want to specify System.Max_Digits, or Long_Float, or anything
like that; if I was happy with that I could stick with Fortran or C.

In Ada 83 I couldn't say this because there was no Max.
In Ada 95, Digits is of type universal_integer, but 'Max must be tied
to some named type, so the obvious thing is to try

	type Product is
	    digits Integer'Max(Coord'Digits, Value'Digits);

Unfortunately, GNAT says 
	"non-static expression used for digits value".

Quoting the AARM (5.95) Section 4.9 para 1
	[{static} Static means determinable at compile time,
	 using the declared properties or values of the program entities.]
which is what I thought static was supposed to mean, and why I though
Max(Coord'Digits, Value'Digits) *should* be static.

Now,
	Integer is a static scalar subtype (para 26),
	'Max is a language-defined attribute that is a function.
	In Integer'Max, the prefix denotes a static scalar subtype,
	the parameter and result types are scalar (para 22),
So,
	if Coord'Digits and Value'Digits are static expressions,
	Integer'Max(Coord'Digits, Value'Digits) is (para 6).

Also,
	T'Digits is an attribute reference that yields a scalar,
	so is a static expression if T is a static scalar subtype (para 7).

So all I have to show is that Coord and Value are static scalar subtypes,
and they are certainly scalar.  Para 26 tells me that the subtype of a
generic formal OBJECT of mode in out is not static, but these are generic
formal TYPES.

Oh DRAT.  I just saw it:
    "A static scalar subtype is an unconstrained scalar subtype
     whose type is NOT A DESCENDANT OF A FORMAL SCALAR TYPE".
Curse.

Thus it appears that I cannot do what I want in Ada 95 either:
	type T is digits E;
cannot mention any attribute of a generic formal type in the expression E.
I can't even say
	type T is digits Coord'Digits;
though of course I can still say
	type T is new Coord;


For several years I have gone around thinking that
    "One of the reasons Ada is a better language for numerical calculations
    than Fortran is that the body of an Ada package can adjust in sensible
    ways to the attributes of its numeric type parameters."
and now I find that this is not true.

WHY isn't it true?
WHY can't I define a package-internal type in terms of the precisions of
its formals?

Of course there is the trivial answer "because the standard says so".
But there has to be a more interesting answer than that.

A macro-expansion approach to generic packages would presumably have little
or no trouble with this construction.  Is this restriction in there to
support some other approach?  But why restrict the ability to adaptively
define floating point types, when the ability to adaptively define array
types is there?  How can the one be harder than the other?

And is there anything I can do to get what I want short of forcing the
package user to declare and provide a suitable type?

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Supplying a parameter for "digits"

[John Herro]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)
would like to write
> generic
>    type Coord is digits <>;
>    type Value is digits <>;
>    package Example is
>       type Product is
>          digits Integer'Max(Coord'Digits, Value'Digits);
but the last line quoted won't compile because the expression isn't
static.

     I don't have the answer, but I can shed a *little* light on the
subject.
     It would *seem* from 4.9(1) that anything that can be evaluated at
compile time "should" be considered a static expression.  However, the
forms that actually *are* considered static expressions are listed in
4.9(2) through 4.9(13).  Unfortunately, what you want to write isn't on
the list.  I have to admit, though, that (6) and (7) come tantalizingly
close.
     Last January there was a thread here about the expression A(0), where
A is a *constant* array.  You would certainly think that A(0) "ought" to
be a static expression, but it isn't.  Of course, a smart compiler might
evaluate A(0) at compile time and use the result in optimizations, but
unfortunately it still doesn't count as a static expression for the rules
of Ada syntax.
     The only rationale mentioned in the earlier thread is that they "had
to draw the line somewhere" (in terms of how complex an expression could
be considered static).  They drew it in 4.9(2) through 4.9(13).
     Unfortunately, I don't know how to set up your generic package the
way you want.  Anyone have any ideas?
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: Supplying a parameter for "digits"

[Kevin J. Weise]

johnherro@aol.com (John Herro) wrote:
>ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)
>would like to write
>> generic
>>    type Coord is digits <>;
>>    type Value is digits <>;
>>    package Example is
>>       type Product is
>>          digits Integer'Max(Coord'Digits, Value'Digits);
>but the last line quoted won't compile because the expression isn't
>static.
>
>     I don't have the answer, but I can shed a *little* light on the
>subject.
>     It would *seem* from 4.9(1) that anything that can be evaluated at
>compile time "should" be considered a static expression.  However, the
>forms that actually *are* considered static expressions are listed in
>4.9(2) through 4.9(13).  Unfortunately, what you want to write isn't on
>the list.  I have to admit, though, that (6) and (7) come tantalizingly
>close.
>    . . .
>Unfortunately, I don't know how to set up your generic package the
>way you want.  Anyone have any ideas?

Well, I don't think this will help much; but after giving the problem
about 30 sec thought, I figured you could have *two* versions of your
generic package.  Each version will declare type Product with respect to 
one of the desired generic formal parameters, e.g.:

 generic
    type Coord is digits <>;
    type Value is digits <>;
    package Example is
       type Product is digits Coord'Digits;
       ...
    end Example;

--OR--

 generic
    type Coord is digits <>;
    type Value is digits <>;
    package Example is
       type Product is digits Value'Digits;
       ...
    end Example;

One could even put an elaboration check into the package body to ensure 
that the larger of the two is properly selected, viz.:

    package body Example is
       ...
    begin
       if Product'Digits < Value'Digits then
          raise {some appropriately named exception};
       end if;
    end Example;

-- OR --

    package body Example is
       ...
    begin
       if Product'Digits < Coord'Digits then
          raise {some appropriately named exception};
       end if;
    end Example;

Then the user must select one of these versions based upon knowledge of 
the generic actual parameters, and the problem gets shifted from design to 
configuration management (i.e. when the remainder of the package gets 
changed, the change must be propagated to both versions).  With this 
approach, one could use a good SCM tool that provides selection of 
alternative code segment choices, based on some user declaration.

Of course, I hope someone comes up with a better solution.

>- John Herro
>Software Innovations Technology
>http://members.aol.com/AdaTutor
>ftp://members.aol.com/AdaTutor

Kevin J. Weise             email:  kweise@sed.redstone.army.mil
COLSA Corporation          voice:  (205) 842-9083
Huntsville, AL

.. standard disclaimers apply