TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Stanley Allen <[log in to unmask]>
Wed, 14 Jul 1999 21:20:29 -0500
text/plain; charset=us-ascii
Stanley Allen <[log in to unmask]>
text/plain (108 lines)

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;


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

end Pack2;

package body Pack2 is

    procedure Increment (B : in out Basic'Class) is
        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


    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;
        Temp := new Fancy (N => Init);
        Basic (Temp.all).Item := Init.all;
        return Temp;
    end New_Fancy;

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

end Pack2.Child;