From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3f4890cc4de8ebc2,start
X-Google-Attributes: gid103376,public
From: "Stanley R. Allen" <s_allen@hso.link.com>
Subject: Derivation, discriminants, and views.
Date: 1999/07/12
Message-ID: <378A5C0B.EFD41854@hso.link.com>#1/1
X-Deja-AN: 500260256
Content-Transfer-Encoding: 7bit
Organization: NASA, Kennedy Space Center
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-07-12T00:00:00+00:00
List-Id: <comp.lang.ada>


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