Derivation + Access Discriminant = Headaches

Derivation + Access Discriminant = Headaches

[Matthew Heaney]

Below is a tagged type hierarchy.

The root is T.  Type T has no discriminant.

Type NT derives from T, and adds a discriminant that designates T'Class.

Type NNT derives from NT, and wants to replace the inherited
discriminant with a discriminant that designates NT'Class.

My expectation is that this should be legal, because NT is in T'Class,
and should therefore be allowed to replace the discriminant that
designates T'Class.

But when I try to compile NNT, my compiler is telling me the subtype of
the discriminant is wrong:

q.ads:5:14: subtype must be compatible with parent discriminant


Is this a compiler bug?  If not, what's the rationale for the
restriction?

Thanks,
Matt


--STX
package P is

   type T is abstract tagged limited private;

   type NT (O : access T'Class) is
     abstract new T with private;

private

   type T is abstract tagged limited null record;

   type NT (O : access T'Class) is new T with null record;

end P;


with P; use P;
package Q is

   type NNT (O : access NT'Class) is
     new NT with private;

private

   type NNT (O : access NT'Class) is
     new NT (O) with null record;

end Q;

Re: Derivation + Access Discriminant = Headaches

[Richard D Riehle]

In article <m3r9qlvpuv.fsf@mheaney.ni.net>,
	Matthew Heaney <matthew_heaney@acm.org> wrote:

>Below is a tagged type hierarchy.

  [ deleted because it is shown in Matthew's code example ]

>
>My expectation is that this should be legal, because NT is in T'Class,
>and should therefore be allowed to replace the discriminant that
>designates T'Class.

 On GNAT, an equivalent type hierarchy works fine.  For simplicity I
 did not separate this into separate packages or use private types.
 However, the same discriminant rules should apply.  

 package Discriminant_Derivations is

  type Tack is tagged limited null record;
  type Tack_Reference is access all Tack'Class;

  function Get return Tack_Reference;

  type Tack_N (Data :  access Tack'Class) is new Tack
              with null record;
  

  type Tack_N1(Data : access Tack'Class) is new Tack_N(Data)
              with null record;
  
  -- This derivation constrains with a function call
  type Tack_N1(Data : access Tack'Class) is new Tack_N(Get)
              with null record;

end Discriminant_Derivations; 


I wonder if this is OK on other Ada 95 compilers.  Have not tried
Aonix with it yet.   Do not have Rational Apex handy.  

Richard Riehle
richard@adaworks.com
http://www.adaworks.com
>
>--STX
>package P is
>
>   type T is abstract tagged limited private;
>
>   type NT (O : access T'Class) is
>     abstract new T with private;
>
>private
>
>   type T is abstract tagged limited null record;
>
>   type NT (O : access T'Class) is new T with null record;
>
>end P;
>
>
>with P; use P;
>package Q is
>
>   type NNT (O : access NT'Class) is
>     new NT with private;
>
>private
>
>   type NNT (O : access NT'Class) is
>     new NT (O) with null record;
>
>end Q;
>
>
>

 

Re: Derivation + Access Discriminant = Headaches

[Matthew Heaney]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

>  On GNAT, an equivalent type hierarchy works fine.  

Which version of GNAT are you using?  On what OS?  On what machine?  

I'm having this problem using a home-grown port of v3.11p, so it may be
a porting problem.

Re: Derivation + Access Discriminant = Headaches

[Stephen Leake]

Matthew Heaney <matthew_heaney@acm.org> writes:

> Richard D Riehle <laoXhai@ix.netcom.com> writes:
> 
> >  On GNAT, an equivalent type hierarchy works fine.  
> 
> Which version of GNAT are you using?  On what OS?  On what machine?  
> 
> I'm having this problem using a home-grown port of v3.11p, so it may be
> a porting problem.

I compiled Matthew's code with GNAT 3.11p on Windows NT (the public
binary distribution) and got the error :

q.ads:4:14: subtype must be compatible with parent discriminant
gnatmake: "q.ads" compilation error

ObjectAda (same machine) gives no error.

I suspect GNAT has a compiler bug; I'll let Matthew submit it.

-- Stephe

Re: Derivation + Access Discriminant = Headaches

[Richard D Riehle]

In article <m3zp591hq6.fsf@mheaney.ni.net>,
	Matthew Heaney <matthew_heaney@acm.org> wrote:

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>>  On GNAT, an equivalent type hierarchy works fine.  
>
>Which version of GNAT are you using?  On what OS?  On what machine?  
>
>I'm having this problem using a home-grown port of v3.11p, so it may be
>a porting problem.

 Matthew,

 I am using GNAT 3.11 on Windows 95 for this experiment.  Notice that
 my code is just a little different, but the discriminant model is 
 identical.  Your example is distributed over three packages; Mine
 is all in the same package.  Yours uses limited private types and 
 mine uses public limited records.  There may some other issue that is 
 causing your error.  The discriminant constraints seem to work fine
 in GNAT 3.11, but may have a problem with limited private -- should
 not have, but nobody's perfect.  :-)

 Richard
 

Re: Derivation + Access Discriminant = Headaches

[Nick Roberts]

RM95 3.7(15):

   15  If a discriminant is used in the constraint defining the parent
       subtype, the subtype of the discriminant shall be statically
       compatible (see 4.9.1) with the subtype of the corresponding
       parent discriminant.

AARM comments:

 15.a   Reason:  This ensures that on conversion (or extension via an
        extension aggregate) to a distantly related type, if the
        discriminants satisfy the target type's requirements they
        satisfy all the intermediate types' requirements as well.

 15.b   Ramification:  There is no requirement that the new discriminant
        have the same (or any) default_expression as the parent's
        discriminant.

Thus it's no bug.

However, I don't see why redefined access discriminants shouldn't be allowed
to designate a type derived from (or within the class of) the type
designated by the corresponding parental discriminant.  An extra compiler
check would be required: if an object of type T were to be converted to type
NT (by an extension aggregate), its discriminant, O, would have to be
checked for being in NT'Class (and Constraint_Error, presumably, raised if
not).  Conversions to 'distantly related types' would still only require one
check, however, so the problem mentioned in AARM (15.a) is solved.

Possibly this is something that could be changed at the next revision, if
it's not considered an unnecessary complication (or there's some other
reason why not that I'm missing).

I guess Tuck or Bob will correct me if I'm on the wrong track here (again
;-).

-------------------------------------
Nick Roberts
-------------------------------------