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,611f4b10cbf9af69
X-Google-Attributes: gid103376,public
From: ka@socrates.hr.att.com (Kenneth Almquist)
Subject: Re: Redefinition of Equality (Long)
Date: 1996/10/07
Message-ID: <539rf2$mbh@nntpa.cb.lucent.com>#1/1
X-Deja-AN: 187228724
references: <52hgmoINN7tg@snoopy.cis.ohio-state.edu>
 <324FD267.954@cis.ohio-state.edu> <DyKEBH.Gp3@world.std.com>
 <531ng6$frs@nntpa.cb.lucent.com> <533aebINNfat@cayman.cis.ohio-state.edu>
organization: Lucent Technologies, Columbus, Ohio
newsgroups: comp.lang.ada
Date: 1996-10-07T00:00:00+00:00
List-Id: <comp.lang.ada>


dgibson@cayman.cis.ohio-state.edu (david scott gibson) asks:
> Would you allow an "in" mode formal of a mutable type to be used as an
> actual corresponding to another "in" mode parameter in a call to an
> operation declared outside the package?  That is, could the (concrete)
> value indeed be modified by an outside operation, but only if that
> operation also saw that the type in question was marked as mutable?

If I understand the question, the answer is no for private types.  In
other words, if you have:

    package Set_Package is
       type Set_Type is limited private;
       procedure Insert(Item : Integer; Set : Set_Type);
       function Is_Member(Item : Integer; Set : Set_Type) return Boolean;
    private
       pragma Mutable(Set_Type);
       type Tree_Entry;
       type Tree_Entry_Ptr is access Tree_Entry;
       type Tree_Entry is record
          Left, Right : Tree_Entry_Ptr;
          Value : Integer;
       type Set is 
    end Set_Package;

then the body of Set_Package can include

    procedure Move_To_Root(Key : Integer; Set : in out Set_Type);
       -- Moves the item containing Key to the root of the tree
       -- if it is present in the tree.

    function Is_Member(Item : Integer; Set : Set_Type) return Boolean is
    begin
       Move_To_Root(Item, Set);
       return Set /= null and then Set.Value = Item;
    end Is_Member;

Inside the body of the package there is no semantic difference between
"in" parameters and "in out" parameters, so we could equally well have
written:

    procedure Move_To_Root(Key : Integer; Set : in Set_Type);


Outside of the package, the legality of various operations is not
affected by the presence of pragma Mutable:

    procedure P(Set : in Set_Type) is
    begin
       if Is_Member(1, Set) then -- Legal
          Insert(2, Set);        -- Not legal
       end if;
    end P;

The point is that the abstract value of an "in" parameter should not be
modified.  Inside the body of the package, it is the responsibility of
the programmer to ensure this.  Outside the package the compiler will
check this.

Note that when code is generated for P, Set must be treated as an "in
out" parameter because Is_Member may modify the concrete value of Set.
This is why the pragma applies to the type, as opposed to applying to
particular operations provided by the package.

In my description, I allowed pragma Mutable to be applied to types
which are not private.  In this case there is no distinction between
inside and outside the package; an "in" parameter of the type can be
modified anywhere.  I cannot think of any valid use for this, so I'm
inclined to prohibit it.
					Kenneth Almquist