Re: Better control of assignment

[Craig Carey <research@ijs.co.nz>]

On Sat, 10 Nov 2001 22:27:25 GMT, Jeffrey Carter <jrcarter@acm.org>
wrote:

>Nick Roberts wrote:
>> 
>> "Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
>> > Assignment should not be able to modify the RHS, especially as it may be
>> > an expression, not a variable.
>> 
>> Perhaps the name Assign is wrong. Maybe Copy would be better. To my mind, it
>> seems obvious (of course ;-) that if the RHS is a constant, this procedure
>> is not invoked; it is only invoked for a copy (including parameter passing
>> by copy (if selected)) from one variable object of type T to another. If
>> this does not deliver enough control, you must make the type private. For
>> example:
>> 
>>    type Odd_Counter is new Integer;
>>    procedure Assign_Odd (Src, Tgt: in out Odd_Counter);
>>    for Odd_Counter'Copy use Assign_Odd;
>>    ...
>>    procedure Assign_Odd (Src, Tgt: in out Odd_Counter) is
>>    begin
>>       if not Is_Odd(Src) then
>>          raise Oddness_Error;
>>       else
>>          Tgt := Src; -- inherited assignment used here by a language rule
>>       end if;
>>    end;
>
>There is still no need for Src to be mode in out.

---

>Nick Roberts wrote:
>> 
>> However, it seems feasible to me to introduce a new finalisation 
>> in the next revision. All we really need (am I wrong?) is three
>> attributes,
...
>>    procedure T'Construct (Object: in out T);
>>    procedure T'Destroy (Object: in out T);
>>    procedure T'Assign (Source, Target: in out T);
>
>Assignment should not be able to modify the RHS, especially as it may
> be an expression, not a variable.
>

Are you sure you want to allow Strings to be destroyed?.

Suppose the pointers got copied, as in this example:

procedure Crash_Ada is
   A, B, C : Unlimited_String;
begin
   Make_New (A);
   B.Ref := A.Ref;
   B.Length := ...
   C.Ref := A.Ref;
      --  At scope exit, the Destructor presumably is called onto all
      --  3 variables.
end Crash_Ada;

A fix is to stop the assignments to the ".Ref" fields.
There could be an agreement that we want to allow assigning to the
Length and Ref.all fields to quite available to packages with-ing
the package.

The whole program could crash when the Destructor frees the same
memory twice.

---

One problem is that letting the programmer do a swapping assign
instead of a copying assign, e.g.

       A :=. B

is that the routine holding B might have to be recoded like this:

From:

    procedure T (B : in Unlimited_String)

into:

    procedure T (B : in out Unlimited_String).

That is undesirable and it may be possible to allow records to have
read-only fields that can be altered (by routines declared in the same
package that declares the type), even though they are supposed to be
constant because they are an "in" mode parameter.

An aim here is to not force people to have pointers to pointers just
to avoid rewritng

   procedure F (B : in Unlimited_String.Vstr) is
   begin
      A :=. B;   --  Fast Assign with pointer swapping and loss of RHS
   end F;

as 

   procedure F (B : in Unlimited_String.Vstr) is
   begin
      A :=. B;
   end F;


It can be just a matter of adding the "out" mode to a record field
which makes the type have a read-only field.

An example of a new proposed feature for Ada:

package Q is
   type Vstr is
      record                             --  Ref is exported read only
         Ref      : out String_Access := Null_String_Access;
         Length   : Natural := 0;
      end record;
   procedure ":=." (L : out Vstr; R : in Vstr);
      --  Swaps pointers and changes the pointer value, R.Ref. It is
      --   read-only, not constant.
end Q;

package body Q is
   procedure ":=." (L : out Vstr; R : in Vstr) is
      Tmp    : Access_String;   --  Fast assign with ptr swapping
   begin
      LHS.Length := RHS.Length;
      Tmp := LHS.Ref;
      LHS.Ref := RHS.Ref;
      RHS.Ref := Tmp;
      RHS.Length := 0;     --  Invalidate the RHS pointer
   end ":=.";
end Y;

procedure R (B : in Q.Vstr) is
   A    : Q.Vstr;
begin
   Unknown1 (Alter_It => B);  --  This proc is not able to alter B.Ref
                              --  but it can change B.Ref.all.

   ...       --  Final access of the data from B destroys it.
             --  It is either that for inefficiency or lazy ":="-ing

   A :=. B;  --  B.Ref can be changed by the Fast Assignment operator
             --  since it is in the package defining (or extending)
             --   the type. That B (and B.Ref) is of the "in" mode
             --   would not stop any routine in Q from altering B.Ref.
   ...
end R;


A big advantage of that is that there are no pointers to pointers to
mislead the language into believing a value changed is not.


Maybe lazy assignments could be slower and it is not clear why such
a complex scheme ought be implented, with its destructors, when this
far simpler can't properly get destructors.

http://groups.google.com/groups?hl=en&rnum=11&selm=dewar.848839209%40merv

  > From: Robert Dewar
  > Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once
  >   again, Ada absent from DoD SBIR solicitation)) 
  > Newsgroups: comp.lang.ada
  > Date: 1996/11/24 

Mr Dewar's lazy assignment idea might not be a remedy for the problem
of slow String handling code.

To put a pointer inside of a record and make it private or limited,
won't stop writing to the pointer while allowing writing to the ".all"
value. It is a bug in the language. No is "access constant [subtype]"
helpful.

Maybe M Carter can come up with an example arguing for user defining
of assignment that keeps away from Strings where what seem to be
language design defects become explicit.

When there are two pointers, then the first pointer can be made a
pointer to a 2nd pointer that is defined to be of this type:

   type [name] is access constant [second_pointer_subtype];

That stops all alteration of the B.Ref1.Ref2 while fully allowing
alterating of

     B.Ref1.Ref12.all (1 .. Sockets_Buffer_Maxlength).