Re: Extension of non-limited type needs limited component

["Eric" <ericmueller@eastlink.ca>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccbs4q8oys.fsf@shell01.TheWorld.com...
[SNIP]>
> By the way, have you read the AARM annotations that explain why we
> didn't allow user-defined ":=" procedures?  We certainly wanted to,
> but we couldn't figure out how to make it work, so we invented Adjust,
> which is not as powerful.  I'd be interested in hearing better ideas
> (even though it's probably too late).
>
> - Bob

Hi,

(I have reproduced the relevant annotation at the end.)

The following solutions come to mind (I haven't gone through all the
possible ramifications and potential problems):

1. (The example in the AARM specifically refers to mutable,
   unconstrained record targets.)  Consider an 'operator' "<-"
   (which is the current Ada implemented 'move of value') to
   disambiguate the procedure ":=". So the present non-limited
   controlled implementation of procedure ":=" looks like:

        procedure ":="(Target : in out TYPE; Source : in TYPE) is
           [anonymous_object : TYPE <- Source;]
        begin
           Finalize(Target);
           Target <- anonymous_object;
           [Finalize(anonymous_object);]
          Adjust(Target);
        end ":=";

  Since finalization should (must) always be done before the
  target is overwritten, Finalize and "<-" (plus any other
  constraint checks) can be combined into the attribute
  Uncontrolled_Assign so that the above looks like:

        procedure ":="(Target : in out TYPE; Source : in TYPE) is
           [anonymous_object : TYPE <- Source;]
        begin
           Target'Uncontrolled_Assign(anonymous_object);
           [Finalize(anonymous_object);]
          Adjust(Target);
        end ":=";

  Thus: a user defined implementation of ":=" could be:

        procedure ":="(Target : in out TYPE; Source : in TYPE) is
           New_Source : TYPE [<- ...]; -- Finalized on procedure return
        begin

           -- Fiddle with New_Source based on both Target and
           -- Source (and constraints)
           Target'Uncontrolled_Assign(New_Source);
           -- Fiddle with Target (probably unneeded)
        end ":=";

  Note that this use of Uncontrolled_Assign would probably
  require a recheck of any constraints.

  The only problem of significance that I see is the initiation
  of New_Source and how to prevent an infinite loop if it is
  initiated (using ":=") to Source.

  Also, as ":=" is defaulted to call Adjust, current code would
  not need be rewritten.

2.  Change the assignment sequence from:

        anonymous_object <- Source
        Finalize(Target)
        Target <-anonymous_object;
        Finalize(anonymous_object)
        Adjust(Target)

  To:

        anonymous_object <- Source
        other_anonymous_object <- Target
        Finalize(Target)
        Target <- anonymous_object;
        Finalize(anonymous_object)
        Adjust(Target, other_anonymous_object) -- *****
        Finalize(other_anonymous_object)

  with Adjust taking a second 'in' argument.

  This would allow Adjust to make use of the original value of
  Target.  Not as useful as the above, but I have already met
  code where it would be useful.


Here is the annotation (reformatted from Section 7.6 of the AARM):

Reason: An alternative design for user-defined assignment might
involve an Assign operation instead of Adjust:

 procedure Assign(Target : in out Controlled;
                             Source : in out Controlled);

Or perhaps even a syntax like this:

 procedure ":="(Target : in out Controlled;
                        Source : in out Controlled);

Assign (or ":=") would have the responsibility of doing the copy,
as well as whatever else is necessary. This would have the
advantage that the Assign operation knows about both the target
and the source at the same time - it would be possible to do
things like reuse storage belonging to the target, for example,
which Adjust cannot do. However, this sort of design would not
work in the case of unconstrained discriminated variables,
because there is no way to change the discriminants
individually. For example:

type Mutable(D : Integer := 0) is
  record
    X : Array_Of_Controlled_Things(1..D);
    case D is when 17 => Y : Controlled_Thing;
              when others => null;
    end D;
  end record;

An assignment to an unconstrained variable of type Mutable can
cause some of the components of X, and the component Y, to appear
and/or disappear. There is no way to write the Assign operation
to handle this sort of case.  Forbidding such cases is not an
option - it would cause generic contract model violations.


Michael Borek "Death before Dishonour; Beer before Lunch"

Michael Borek Software Services
http://users.eastlink.ca/~borekking/professionalhome.html