Derivation, discriminants, and views.

Derivation, discriminants, and views.

[Stanley R. Allen]

Language lawyers and philosophers:

The packages Pack2 and Pack2.Child given below are treated differently
by two Ada 95 compilers.  I am unsure about which one is correct.  From
the partial view, type Basic is unconstrained.  The full view of Basic
is constrained.  The spec of Pack2.Child derives a new type from Basic
in the partial view (visible part) and adds a discriminant.  This seems
like it should be illegal according to RM95 3.7(13) -- and that is
the interpretation of the compiler I am calling COMPILER A.  COMPILER B
has a different interpretation; see the comments in the spec of package
Pack2.Child.

So, I have three questions: which compiler is correct?  If COMPILER B
is correct, which rules make it so?  And if COMPILER B is correct,
doesn't this represent a language anomoly, because the 'clients' of
package heirarchy Pack2 'see' a violation of RM95 3.7(13)?

Stanley Allen
mailto:s_allen@hso.link.com

------------------------------------------------------------
package Pack2 is

    type Basic (<>) is abstract tagged limited private;

    procedure Increment (B : in out Basic'Class);

    procedure Operation (B : in out Basic) is abstract;

private

    type Basic is abstract tagged limited
        record
            Item : Integer;
        end record;

end Pack2;

package body Pack2 is

    procedure Increment (B : in out Basic'Class) is
    begin
        B.Item := B.Item + 1;
    end Increment;

end Pack2;

package Pack2.Child is

    type Fancy (N : access Integer) is new Basic with private;
-------------------------------------------^
--  Fancy is derived from an unconstrained type, in this view
--
--  COMPILER A complains, referencing RM95 3.7(13)
--  COMPILER B accepts, here is a comment from vendor B:
--
--  "COMPILER B is correct here, the declaration of derived type Fancy
--  in your example is legal.  The full type is derived from a
--  constrained view of the parent type and doesn't violate the
--  stated rule."
--
--  COMPILER B reports an error if Fancy is not a private type, but is
--  declared instead as this:
--
--  type Fancy (N : access Integer) is new Basic with null record;
--

    type Fancy_Ptr is access all Fancy'Class;

    function New_Fancy (Init : access Integer) return Fancy_Ptr;

    procedure Operation (F : in out Fancy);   -- override

private

    type Fancy (N : access Integer) is new Basic with null record;
-------------------------------------------^
--  Fancy is derived from a constrained type, in this view
--

end Pack2.Child;

package body Pack2.Child is

    function New_Fancy (Init : access Integer) return Fancy_Ptr is
        Temp : Fancy_Ptr;
    begin
        Temp := new Fancy (N => Init);
        Basic (Temp.all).Item := Init.all;
        return Temp;
    end New_Fancy;

    procedure Operation (F : in out Fancy) is
    begin
        null;
    end Operation;

end Pack2.Child;
---------------------------------------------------------------

Re: Derivation, discriminants, and views.

[Tucker Taft]

Stanley R. Allen wrote:
> 
> Language lawyers and philosophers:
> 
> The packages Pack2 and Pack2.Child given below are treated differently
> by two Ada 95 compilers.  I am unsure about which one is correct.  From
> the partial view, type Basic is unconstrained.  The full view of Basic
> is constrained.  The spec of Pack2.Child derives a new type from Basic
> in the partial view (visible part) and adds a discriminant.  This seems
> like it should be illegal according to RM95 3.7(13) -- and that is
> the interpretation of the compiler I am calling COMPILER A.  COMPILER B
> has a different interpretation; see the comments in the spec of package
> Pack2.Child.
> 
> So, I have three questions: which compiler is correct?  

Compiler B -- the declaration of the private extension is legal. 

> ... If COMPILER B
> is correct, which rules make it so?  

RM95 7.3(9)

> ... And if COMPILER B is correct,
> doesn't this represent a language anomoly, because the 'clients' of
> package heirarchy Pack2 'see' a violation of RM95 3.7(13)?

The paragraph 3.7(13) applies only to "types defined by a derived_
type_definition."  The declaration of a private extension does not
involve a "derived_type_definition."  

It is important to remember that in a private extension declaration,
only an *ancestor* subtype is specified, not the direct parent.  The
full type definition can specify some other type as the direct parent.
Take a look at paragraphs 7.3(8) and 7.3(9).

In any case, "seeing" a violation of 3.7(13) is not so terrible.
In this case, the only conclusion to be drawn is that the full type
definition does not violate 3.7(13), and that the discriminants of the
derived type are as specified in the declaration of the private extension.

> Stanley Allen
> mailto:s_allen@hso.link.com
> 
> ------------------------------------------------------------
> package Pack2 is
> 
>     type Basic (<>) is abstract tagged limited private;
> 
>     procedure Increment (B : in out Basic'Class);
> 
>     procedure Operation (B : in out Basic) is abstract;
> 
> private
> 
>     type Basic is abstract tagged limited
>         record
>             Item : Integer;
>         end record;
> 
> end Pack2;
> 
> package body Pack2 is
> 
>     procedure Increment (B : in out Basic'Class) is
>     begin
>         B.Item := B.Item + 1;
>     end Increment;
> 
> end Pack2;
> 
> package Pack2.Child is
> 
>     type Fancy (N : access Integer) is new Basic with private;
> -------------------------------------------^
> --  Fancy is derived from an unconstrained type, in this view
> --
> --  COMPILER A complains, referencing RM95 3.7(13)
> --  COMPILER B accepts, here is a comment from vendor B:
> --
> --  "COMPILER B is correct here, the declaration of derived type Fancy
> --  in your example is legal.  The full type is derived from a
> --  constrained view of the parent type and doesn't violate the
> --  stated rule."
> --
> --  COMPILER B reports an error if Fancy is not a private type, but is
> --  declared instead as this:
> --
> --  type Fancy (N : access Integer) is new Basic with null record;
> --
> 
>     type Fancy_Ptr is access all Fancy'Class;
> 
>     function New_Fancy (Init : access Integer) return Fancy_Ptr;
> 
>     procedure Operation (F : in out Fancy);   -- override
> 
> private
> 
>     type Fancy (N : access Integer) is new Basic with null record;
> -------------------------------------------^
> --  Fancy is derived from a constrained type, in this view
> --
> 
> end Pack2.Child;
> 
> package body Pack2.Child is
> 
>     function New_Fancy (Init : access Integer) return Fancy_Ptr is
>         Temp : Fancy_Ptr;
>     begin
>         Temp := new Fancy (N => Init);
>         Basic (Temp.all).Item := Init.all;
>         return Temp;
>     end New_Fancy;
> 
>     procedure Operation (F : in out Fancy) is
>     begin
>         null;
>     end Operation;
> 
> end Pack2.Child;
> ---------------------------------------------------------------

-- 
-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