Extended return question

Extended return question

[Dale Stanbrough]

The purpose of an extended return is to create the values in-situ 
without copying. However an exception in the middle of the extended 
return seems to indicate otherwise (using Gnat).

Is this the expected behaviour, or is my understanding of the extended 
returns correct?

Thanks,

Dale


-------------------------------------------------
with Ada.Text_IO;         use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;

procedure Returning_Large_Objects is

   type List is array (1..4) of Integer;
   
   
   function Extended_Return_Error (Raise_Exception : Boolean)
   return List
   is
   begin
      return L : List do
          L (1) := 1; L (2) := 2;
          if Raise_Exception then raise Constraint_Error; end if;
          L (3) := 3; L (4) := 4;
      end return;
   end;

   Destination : List;

   -------------------------------
   procedure Put (Item : List) is
   begin 
      for i in Item'range loop
         Put (Item (I));
      end loop;
      New_Line;
   end;

begin

   -- run normally, no exception

   Destination := (others => 0);

   Put (Destination);
   Destination := Extended_Return_Error (false);   
   Put (Destination);

   -- displays 1 2 3 4 as expected

   ---------------------------------
   -- run with exception in middle

   Destination := (others => 0);
   Put (Destination);
   begin
      Destination := Extended_Return_Error (true);
   exception
      when others => null;
   end;
   
   Put (Destination);
   -- displays 0 0 0 0, i expected 1 2 0 0

   -- the exception seems to have affected statements
   -- that precede it

   
end Returning_Large_Objects;

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Extended return question

[Georg Bauhaus]

Dale Stanbrough wrote:
> The purpose of an extended return is to create the values in-situ 
> without copying.

_Limited_ objects can be initialized in situ by an aggregate
or function call  ... :-)


-- 
Georg Bauhaus
Y A Time Drain  http://www.9toX.de

Re: Extended return question

[Dale Stanbrough]

Georg Bauhaus wrote:

> Dale Stanbrough wrote:
> > The purpose of an extended return is to create the values in-situ 
> > without copying.
> 
> _Limited_ objects can be initialized in situ by an aggregate
> or function call  ... :-)


Ah, thanks.  I had misread John Barnes comments on this. Why such a 
restriction? Why not allow it for all extended returns on all types?

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Extended return question

[Adam Beneschan]

On Jul 10, 12:32 am, Dale Stanbrough <MrNoS...@bigpoop.net.au> wrote:
> Georg Bauhaus wrote:
> > Dale Stanbrough wrote:
> > > The purpose of an extended return is to create the values in-situ
> > > without copying.
>
> > _Limited_ objects can be initialized in situ by an aggregate
> > or function call  ... :-)
>
> Ah, thanks.  I had misread John Barnes comments on this. Why such a
> restriction? Why not allow it for all extended returns on all types?

For nonlimited types, function calls work the same way they've always
worked since Ada 83.  The function call builds an anonymous object.
In your example, since you're using an assignment, the anonymous
object is then assigned into Destination.  But of course, if the
function raises an exception, the assignment never takes place.

This isn't too different from this situation, which has always existed
since Ada 83:

   Destination := (1 => Func1, 2 => Func2, 3 => Func3, 4 => Func4);

If Func1 and Func2 complete normally, but Func3 raises an exception,
*no* elements of Destination are changed.  Extended return is no
different.  Function calls still involve anonymous objects to hold the
function result, and extended return doesn't change that.

Hope this helps,

                              -- Adam

Re: Extended return question

[Dale Stanbrough]

Adam Beneschan wrote:


> Hope this helps,

Yes it does.

Thanks for the info everyone. Back on the right track again.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Extended return question

[Randy Brukardt]

"Dale Stanbrough" <MrNoSpam@bigpoop.net.au> wrote in message 
news:MrNoSpam-BCD9C2.17322110072008@news-server.bigpond.net.au...
> Georg Bauhaus wrote:
>
>> Dale Stanbrough wrote:
>> > The purpose of an extended return is to create the values in-situ
>> > without copying.
>>
>> _Limited_ objects can be initialized in situ by an aggregate
>> or function call  ... :-)
>
>
> Ah, thanks.  I had misread John Barnes comments on this. Why such a
> restriction? Why not allow it for all extended returns on all types?

