Re: Access to generic formal parameters in an generic package instantiation

[Adam Beneschan <adam@irvine.com>]

On Tuesday, July 31, 2012 12:48:04 AM UTC-7, Georg Bauhaus wrote:

> Compilers seem to differ on this one, which should be Ada 95.
> I am not sure the generics are properly addressing the issue
> of type comparison (well, of convertibility).
> 
>
> With GNAT's bug boxes currently in the way I can't try the
> Ada 2012 features. (Something about failures when testing entity
> node kinds.)
> 
> 
> 
> generic
>     type T is private;
>     Fst, Snd : in T;
> package Same_Type is end;
> 
> with Same_Type;
> generic
>     type Ancestor is private;
>     type T1 is new Ancestor;
>     type T2 is new Ancestor;
>     X : T1;
>     Y : T2;
> --   with package Comparison is new Same_Type (T1, T1'(X), T1 (Y));
> 
> package Ops is
> private
>     package Comparison_1 is new Same_Type (T1, T1'(X), T1 (Y));
>     package Comparison_2 is new Same_Type (T2, T2 (X), T2'(Y));
> end;
> 
> with Same_Type, Ops;
> procedure Test_G is
>     type Int is new Integer;
>     type Chr is new Character;
>     Two : constant Int := 2;
>     C : constant Chr := 'c';
>     package Test_1 is new Ops (Int, Int, Int, Two, Two);
> --!GNAT!   package Test_2 is new Ops (Int, Int, Chr, Two, C);

GNAT gets a bug box here, but you do realize that the instantiation is illegal, right?  T2 is supposed to be derived from T1, but Chr is not derived from Int.  I'm sure you probably realize this, but it's not clear from your post what you're trying to show.

>     package PK is
>        type root is tagged null record;
>        type left is new root with null record;
>        type right is new root with null record;
>     end PK;
>     use pK;
>
>     L : Left;
>     R : Right;
>     package test_3 is new ops (Root, Left, Right, L, R);

I get an "instantiation error" when I try this with GNAT, which is usually a bad sign.  In this case, I think it's a hole in the language.  The formal types are declared without "tagged", so that while compiling the generic, they're treated as untagged.  And for untagged types, any time you have two types with the same ultimate ancestor, you can convert between them.  For tagged types, the rules are different, though, since downward conversions (from a type to its descendant) are not generally allowed, since the descendant can have new components that a conversion wouldn't be able to supply.  (I'm not sure offhand whether a downward conversion to a null extension is allowed--I'd have to look it up.)  The problem is that a generic formal untagged type can have a tagged type as an actual.  So in a case like this, where a generic contains a construct that would be legal for untagged types but illegal for tagged types, the language doesn't seem to prevent error cases from coming up.  There may be other  constructs besides type conversions that cause problems when an untagged formal has a tagged actual.

Anyway, I'll look into this further but will probably send something to Ada-Comment unless this has been brought up already.  I think it could be fixed fairly simply.  (I'm thinking that adding a rule that a generic formal untagged derived type cannot have a tagged type as an actual would work, and would be unlikely to make any existing code illegal.)

                               -- Adam