TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding: 7bit
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: Stanley Allen <[log in to unmask]>
Date: Wed, 14 Jul 1999 21:20:29 -0500
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Reply-To: Stanley Allen <[log in to unmask]>
Parts/Attachments: text/plain (108 lines)
Teamers:

I posted this on CLA, but I think there is a problem with the
news server where I work.

Language lawyers and philosophers:

Two Ada 95 compilers treat the code below differently, and
I am unsure which one (if either) 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:[log in to unmask]

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

ATOM RSS1 RSS2