Re: Supplying a parameter for "digits"

["Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil>]

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