Build-in-place is *allowed* for all objects; it is only *required* for types 
that always have to be limited (now known as "immutably limited types" (see 
AI05-0052-1).

The reason it is not required is that the function could be used in an 
assignment statement, and in that case, it doesn't make sense to require 
build-in-place. And trying to have a function that works both ways could be 
expensive to implement (the calling conventions are very different).

                                 Randy.

Re: Extended return question

[Adam Beneschan]

On Jul 10, 4:20 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Dale Stanbrough" <MrNoS...@bigpoop.net.au> wrote in message
>
> news:MrNoSpam-BCD9C2.17322110072008@news-server.bigpond.net.au...
>
> > Georg Bauhaus wrote:
>
> >> Dale Stanbrough wrote:
> >> > The purpose of an extended return is to create the values in-situ
> >> > without copying.
>
> >> _Limited_ objects can be initialized in situ by an aggregate
> >> or function call  ... :-)
>
> > Ah, thanks.  I had misread John Barnes comments on this. Why such a
> > restriction? Why not allow it for all extended returns on all types?
>
> Build-in-place is *allowed* for all objects; it is only *required* for types
> that always have to be limited (now known as "immutably limited types" (see
> AI05-0052-1).

Where does the RM say that build-in-place is allowed for all objects?
The only place I can see that refers to build-in-place for nonlimited
objects is 7.6(21), and that permission seems to apply only to
controlled objects.

Also, the language there says that if a function call is assigned into
a target object, an anonymous object doesn't need to be created if the
value of the function call can be "safely" created in the target
object.  But "safely" isn't defined.  If the function could create
part of the target object and then terminate on an exception, as in
Dale's original example, is that considered "unsafe", which would mean
build-in-place isn't allowed for this function call?  If it doesn't
mean that, what does "safely" mean?

                                  -- Adam

(Note: I will not see any response until 7/22)

Re: Extended return question

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> On Jul 10, 4:20 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> "Dale Stanbrough" <MrNoS...@bigpoop.net.au> wrote in message
>>
>> news:MrNoSpam-BCD9C2.17322110072008@news-server.bigpond.net.au...
>>
>> > Georg Bauhaus wrote:
>>
>> >> Dale Stanbrough wrote:
>> >> > The purpose of an extended return is to create the values in-situ
>> >> > without copying.
>>
>> >> _Limited_ objects can be initialized in situ by an aggregate
>> >> or function call  ... :-)
>>
>> > Ah, thanks.  I had misread John Barnes comments on this. Why such a
>> > restriction? Why not allow it for all extended returns on all types?
>>
>> Build-in-place is *allowed* for all objects; it is only *required* for types
>> that always have to be limited (now known as "immutably limited types" (see
>> AI05-0052-1).
>
> Where does the RM say that build-in-place is allowed for all objects?
> The only place I can see that refers to build-in-place for nonlimited
> objects is 7.6(21), and that permission seems to apply only to
> controlled objects.
>
> Also, the language there says that if a function call is assigned into
> a target object, an anonymous object doesn't need to be created if the
> value of the function call can be "safely" created in the target
> object.  But "safely" isn't defined.  If the function could create
> part of the target object and then terminate on an exception, as in
> Dale's original example, is that considered "unsafe", which would mean
> build-in-place isn't allowed for this function call?  If it doesn't
> mean that, what does "safely" mean?

For:

    X := F(...);

the language rules require that X not be modified in case of exceptions
in F.  Of course the type of X is nonlimited here.

- Bob 

Re: Extended return question

[Robert A Duff]

Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes:

> The purpose of an extended return is to create the values in-situ 
> without copying.

No, that's not correct.  Limited function results are built in place,
nonlimited ones are not.  It's got nothing to do with which sort of
return statement you use -- limited builds in place even when you
say "return <expression>;".

The purpose of extended return is to give a name to the result, so you
can poke at it, or assert things about it, etc.  This capability is
needed for limited types, but is also useful for nonlimited types.

Your example below uses a nonlimited type, and it would be wrong for the
compiler to use build-in-place in this case -- the left-hand side of an
assignment must not be modified if the right-hand side raises an
exception.

An implementation can use build-in-place for nonlimited types, but only
in cases where it can prove that there is no visible difference, such as
when you are initializing a new object, or if there are no references to
the object in any relevant exception handler.  The example below is not
such a case.

I intend to make GNAT use build-in-place for nonlimited types in some
cases someday, for efficiency.  But it's low priority.

- Bob

> -------------------------------------------------
> with Ada.Text_IO;         use Ada.Text_IO;
> with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
>
> procedure Returning_Large_Objects is
>
>    type List is array (1..4) of Integer;
>    
>    
>    function Extended_Return_Error (Raise_Exception : Boolean)
>    return List
>    is
>    begin
>       return L : List do
>           L (1) := 1; L (2) := 2;
>           if Raise_Exception then raise Constraint_Error; end if;
>           L (3) := 3; L (4) := 4;
>       end return;
>    end;
>
>    Destination : List;
>
>    -------------------------------
>    procedure Put (Item : List) is
>    begin 
>       for i in Item'range loop
>          Put (Item (I));
>       end loop;
>       New_Line;
>    end;
>
> begin
>
>    -- run normally, no exception
>
>    Destination := (others => 0);
>
>    Put (Destination);
>    Destination := Extended_Return_Error (false);   
>    Put (Destination);
>
>    -- displays 1 2 3 4 as expected
>
>    ---------------------------------
>    -- run with exception in middle
>
>    Destination := (others => 0);
>    Put (Destination);
>    begin
>       Destination := Extended_Return_Error (true);
>    exception
>       when others => null;
>    end;
>    
>    Put (Destination);
>    -- displays 0 0 0 0, i expected 1 2 0 0
>
>    -- the exception seems to have affected statements
>    -- that precede it
>
>    
> end Returning_Large_Objects;
>
> -- 
> dstanbro@spam.o.matic.bigpond.net.au

Re: Extended return question

[Adam Beneschan]

On Jul 10, 7:37 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Dale Stanbrough <MrNoS...@bigpoop.net.au> writes:
> > The purpose of an extended return is to create the values in-situ
> > without copying.
>
> No, that's not correct.  Limited function results are built in place,
> nonlimited ones are not.  It's got nothing to do with which sort of
> return statement you use -- limited builds in place even when you
> say "return <expression>;".

Actually, the situation with limited types isn't totally clear,
either.  However, for limited types, there's no way Dale could test
this using the sort of example he used above, since he used his
Extended_Return_Function on the right-hand side of an assignment,
which wouldn't be allowed for a function returning a limited type.  If
he tried to use the function call as an initializer for some object X,
and the function raised an exception and left, there's no way X could
be examined to determine whether some of the components of X were set.

But in AI05-67, I did come up with an example where an extended return
with a limited function result was left with a GOTO, and the function
then did another extended return, and I had a question about whether
the components set up by the first extended return (if not overwritten
by the second) were required to show up in the result.  Your answer,
Bob, was "no", and I think that if AI05-67 is adopted, the answer will
still be "no", because this AI says that the function result object
does not "morph" into the created object until the return is
completed.  The upshot of this AI is, I think, that (1) the object
being worked on for an extended return is *not* an "alias" for the
object being created, even for a limited type, and (2) although
limited types aren't supposed to be copied, this is true only in an
Ada semantic sense, and implementations are allowed to do any block-
copies they wish as long as they get the Ada semantics right.

                                 -- Adam

Re: Extended return question

[Dmitry A. Kazakov]

On Thu, 10 Jul 2008 08:19:41 -0700 (PDT), Adam Beneschan wrote:

> The upshot of this AI is, I think, that (1) the object
> being worked on for an extended return is *not* an "alias" for the
> object being created, even for a limited type, and (2) although
> limited types aren't supposed to be copied, this is true only in an
> Ada semantic sense, and implementations are allowed to do any block-
> copies they wish as long as they get the Ada semantics right.

Right, and the position 1 is inconsistent with the notion of limited type.
A "backdoor" 2 does not save it as the following example illustrates:

with Ada.Finalization;
with Ada.Text_IO;  use Ada.Text_IO;

procedure Test_Return is
   package Test is
      type T is
         new Ada.Finalization.Limited_Controlled with null record;
      overriding
         procedure Finalize (X : in out T);
      overriding
         procedure Initialize (X : in out T);
      function Create return T;
   end Test;
   
   package body Test is
      procedure Finalize (X : in out T) is
      begin
         Put_Line ("Finalized");
      end Finalize;
      procedure Initialize (X : in out T) is
      begin
         Put_Line ("Initialized");
      end Initialize;
      function Create return T is
      begin
         return X : T do
            raise Constraint_Error;
         end return;
      exception
         when Constraint_Error =>
            return X : T;
      end Create;
   end Test;

   use Test;
   X : T := Create;
begin
   null;
end Test_Return;

The output should be:

Initialized
Finalized
Initialized
Finalized

This is a case when *a* limited object is initialized and finalized twice,
which is semantically inconsistent.

OK, Initialize is not a constructor. But we could rewrite the above so that
Create would call itself multiple times over the "same" X before it would
finally "return" X!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Extended return question

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 10 Jul 2008 08:19:41 -0700 (PDT), Adam Beneschan wrote:
>
>> The upshot of this AI is, I think, that (1) the object
>> being worked on for an extended return is *not* an "alias" for the
>> object being created, even for a limited type, and (2) although
>> limited types aren't supposed to be copied, this is true only in an
>> Ada semantic sense, and implementations are allowed to do any block-
>> copies they wish as long as they get the Ada semantics right.
>
> Right, and the position 1 is inconsistent with the notion of limited type.
> A "backdoor" 2 does not save it as the following example illustrates:

I don't see any problem here.  The "notion of limited type" is "do not
copy".  In the example below, X is created, then destroyed, then another
X is created, and that becomes the result.  No copying.

> with Ada.Finalization;
> with Ada.Text_IO;  use Ada.Text_IO;
>
> procedure Test_Return is
>    package Test is
>       type T is
>          new Ada.Finalization.Limited_Controlled with null record;
>       overriding
>          procedure Finalize (X : in out T);
>       overriding
>          procedure Initialize (X : in out T);
>       function Create return T;
>    end Test;
>    
>    package body Test is
>       procedure Finalize (X : in out T) is
>       begin
>          Put_Line ("Finalized");
>       end Finalize;
>       procedure Initialize (X : in out T) is
>       begin
>          Put_Line ("Initialized");
>       end Initialize;
>       function Create return T is
>       begin
>          return X : T do
>             raise Constraint_Error;
>          end return;
>       exception
>          when Constraint_Error =>
>             return X : T;
>       end Create;
>    end Test;
>
>    use Test;
>    X : T := Create;
> begin
>    null;
> end Test_Return;
>
> The output should be:
>
> Initialized
> Finalized
> Initialized
> Finalized

Right.

> This is a case when *a* limited object is initialized and finalized twice,
> which is semantically inconsistent.

No, X is initialized and finalized, then a different X is initialized,
which becomes a still-different X, which is then finalized.

I don't see how that's "semantically inconsistent".

> OK, Initialize is not a constructor. But we could rewrite the above so that
> Create would call itself multiple times over the "same" X before it would
> finally "return" X!

- Bob

Re: Extended return question

[Dmitry A. Kazakov]

On Thu, 10 Jul 2008 20:43:09 -0400, Robert A Duff wrote:

> I don't see any problem here.  The "notion of limited type" is "do not
> copy".  In the example below, X is created, then destroyed, then another
> X is created, and that becomes the result.  No copying.

No, we cannot say that, because

A) X is not created until the constructing function returns. There is just
no X until that point. The question is *what* was created and destroyed? It
is improperly typed, at least.

B) On the other hand, if we considered X being created, destroyed and
created again, then the name X would resolve into two different objects in
the same context. This would either violate the identity semantics of X or
be semantically equivalent to an assignment of X.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Extended return question

[christoph.grein]

On 11 Jul., 09:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 10 Jul 2008 20:43:09 -0400, Robert A Duff wrote:
> > I don't see any problem here.  The "notion of limited type" is "do not
> > copy".  In the example below, X is created, then destroyed, then another
> > X is created, and that becomes the result.  No copying.
>
> No, we cannot say that, because
>
> A) X is not created until the constructing function returns. There is just
> no X until that point. The question is *what* was created and destroyed? It
> is improperly typed, at least.
>
> B) On the other hand, if we considered X being created, destroyed and
> created again, then the name X would resolve into two different objects in
> the same context. This would either violate the identity semantics of X or
> be semantically equivalent to an assignment of X.

I view it this way:

There is a certain storage region where something (first X) is created
and then distroyed.

There is again a certain storage region (may be the same, may be not)
where the second X is created. Only when the function returns becomes
this storage region known a the final limited object. No copying.

Re: Extended return question

[Dmitry A. Kazakov]

On Fri, 11 Jul 2008 02:06:17 -0700 (PDT), christoph.grein@eurocopter.com
wrote:

> On 11 Jul., 09:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 10 Jul 2008 20:43:09 -0400, Robert A Duff wrote:
>>> I don't see any problem here. �The "notion of limited type" is "do not
>>> copy". �In the example below, X is created, then destroyed, then another
>>> X is created, and that becomes the result. �No copying.
>>
>> No, we cannot say that, because
>>
>> A) X is not created until the constructing function returns. There is just
>> no X until that point. The question is *what* was created and destroyed? It
>> is improperly typed, at least.
>>
>> B) On the other hand, if we considered X being created, destroyed and
>> created again, then the name X would resolve into two different objects in
>> the same context. This would either violate the identity semantics of X or
>> be semantically equivalent to an assignment of X.
> 
> I view it this way:
> 
> There is a certain storage region where something (first X) is created
> and then distroyed.

But there cannot be first and second X, when X is limited! The object X is
*one* object. It must be created strictly once. It can change its state,
but it cannot disappear and reappear, that is not state change. So the
question stands: what was created and then destroyed? The following
question is: what is the type of that thing (which the type cannot be T.)

> There is again a certain storage region (may be the same, may be not)
> where the second X is created. Only when the function returns becomes
> this storage region known a the final limited object. No copying.

I don't think that limitmess is only about copying. It is rather about
keeping the identity of the object. The latter implies the former but not
necessarily reverse.

When I see a sequence Initialize - Finalize - Initialize attributed to the
same object, that is a sequence of assignment to me. The storage region
used is in my view irrelevant here. I agree with Adam that "limitness" may
allow moving bit patterns in the memory. It is OK, because the identity of
a limited object is not necessarily the memory address, though an
implementation may choose memory location for this purpose. So the issue
boils down to the meaning of "in-place."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Extended return question

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> On Jul 10, 7:37 am, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> Dale Stanbrough <MrNoS...@bigpoop.net.au> writes:
>> > The purpose of an extended return is to create the values in-situ
>> > without copying.
>>
>> No, that's not correct.  Limited function results are built in place,
>> nonlimited ones are not.  It's got nothing to do with which sort of
>> return statement you use -- limited builds in place even when you
>> say "return <expression>;".
>
> Actually, the situation with limited types isn't totally clear,
> either.

It's pretty clear to me.  ;-)

I agree the RM wording is not crystal clear -- hence the AI you mention
below.

>...However, for limited types, there's no way Dale could test
> this using the sort of example he used above, since he used his
> Extended_Return_Function on the right-hand side of an assignment,
> which wouldn't be allowed for a function returning a limited type.

Right.

But if we're being really precise, we need to use standard Ada terms.
"Assignment" is (confusingly) not a shorthand for "assignment
statement", in Ada.  You mean "assignment statement" above.

And when I said "limited" in my previous message, I really meant
"immutably limited", as Randy pointed out.  A limited private type whose
full type is "range 1..10", or a generic formal limited private type
whose actual is "range 1..10" doesn't count.  We're talking about types
that are really limited, "deep down".

>...If
> he tried to use the function call as an initializer for some object X,
> and the function raised an exception and left, there's no way X could
> be examined to determine whether some of the components of X were set.

Right.  That's one of the cases where the compiler can safely use
build-in-place for nonlimited types.

> But in AI05-67, I did come up with an example where an extended return
> with a limited function result was left with a GOTO, and the function
> then did another extended return, and I had a question about whether
> the components set up by the first extended return (if not overwritten
> by the second) were required to show up in the result.  Your answer,
> Bob, was "no",...

Right.  For inherently limited types, the return object, and the object
being initialized are one and the same object.  But the object
being initialized doesn't exist until the return statement completes
successfully -- if it is left via goto, exit, or (more likely) an
exception, then a different return object may eventually be created,
which will _be_ the object being initialized.

>... and I think that if AI05-67 is adopted, the answer will
> still be "no", because this AI says that the function result object
> does not "morph" into the created object until the return is
> completed.  The upshot of this AI is, I think, that (1) the object
> being worked on for an extended return is *not* an "alias" for the
                         ^^^^^^^^^^^^^^^
Again, the return syntax is irrelevant!

> object being created, even for a limited type,...

For an immutably limited type, the return object is an alias for object
that _will_ be created, if we get that far.

>.. and (2) although
> limited types aren't supposed to be copied, this is true only in an
> Ada semantic sense, and implementations are allowed to do any block-
> copies they wish as long as they get the Ada semantics right.

Yes, of course -- if an implemention has garbage collection, it can copy
anything it likes, including tasks, so long as it patches up all the
pointers properly, so the copying is semantically invisible.

E.g. if you have a record with a Self component that points to the
record, it had better still point to itself after returning from the
function.  The easiest way to implement that is to make sure that the
address of the return object is the same as the address of the
newly-created object at the call site (which is exactly what GNAT
does).

- Bob