Return by reference

Return by reference

[Brian Rogoff]

I understand why, for a return-by-reference type T, the function 

function Some_Func( ... ) return T is 
    Local_Var : T
begin
    ...
    return Local_Var;
end Some_Func;

causes Program_Error to be raised at run time, but I'm a bit 
perplexed as to why there is a problem for 

function Some_Func( Param : T; ... ) return T is
begin
    ...
    return Param;
end Some_Func;

Could someone explain why the latter case is problematic? 

-- Brian

Re: Return by reference

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> I understand why, for a return-by-reference type T, the function 
> 
> function Some_Func( ... ) return T is 
>     Local_Var : T
> begin
>     ...
>     return Local_Var;
> end Some_Func;
> 
> causes Program_Error to be raised at run time, but I'm a bit 
> perplexed as to why there is a problem for 
> 
> function Some_Func( Param : T; ... ) return T is
> begin
>     ...
>     return Param;
> end Some_Func;
> 
> Could someone explain why the latter case is problematic? 

We wanted the checks to be done at compile time.

So you may well ask, why does this one raise Program_Error?  It's
because in a shared-body generic, we don't know enough to do the check
at compile time.  However, most compilers use macro-expanded generics,
so they can check the above at compile time, and just generate code to
raise P_E if the check fails, and, one hopes, give a message at compile
time.

If the above were allowed, then somebody could do this:

    function Mumble return T is
        Local: T;
    begin
        return Some_Func(Local); -- Wrong.
    end Mumble;

To detect that error would require keeping too much dope around at run
time.

On the other hand, if you want true run-time checks, you can use access
parameters.  Some extra dope is normally passed with an access
parameter.

- Bob

Re: Return by reference

[Brian Rogoff]

On Tue, 2 Nov 1999, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > I understand why, for a return-by-reference type T, the function 
> > 
> > function Some_Func( ... ) return T is 
> >     Local_Var : T
> > begin
> >     ...
> >     return Local_Var;
> > end Some_Func;
> > 
> > causes Program_Error to be raised at run time, but I'm a bit 
> > perplexed as to why there is a problem for 
> > 
> > function Some_Func( Param : T; ... ) return T is
> > begin
> >     ...
> >     return Param;
> > end Some_Func;
> > 
> > Could someone explain why the latter case is problematic? 
> 
> We wanted the checks to be done at compile time.
> 
> So you may well ask, why does this one raise Program_Error?  It's
> because in a shared-body generic, we don't know enough to do the check
> at compile time.  However, most compilers use macro-expanded generics,
> so they can check the above at compile time, and just generate code to
> raise P_E if the check fails, and, one hopes, give a message at compile
> time.

Thanks, that's what I wanted to know. I should have guessed that the evil 
shared generics were responsible. Any place I can find a further
discussion of this?

> If the above were allowed, then somebody could do this:
> 
>     function Mumble return T is
>         Local: T;
>     begin
>         return Some_Func(Local); -- Wrong.
>     end Mumble;
> 
> To detect that error would require keeping too much dope around at run
> time.

I thought of this case but I expected that it could be caught at compile 
time. 

In any case, in response to Lutz Donnerhack, who wonders why I might want
to do such a thing, consider the problem of trying to write a printf like
like formatting library in Ada. One interface (proposed in the programming
FAQ at adahome) goes something like this 

    type Format_Type is limited private;

    function  Format(S : in String) return Format_Type;
    procedure Printf    (Fmt : in Format_Type);
    function "&" (Fmt : in Format_Type; S : in String)    return
Format_Type;
    function "&" (Fmt : in Format_Type; I : in Integer)   return
Format_Type;

etc.

I was going to use the "Rosen trick" to modify data in the Fmt each time 
"&" is called. Unfortunately, that requires making the full view of
Format_Type limited and you run into the problem I described. 

Is there a cleaner way to implement that interface? 

-- Brian

Re: Return by reference

