Re: Generic package array parameter

[Tucker Taft <stt@averstar.com>]

Mario Amado Alves wrote:
> 
> I am trying to rewrite
> 
> generic
>   type X is (<>);
>   type Y is (<>);
>   Table: array(X, Y) of X;
> package Foo is
> ...
> 
> in order to circuvent the 'anonymous array definition not allowed here'
> constraint. I tried
> 
> generic
>   type X is (<>);
>   type Y is (<>);
>   Table: Table_Type;
> package Foo is
>   type Table_Type is array(X, Y) of X;
> ...
> 
> and of course got '"Table_Type" is undefined'. Then I tried
> 
> generic
>   type X is (<>);
>   type Y is (<>);
>   type Table_Type is array(X, Y) of X;
>   Table: Table_Type;
> package Foo is
> ...
> 
> which of course works, but is odd, and requires an equally odd
> instantiation:
> 
> type My_X is ...;
> type My_Y is ...;
> type My_Table_Type is array(My_X, My_Y) of My_X;
> My_Table: My_Table_Type := (...);
> package My_Foo is new Foo(My_X, My_Y, My_Table_Type, My_Table);
> ...
> 
> This works, but is ugly and stupid. Is there a smart way to rewrite it?

Probably the simplest solution is to use a nested generic:

    generic
        type X is (<>);
        type Y is (<>);
    package Foo is
        type Table_Type is array(X, Y) of X;
        generic
            Table : Table_Type;
        package Inner is ...

  With this, your instantiation becomes:
    type My_X is ...
    type My_Y is ...
    package My_Foo is new Foo(My_X, My_Y);
    My_Table : My_Foo.Table;
    package My_Inner_Foo is new Foo.Inner(My_Table);

Using a nested generic is not the most obvious solution, but
they do provide a lot of power.  Note that there are other
similar (Ada95-only) solutions that are a bit more extensible, including
using a generic child package rather than a nested package,
or using a second generic that takes an instance of the
first generic as the actual for a formal package parameter.

> (I feel I am again on the verge of giving up the Ada generic programming
> idiom. What is this Ada thing with anonymous array types?)

Anonymous types are generally frowned upon because they
smack of "structural" type equality rather than "named" type
equivalence.  Named type equivalence usually provides stronger type
checking, and hence typically more compile-time detection of errors,
than structural type equivalence.  It is admittedly more
work sometimes when writing code, but Ada is definitely prejudiced
in favor of the reader over the writer.

But in any case, don't give up on Ada generics.  They provide a lot
of capability, especially when you start nesting generics and/or instances
within one another.

> Thanks.
> 
> | | |,| | | | |RuaFrancTaborda24RcD 2815-249CharnecaCaparica 351+212976751
> | |M|A|R|I|O| |                                              mob 219354005
> | |A|M|A|D|O| |DepartmentoInformaticFCT/UNL 2825-114Caparica 351+212958536
> | |A|L|V|E|S| |                                              fax 212948541
> | | | | | | | |               maa@di.fct.unl.pt              FCT 212948300

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA