Re: Generic-Package Elaboration Question / Possible GNAT Bug.

[Adam Beneschan <adam@irvine.com>]

On Nov 19, 1:14 pm, Shark8 <onewingedsh...@gmail.com> wrote:
> I was working on some simple little array manipulation functions when
> I encountered an interesting behavior in the compiler; it said that
> trying to instantiate a function of the form:
>    Generic
>       Type Element is Private;
>       Type Index_Type is (<>);
>       Type Array_Type is Array (Index_Type Range <>) of Element;
>    Function Generic_Delete( Index : In Index_Type; Data : In
> Array_Type ) Return Array_Type;
>
> When given the following body, the compiler complained about the
> Index_Range'First/Last not being static:
>
>    Function Generic_Delete( Index : In Index_Type; Data : In
> Array_Type ) Return Array_Type is
>    begin
>       if Index not in Data'Range then
>          Raise Constraint_Error;
>       else
>            case Index is
>            when Index_Type'First => Return
> Data( Index_Type'Succ(Index)..Data'Last );
>            when Index_Type'Last => Return
> Data( Data'First..Index_Type'Pred(Index) );
>            when others =>
>                   Return Data( Data'First..Index_Type'Pred(Index) )
>                  & Data( Index_Type'Succ(Index)..Data'Last );
>            end case;
>       end if;
>    end Generic_Delete;
>
> Now, I know that the following works as a fix:
>
>      Function Generic_Delete( Index : In Index_Type; Data : In
> Array_Type ) Return Array_Type is
>      begin
>         if Index not in Data'Range then
>            Raise Constraint_Error;
>         else
>            if Index = Data'First then
>               Return Data( Index_Type'Succ(Index)..Data'Last );
>            elsif Index = Data'Last then
>               Return Data( Data'First..Index_Type'Pred(Index) );
>            else
>               Return Data( Data'First..Index_Type'Pred(Index) )
>                  & Data( Index_Type'Succ(Index)..Data'Last );
>            end if;
>         end if;
>      end Generic_Delete;
>
> But the question that came to my mind after reading the ARM section on
> the error (sorry, I forgot to write it down) is, why is it not static?
> Is it because though the elaboration-parameters *may* be known [and
> static] at compile-time that some instantiation might NOT be
> [guaranteed] to be known at compile-time? (i.e. because the compiler
> cannot guarantee that you won't throw 1..N where N is something pulled
> from the user-input?)

I think one thing to keep in mind is that it's legal in Ada to compile
the specification of a generic, and *then* compile one or more
instances of the generic, before the generic body is ever seen.  So
say you compile source S1 containing the specification of
Generic_Delete, and then compile source S2 which instantiates
Generic_Delete with Index_Type => Some_Subtype where Some_Subtype has
a non-static bound (like your 1..N).  Later, you compile source S3
containing the body of Generic_Delete.  If the CASE statement you
wrote were legal, it would make source S2 illegal retroactively, which
isn't really feasible.  I think that's one reason, perhaps the main
reason, why the Ada rules are written the way they are---a generic
body has to be legal for all possible instantiations for which the
specification is legal.

                          -- Adam