[Lutz Donnerhacke]

* Brian Rogoff wrote:
>In any case, in response to Lutz Donnerhack, who wonders why I might want

'Donnerhacke' (= 'thunder & hoe') please. Today exaktly seven guys with this
surname live on this earth. 'Donnerhack' is much more common (something like
'Smith' ;-)).

>to do such a thing, consider the problem of trying to write a printf like
>like formatting library in Ada. One interface (proposed in the programming
>FAQ at adahome) goes something like this
>
>    type Format_Type is limited private;
>
>    function  Format(S : in String) return Format_Type;
>    procedure Printf    (Fmt : in Format_Type);
>    function "&" (Fmt : in Format_Type; S : in String)    return Format_Type;
>    function "&" (Fmt : in Format_Type; I : in Integer)   return Format_Type;
>
>etc.
>
>I was going to use the "Rosen trick" to modify data in the Fmt each time 
>"&" is called. Unfortunately, that requires making the full view of
>Format_Type limited and you run into the problem I described. 
>
>Is there a cleaner way to implement that interface? 

To my first and ignorant view it should work fine with an unlimited type.
I implemented it for myself to check this view. Your will get it by E-Mail.

Re: Return by reference

[Brian Rogoff]

On 3 Nov 1999, Lutz Donnerhacke wrote:
> * Brian Rogoff wrote:
> >In any case, in response to Lutz Donnerhack, who wonders why I might want
> 
> 'Donnerhacke' (= 'thunder & hoe') please. Today exaktly seven guys with this
> surname live on this earth. 'Donnerhack' is much more common (something like
> 'Smith' ;-)).

My apologies.

> >to do such a thing, consider the problem of trying to write a printf like
> >like formatting library in Ada. One interface (proposed in the programming
> >FAQ at adahome) goes something like this
> >
> >    type Format_Type is limited private;
> >
> >    function  Format(S : in String) return Format_Type;
> >    procedure Printf    (Fmt : in Format_Type);
> >    function "&" (Fmt : in Format_Type; S : in String)    return Format_Type;
> >    function "&" (Fmt : in Format_Type; I : in Integer)   return Format_Type;
> >
> >etc.
> >
> >I was going to use the "Rosen trick" to modify data in the Fmt each time 
> >"&" is called. Unfortunately, that requires making the full view of
> >Format_Type limited and you run into the problem I described. 
> >
> >Is there a cleaner way to implement that interface? 
> 
> To my first and ignorant view it should work fine with an unlimited type.
> I implemented it for myself to check this view. Your will get it by E-Mail.

Thanks for the code, but I already know how to do this with a type whose 
public view is limited and its private view, not limited. I was wondering
if I can do this entirely with minimal potential copying.

-- Brian

Re: Return by reference

[Lutz Donnerhacke]

* Brian Rogoff wrote:
>Thanks for the code, but I already know how to do this with a type whose 
>public view is limited and its private view, not limited. I was wondering
>if I can do this entirely with minimal potential copying.

Of course it is possible. The idea is to deal with a pointer to a dynamic
array only. The Format function allocates and the To_String function
releases the memory.

Please drop me any notes on the source or include it to other projects.
ftp://ftp.iks-jena.de/pub/mitarb/lutz/ada/formatted_print/

Re: Return by reference

[Brian Rogoff]

On 4 Nov 1999, Lutz Donnerhacke wrote:
> * Brian Rogoff wrote:
> >Thanks for the code, but I already know how to do this with a type whose 
> >public view is limited and its private view, not limited. I was wondering
> >if I can do this entirely with minimal potential copying.
> 
> Of course it is possible. The idea is to deal with a pointer to a dynamic
> array only. The Format function allocates and the To_String function
> releases the memory.

But then you have to heap allocate. That seems rather heavy. I think
Matthew Heaney's suggestion is the most promising for reducing copying,
but it appears too "naughty" to me. I'll just live with the copying.

--Brian

Re: Return by reference

[Lutz Donnerhacke]

* Brian Rogoff wrote:
>> Of course it is possible. The idea is to deal with a pointer to a dynamic
>> array only. The Format function allocates and the To_String function
>> releases the memory.
>
>But then you have to heap allocate. That seems rather heavy. I think
>Matthew Heaney's suggestion is the most promising for reducing copying,
>but it appears too "naughty" to me. I'll just live with the copying.

So lets add three alternatives to the pool of reusable packages and deal
with the next problem.

Re: Return by reference

[Robert A Duff]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> 'Donnerhacke' (= 'thunder & hoe') please. Today exaktly seven guys with this
> surname live on this earth. 'Donnerhack' is much more common (something like
> 'Smith' ;-)).

So 'Donnerhacke' is something like 'Psmith' (P.G. Wodehouse), then (the
P is silent).  :-) :-)

- Bob

Re: Return by reference

[Matthew Heaney]

In article <Pine.BSF.4.10.9911021905050.1386-100000@shell5.ba.best.com> 
, Brian Rogoff <bpr@shell5.ba.best.com>  wrote:

> I was going to use the "Rosen trick" to modify data in the Fmt each time
> "&" is called. Unfortunately, that requires making the full view of
> Format_Type limited and you run into the problem I described.
>
> Is there a cleaner way to implement that interface?

1) Privately implement the type as tagged, to make it a by-reference
type.

2) This allows you to invoke RM95 13.3 (16), to take the address of
parameter.

3) Pass the address to an instantiation of
System.Address_To_Access_Conversions, which gives you a variable view of
the parameter.


Note that there has been a subtle error running throughout this thread.
There is nothing wrong with returning a "by-reference" type as a
function return type; the error is returning a *limited* type.


--
Science is, foremost, a method of interrogating reality: proposing
hypotheses that seem true and then testing them -- trying, almost
perversely, to negate them, elevating only the handful that survive to
the status of a theory. Creationism is a doctrine, whose adherents are
interested only in seeking out data that support it.

George Johnson, NY Times, 15 Aug 1999

Re: Return by reference

[Brian Rogoff]

On Wed, 3 Nov 1999, Matthew Heaney wrote:
> In article <Pine.BSF.4.10.9911021905050.1386-100000@shell5.ba.best.com> 
> , Brian Rogoff <bpr@shell5.ba.best.com>  wrote:
> 
> > I was going to use the "Rosen trick" to modify data in the Fmt each time
> > "&" is called. Unfortunately, that requires making the full view of
> > Format_Type limited and you run into the problem I described.
> >
> > Is there a cleaner way to implement that interface?
> 
> 1) Privately implement the type as tagged, to make it a by-reference
> type.
> 
> 2) This allows you to invoke RM95 13.3 (16), to take the address of
> parameter.
> 
> 3) Pass the address to an instantiation of
> System.Address_To_Access_Conversions, which gives you a variable view of
> the parameter.

Interesting idea. I'll try it, but it still does more copying than I'd
have liked, since it isn't a return-by-reference type. You'll end up
copying on the way out. 

> Note that there has been a subtle error running throughout this thread.
> There is nothing wrong with returning a "by-reference" type as a
> function return type; the error is returning a *limited* type.

No, I was quite clear in my post. The issue is about "return-by-reference" 
types (see 6.5.11) and why returning an argument of such a type is the
same as returning a local variable of such a type (it is the same, in that 
it raises Program_Error). You can certainly return a (limited)
return-by-reference type from a function, it just has to be global to that 
function. 

-- Brian

> 
> 
> --
> Science is, foremost, a method of interrogating reality: proposing
> hypotheses that seem true and then testing them -- trying, almost
> perversely, to negate them, elevating only the handful that survive to
> the status of a theory. Creationism is a doctrine, whose adherents are
> interested only in seeking out data that support it.
> 
> George Johnson, NY Times, 15 Aug 1999
> 
> 

Re: Return by reference

[Matthew Heaney]

In article <38203d4a_1@news1.prserv.net> , "Matthew Heaney" 
<matthew_heaney@acm.org> wrote:

> In article <Pine.BSF.4.10.9911021905050.1386-100000@shell5.ba.best.com>
> , Brian Rogoff <bpr@shell5.ba.best.com>  wrote:
>
>> I was going to use the "Rosen trick" to modify data in the Fmt each time
>> "&" is called. Unfortunately, that requires making the full view of
>> Format_Type limited and you run into the problem I described.
>>
>> Is there a cleaner way to implement that interface?
>
> 1) Privately implement the type as tagged, to make it a by-reference
> type.

I should have said, "implement the type as *nonlimited* tagged..."



--
The political forces that try to eliminate evolution from science
classrooms impose a narrow, sectarian doctrine on our educational
systems. This imposition represents an affront not only to the
constitutional separation of church and state but also to the moral and
intellectual integrity embedded in that constitution.

<http://www.nabt.org/evolutionks.html>

Re: Return by reference

[Lutz Donnerhacke]

* Brian Rogoff wrote:
>I understand why, for a return-by-reference type T, the function 
[...]
>causes Program_Error to be raised at run time, but I'm a bit 
>perplexed as to why there is a problem for 
>
>function Some_Func( Param : T; ... ) return T is
>begin
>    ...
>    return Param;
>end Some_Func;

May you explain a bit more why you are returning a 'constant' 'in' parameter?

OTOH it might be a problem in your calling function.

  type S is tagged new T with record ... end record;
  aS: S := Some_Func(aT); -- may cause the error.
  

Return by reference

[Jere]

Implicit dereference has gone a long way in providing
a sort of return by reference capability in Ada.  It is
still fairly clunky to setup and use though and requires
a lot of definitions that aren't always easy to read
and discern their purpose without lots of extra comments.
Additionally, it still exposes access types in places where
a designer may not want to at all.  Yes, it does so more
safely than before, but I know at least for me, I like to
avoid exposing access types as much as possible.

I was wondering if Ada could take a step with it further
and provide a syntax for return by reference.  The building
blocks for implementation (Implicit_Dereference based
holders) are already in the language now.  All that I was
curious about was a way to remove the hard to read, clunky
setup and a way to remove direct access to the underlying
access type.

I don't know if I have any good ideas for the syntax honestly.
The one idea that I came up with probably has holes:

function Stuff(Object : Some_Aliased_Type) return aliased Component_Type;

Basically this would expand out to (in the compiler implementation):

type Component_Type_Holder(Raw : not null access Component_Type)
   is limited null record;

function Stuff(Object : Some_Aliased_Type) return Component_Type_Holder;

as for what could be returned:
1.  Any aliased or tagged package level object
2.  Any function parameter object (or it's components) provided
    that the parameter is either explicitly aliased or tagged

Local variables to the function would not be allowed as sources

so

function Stuff(Object : Some_Aliased_Type) return aliased Component_Type is
begin
   return Object.Component;
end Stuff;

would be ok but:

function Stuff(Object : Some_Aliased_Type) return aliased Component_Type is
   Temp : Some_Aliased_Type;
begin
   return Temp.Component;
end Stuff;

would not be ok. 

Calling a return by reference within a function that returns
by reference would not be allowed directly, but require an unchecked_access
so that they can easily be identified and provide the programmer with
opportunity to really consider the source of his/her return value.

Again, I'm not necessarily proposing this is the right syntax, I just
wanted something to get people thinking.  Any syntax/implementation that
can improve this functionality is welcome.  I'm more interested in
hiding the access discriminant and cutting back on all the overly clunky
(though currently necessary) declarations that reduce readability.

Other thoughts are completely welcome.

I know it isn't as easy as I laid out, but I fell like the current
implicit_dereference method now gives compiler writers at least
a starting tool to take it a step further and enhance readability
and safety (less access types exposed).

Re: Return by reference

[Dmitry A. Kazakov]

On 2017-12-17 15:38, Jere wrote:
> Implicit dereference has gone a long way in providing
> a sort of return by reference capability in Ada.

I don't think this is a right way anyway. A great number of application 
interested in in-place semantics would rather like to implement 
referential semantics of their own, possibly unrelated to any access 
type at all. Consider as example a DB interface:

    Table.Select (Column) := Value;

There is simply to object to get access to.

Using iterators and holders is one method, which is as you have noticed 
quite clunky, requires helper types obscuring everything, and still 
requiring access types.

I would prefer language-assisted delegation to a getter/setter pair:

    function Getter (To : Container) return Element;
    procedure Setter (To : in out Container; Item : Element);

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

Re: Return by reference

[Mehdi Saada]

Not like they were omnicient, but people in ARG certainly had at least some reasons to provide a "clunky" mechanism ?

Re: Return by reference

[Dmitry A. Kazakov]

On 18/12/2017 01:51, Mehdi Saada wrote:
> Not like they were omnicient, but people in ARG certainly had at
> least  some reasons to provide a "clunky" mechanism ?

Sure. Typical arguments are:

1. It is too complicated

2. It could be incompatible with a feature nobody ever used and nobody 
certain is there

3. "Aber, meine Herren, das ist keine Physik".

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

Re: Return by reference

[Mehdi Saada]

What ? Too complicated to provide something simplier ? Or rather to change to rest of the language accordingly ?

Re: Return by reference

[Dmitry A. Kazakov]

On 18/12/2017 11:47, Mehdi Saada wrote:

> What ? Too complicated to provide something simplier ? Or rather to
> change to rest of the language accordingly ?

Simpler for the programmer frequently means difficult for the compiler 
designer. After all Ada is far less complicated than ANSI C, but not so 
simple to write a compiler...

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

Re: Return by reference

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:4d13b387-b813-449f-93b1-850822560578@googlegroups.com...
> Not like they were omnicient, but people in ARG certainly had at least
> some reasons to provide a "clunky" mechanism ?

Surely.  Every mechanism that we tried ended up simply regressing the 
problem -- there still was a non-user-defined dereference involved. And that 
had to be controlled, lest one be able to make long-lived copies of the 
dereferenced access type. It turned out that access discriminants have the 
right lifetime to do the control, and making the type with an access 
discriminant controlled gives the necessary hook. So it was much less change 
than a new kind of function return that really didn't solve the problem 
anyway.

Dmitry's delegation scheme would have worked, I guess, but such things can't 
replace assignment because they don't make sense for discriminant-dependent 
components. So you'd lose the assignment syntax, or have a horrible wart in 
the way it works.

                                     Randy.

Re: Return by reference

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:a94cf715-a4a4-42bb-8800-9bb6a8baf9ac@googlegroups.com...
...
> I was wondering if Ada could take a step with it further
> and provide a syntax for return by reference.

No. It doesn't semantically make sense as a stand-alone concept. We tried a 
whole bunch of ideas on that line before giving up and adopting the implicit 
dereference mechanism.

                           Randy.

Re: Return by reference

[Jere]

On Monday, December 18, 2017 at 5:33:20 PM UTC-5, Randy Brukardt wrote:
> "Jere"  wrote in message 
> ...
> > I was wondering if Ada could take a step with it further
> > and provide a syntax for return by reference.
> 
> No. It doesn't semantically make sense as a stand-alone concept. We tried a 
> whole bunch of ideas on that line before giving up and adopting the implicit 
> dereference mechanism.
> 
>                            Randy.

And I think it was a good choice.  I was just seeing if there was a way that
the language could further increase the safety of the mechanism by fully
hiding the access type and making it more integrated into the language. It's
a fairly young feature of the language, so I was just seeing if that was
plausible.