Question[s] about aliased extended return.

Question[s] about aliased extended return.

[Shark8]

The syntax for the extended return given in the RM [ http://www.ada-auth.org/standards/12rm/html/RM-6-5.html ] allows for the usage of the keyword ALIASED, with the restriction of "if the keyword aliased is present in an extended_return_object_declaration, the type of the extended return object shall be immutably limited."

The 2012 rationale entry regarding the extended return [ http://www.ada-auth.org/standards/12rat/html/Rat12-4-6.html ] says of immutably limited objects:
* it is an explicitly limited record type,
* it is a task type, protected type or synchronized interface,
* it is a non-formal limited private type that is tagged or has an access discriminant with a default expression, [or]
* it is derived from an immutably limited type.

(1) Doesn't this reduce the usefulness of the extended return?

There are a couple of times building the OpenGL binding where I would have liked to do something like:
Function some_vector( [params] ) Return Vector_of_points is
begin
  Return Result : access Vector_of_points( 1..size_from_params ) do
    glFunctionPopulatingVector( glEnum_from_params, Result'access )
  end return;
end some_vector;
in order to populate the vector with the requisite data, but this is not allowed.
(2) Is there a reason this is not allowed? (Thick/thin 'pointer' differences?)

Lastly, the GNAT compiler seems to reject the following, even though the rationale says a "explicitly limited record type" qualifies as immutably limited:
    Type LR is limited record
	Data : Character:= 'X';
    End record;
    
    Function Get_LR Return LR is
    begin
	Return Result : aliased LR do
	    null;
	end return;
    end Get_LR;
(3) Is this a bug, or am I just misreading everything?

Re: Question[s] about aliased extended return.

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:9bbd99bd-f953-434d-b3c8-6e8a6d5c7dfd@googlegroups.com...
>The syntax for the extended return given in the RM
>[ http://www.ada-auth.org/standards/12rm/html/RM-6-5.html ] allows for the 
>usage
> of the keyword ALIASED, with the restriction of "if the keyword aliased is 
> present
>  in an extended_return_object_declaration, the type of the extended return 
> object
>  shall be immutably limited."
>
>The 2012 rationale entry regarding the extended return
> [ http://www.ada-auth.org/standards/12rat/html/Rat12-4-6.html ] says of 
> immutably limited objects:
>* it is an explicitly limited record type,
>* it is a task type, protected type or synchronized interface,
>* it is a non-formal limited private type that is tagged or has an access 
>discriminant with a default expression, [or]
>* it is derived from an immutably limited type.
>
>(1) Doesn't this reduce the usefulness of the extended return?

No. Allowing "aliased" at all was a bug in Ada 2005; we preserved it only 
for compatibility (some GNAT customers used it a lot).

> There are a couple of times building the OpenGL binding where I would have 
> liked to do something like:
> Function some_vector( [params] ) Return Vector_of_points is
> begin
>  Return Result : access Vector_of_points( 1..size_from_params ) do
>    glFunctionPopulatingVector( glEnum_from_params, Result'access )
>  end return;
>end some_vector;
>in order to populate the vector with the requisite data, but this is not 
>allowed.

I presume you meant "aliased" rather than "access" in the return statement 
here.

IMHO, you get what you deserve when you use access parameters rather than 
"in out" parameters. There is no good reason to use an access parameter in a 
routine like Populating_Vector (at least in the Ada part - you might have to 
do all kinds of nasty things in the thin interface).

>(2) Is there a reason this is not allowed? (Thick/thin 'pointer' 
>differences?)

Of course. See the examples in AI05-0053-1. If a return object is a a 
temporary, allowing 'Access to be taken of it causes all kinds problems 
because its lifetime is unusual at best.

> Lastly, the GNAT compiler seems to reject the following, even though the 
> rationale says
> a "explicitly limited record type" qualifies as immutably limited:
>    Type LR is limited record
>      Data : Character:= 'X';
>    End record;
>
>    Function Get_LR Return LR is
>    begin
>        Return Result : aliased LR do
>           null;
>       end return;
>     end Get_LR;
>(3) Is this a bug, or am I just misreading everything?

Looks like a bug to me.

                                   Randy.

Re: Question[s] about aliased extended return.

[Yannick Duchêne (Hibou57)]

Le Fri, 09 Nov 2012 01:43:15 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:

> "Shark8" <onewingedshark@gmail.com> wrote in message
> news:9bbd99bd-f953-434d-b3c8-6e8a6d5c7dfd@googlegroups.com...
>> The syntax for the extended return given in the RM
>> [ http://www.ada-auth.org/standards/12rm/html/RM-6-5.html ] allows for  
>> the
>> usage
>> of the keyword ALIASED, with the restriction of "if the keyword aliased  
>> is
>> present
>>  in an extended_return_object_declaration, the type of the extended  
>> return
>> object
>>  shall be immutably limited."
>>
>> The 2012 rationale entry regarding the extended return
>> [ http://www.ada-auth.org/standards/12rat/html/Rat12-4-6.html ] says of
>> immutably limited objects:
>> * it is an explicitly limited record type,
>> * it is a task type, protected type or synchronized interface,
>> * it is a non-formal limited private type that is tagged or has an  
>> access
>> discriminant with a default expression, [or]
>> * it is derived from an immutably limited type.
>>
>> (1) Doesn't this reduce the usefulness of the extended return?
>
> No. Allowing "aliased" at all was a bug in Ada 2005; we preserved it only
> for compatibility (some GNAT customers used it a lot).

Why not list it in the Obsolescent Features section?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Question[s] about aliased extended return.

[Shark8]

On Thursday, November 8, 2012 5:43:18 PM UTC-7, Randy Brukardt wrote:
> "Shark8" <onewingedshark@gmail.com> wrote in message 
> 
> > There are a couple of times building the OpenGL binding where I would have 
> > liked to do something like:
> > Function some_vector( [params] ) Return Vector_of_points is
> > begin
> >  Return Result : ALIASED Vector_of_points( 1..size_from_params ) do
> >    glFunctionPopulatingVector( glEnum_from_params, Result'access )
> >  end return;
> >end some_vector;
> >in order to populate the vector with the requisite data, but this is not 
> >allowed.
> 
> I presume you meant "aliased" rather than "access" in the return statement 
> here.

Yes.

> 
> IMHO, you get what you deserve when you use access parameters rather than 
> "in out" parameters. There is no good reason to use an access parameter in a 
> routine like Populating_Vector (at least in the Ada part - you might have to 
> do all kinds of nasty things in the thin interface).

Ah that's kinda the point, this is WRT the implementation part [of my OpenGL binding] and therefore the interface between the thin/raw-imports and the more useful/friendly Ada world. (By Vector I mean something like "Array (Positive Range <>) of Float" [or whatever], not the Containers's Vector.)

As it is I have to do something like:
    Function Get_Elements(Item:Texture_Coordinate_Generation) Return Positive is
    begin
	case Item is
	when TEXTURE_GEN_MODE		=> Return 1;
	when OBJECT_PLANE | EYE_PLANE	=> Return 4;
	end case;
    end Get_Elements;

    Function GetTexGen (	coord : Texture_Coordinate_Type;
				pname : Texture_Coordinate_Generation)
				Return Double_Vector_Type is
    begin
	Return Result : Double_Vector_Type(1..Get_Elements( pname )) do
		glGetTexGendv(
			coord  => Convert(coord),
			pname  => Convert(pname),
			params => To_Pointer( Result'Address )
		);
	End Return;
    end GetTexGen;

Where Convert is Unchecked_Conversion to GLEnum, and To_Pointer is Address/access conversion. {Aliased return statements would then allow me to be rid of a whole dependency... oh well.}

> 
> > Lastly, the GNAT compiler seems to reject the following, [..] 
> >(3) Is this a bug, or am I just misreading everything?
> 
> Looks like a bug to me.

Thank you, good to know.

Re: Question[s] about aliased extended return.

[sbelmont700]

On Friday, November 9, 2012 2:42:37 PM UTC-5, Shark8 wrote:
> 
> Ah that's kinda the point, this is WRT the implementation part [of my OpenGL binding] and therefore the interface between the thin/raw-imports and the more useful/friendly Ada world. (By Vector I mean something like "Array (Positive Range <>) of Float" [or whatever], not the Containers's Vector.)
> 


Perhaps something like this:

Function GetTexGen (coord : Texture_Coordinate_Type; 
                    pname : Texture_Coordinate_Generation) 
                    Return Double_Vector_Type is

  procedure Thin (coord  : in Texture_Coordinate_Type; 
                  pname  : in Texture_Coordinate_Generation) 
                  params : aliased in out Double_Vector_Type) is
  begin
    glGetTexGendv(coord  => coord, 
                  pname  => pname, 
                  params => params'Unchecked_Access);
  end Thin;
                  
begin 
  return Result : Double_Vector_Type(1..Get_Elements( pname )) do 
   C_Kludge(coord  => coord, 
            pname  => pname, 
            params => Result);
   End Return; 
end GetTexGen;

In either case, I'm always of the opinion that the 'thin' binding should match the API and just change types (pointers to arrays, etc), and the 'thick' binding should change the structure (procedures to functions, return codes to exceptions, etc).

-ab

Re: Question[s] about aliased extended return.

[Yannick Duchêne (Hibou57)]

Le Fri, 09 Nov 2012 21:53:13 +0100, <sbelmont700@gmail.com> a écrit:

> In either case, I'm always of the opinion that the 'thin' binding should  
> match the API and just change types (pointers to arrays, etc), and the  
> 'thick' binding should change the structure (procedures to functions,  
> return codes to exceptions, etc).
>
> -ab

Just out of curiosity, for a thin binding, would reuse the names used in  
the API or would you change names only in a tick binding? (most of times,  
I feel API names are not nice to read).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Question[s] about aliased extended return.

[sbelmont700]

On Friday, November 9, 2012 4:44:19 PM UTC-5, Hibou57 (Yannick Duchêne) wrote:
> 
> Just out of curiosity, for a thin binding, would reuse the names used in  
> 
> the API or would you change names only in a tick binding? (most of times,  
> 
> I feel API names are not nice to read).
> 

My preference for the thin binding is to reuse the name exactly as it in the C API, import the actual C function with a preceeding 'C_', and then clean up the thick binding as needed (usually it ends up being split apart into child packages, depending on the API), but of course to each their own.

-sb

Re: Question[s] about aliased extended return.

[Shark8]

On Friday, November 9, 2012 2:44:19 PM UTC-7, Hibou57 (Yannick Duchêne) wrote:
> Le Fri, 09 Nov 2012 21:53:13 +0100, <sbelmont700@gmail.com> a écrit:
> 
> Just out of curiosity, for a thin binding, would reuse the names used in  
> the API or would you change names only in a tick binding? (most of times,  
> I feel API names are not nice to read).

As I have it the thin binding is only in the package-bodies, completely unexposed to the client. Right now all the function-names are simply the API-name less the "gl"-prologue and the type-epilog; that is: glColor4i -> Color (letting overloading take care of the differences between 4i and 3f).

After I finish the functions for opengl 4.3 (currently only those from 1.1 are linked) I plan on tweaking the function-names by inserting underscores {I may also use full-words}. Ex: TexEnv -> Texture_Environment.

Re: Question[s] about aliased extended return.

[Shark8]

On Friday, November 9, 2012 3:04:17 PM UTC-7, sbelm...@gmail.com wrote:
> 
> My preference for the thin binding is to reuse the name exactly as it in the C API, import the actual C function with a preceeding 'C_', and then clean up the thick binding as needed (usually it ends up being split apart into child packages, depending on the API), but of course to each their own.

That's how I'm doing it (w/o the 'C_'), with the added constraint that the thin functions are never seen in the public portions of the package.

Re: Question[s] about aliased extended return.

[Jeffrey Carter]

On 11/09/2012 12:42 PM, Shark8 wrote:
>
>      Function GetTexGen (	coord : Texture_Coordinate_Type;
> 				pname : Texture_Coordinate_Generation)
> 				Return Double_Vector_Type is
>      begin
> 	Return Result : Double_Vector_Type(1..Get_Elements( pname )) do
> 		glGetTexGendv(
> 			coord  => Convert(coord),
> 			pname  => Convert(pname),
> 			params => To_Pointer( Result'Address )
> 		);
> 	End Return;
>      end GetTexGen;

The extended return exists for build-in-place results of limited types. There's 
really no reason to use it for other types.

function Gettexgen (Coord : in Texture_Coordiate_Type;
                     Pname : in Texture_Coordinate_Generation)
return Double_Vector_Type is
    Result : aliased Double_Vector_Type (1 .. Get_Elements (Pname) );
begin -- Gettexgen
    Glgettexgendv (Coord  => Convert (Coord),
                   Pname  => Convert (Pname),
                   Params => Result'Unchecked_Access);

    return Result;
end Gettexgen;

-- 
Jeff Carter
"It is the German who is so uncourteous to his verbs."
A Scandal in Bohemia
122

Re: Question[s] about aliased extended return.

[Shark8]

On Friday, November 9, 2012 6:08:46 PM UTC-7, Jeffrey Carter wrote:
> On 11/09/2012 12:42 PM, Shark8 wrote:
> 
> The extended return exists for build-in-place results of limited types. There's 
> really no reason to use it for other types.

Really? I thought it was quite useful for initializing things too:

Type Matrix is Array(Positive Range <>, Positive Range <>) of Float;

Type Identity(Size: Positive) return Matrix is
begin
  Return Result : Matrix(1..size, 1..size):= (others => 0.0) do
    For index in Matrix'Range(1) loop
      Result(Index, Index):= 1.0;
    end loop;
  End return;
end;

But I guess that's fairly related to build-in-place; the only difference being it's not limited.

Re: Question[s] about aliased extended return.

[Yannick Duchêne (Hibou57)]

Le Sat, 10 Nov 2012 02:52:43 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:

> On Friday, November 9, 2012 6:08:46 PM UTC-7, Jeffrey Carter wrote:
>> On 11/09/2012 12:42 PM, Shark8 wrote:
>>
>> The extended return exists for build-in-place results of limited types.  
>> There's
>> really no reason to use it for other types.
>
> Really? I thought it was quite useful for initializing things too:

No (it was discussed some many months ago). It may looks like a  
write‑in‑place statement, but that's only an appearance, nothing specifies  
it should have this behavior. For non‑limited types, the extended return  
statement is exactly the same as a classic return statement, wrapped in a  
local scope (as with a declare/begin/end block) with a locally declared  
variable. Nothing special with this construct when not applied to a  
limited type.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Question[s] about aliased extended return.

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:5dd387bf-f15e-4800-8c92-ceb87c956581@googlegroups.com...
>As I have it the thin binding is only in the package-bodies, completely 
>unexposed to the client.

I've tended to put them in private packages (or the private part), mainly so 
each API only needs to be defined once. By putting them in the private part 
or in private packages, child units can use them, but clients still don't 
have access. Of course, if you're CERTAIN that you'll NEVER need to use the 
same API somewhere else, the body is probably better. (But who's certain of 
anything?? :-)

                              Randy.

Re: Question[s] about aliased extended return.

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wnhlszemule2fv@cardamome...
...
>> No. Allowing "aliased" at all was a bug in Ada 2005; we preserved it only
>> for compatibility (some GNAT customers used it a lot).
>
>Why not list it in the Obsolescent Features section?

Obviously, if customers are using it enough to make this an issue, it's 
useful in some cases. And there is no alternative if you have to have a 
pointer to match some idiot API, so it's hard to call it obsolescent.

We believe that it can make sense to use for any object that requires 
build-in-place, which is where the "immutably limited" rule comes from, but 
it doesn't make sense if a temporary is involved. But that's all 
after-the-fact thinking; no one considered the implications when it 
originally put into the syntax and there doesn't appear to have been any 
original reason to allow it other than consistency with normal object 
declarations. (But whoever came up with that left out "constant", so they 
didn't do that very well, either.) Since the semantics don't make sense in 
general, and there was no identified need, it shouldn't have been there in 
the first place. The situation is different now, as the OP's example shows; 
since it was there, people figured out ways to use it.

                                                       Randy.

Re: Question[s] about aliased extended return.

[Bill Findlay]

On 10/11/2012 01:52, in article
3f8ba99f-015f-4567-8d31-6c711beb58c4@googlegroups.com, "Shark8"
<onewingedshark@gmail.com> wrote:

> On Friday, November 9, 2012 6:08:46 PM UTC-7, Jeffrey Carter wrote:
>> On 11/09/2012 12:42 PM, Shark8 wrote:
>> 
>> The extended return exists for build-in-place results of limited types.
>> There's 
>> really no reason to use it for other types.
> 
> Really? I thought it was quite useful for initializing things too:
> 
> Type Matrix is Array(Positive Range <>, Positive Range <>) of Float;
> 
> Type Identity(Size: Positive) return Matrix is
> begin
>   Return Result : Matrix(1..size, 1..size):= (others => 0.0) do
>     For index in Matrix'Range(1) loop
>       Result(Index, Index):= 1.0;
>     end loop;
>   End return;
> end;
> 
> But I guess that's fairly related to build-in-place; the only difference being
> it's not limited.

I have not used it for a limited type yet; most of my use cases have been
like your example.  It is also nice for finalization after picking up the
value to be returned, e.g.:

   function pop
   return KDF9.word is
      pragma Assert(the_nest_depth > 0 or the_CPU_state = Director_state);
   begin
      return result : constant KDF9.word := the_nest(the_nest_depth - 1) do
         the_nest(the_nest_depth - 1) := 0;
         the_nest_depth := the_nest_depth - 1;
      end return;
   end pop;

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Question[s] about aliased extended return.

[Shark8]

On Saturday, November 10, 2012 12:27:20 AM UTC-7, Randy Brukardt wrote:
> "Shark8" <onewingedshark@gmail.com> wrote in message 
> 
> news:5dd387bf-f15e-4800-8c92-ceb87c956581@googlegroups.com...
> 
> >As I have it the thin binding is only in the package-bodies, completely 
> >unexposed to the client.
> 
> I've tended to put them in private packages (or the private part), mainly so 
> each API only needs to be defined once. By putting them in the private part 
> or in private packages, child units can use them, but clients still don't 
> have access. Of course, if you're CERTAIN that you'll NEVER need to use the 
> same API somewhere else, the body is probably better. (But who's certain of 
> anything?? :-)

Good points.
In the OpenGL binding there's only one function that it's looking like might be useful in a parent's private part (glGetInteger) which is needed for getting the numbers of "objects" and therefore might make a use in parameters for a generic package that set the types up:

Generic
  Max_Textures : Integer := glGetInteger( [constant for 'textures'] );
Package Types is
  SubType Textures is Enum Range Texture_Base..Texture_Base+Enum(Max_Textures);
End Types;

{Top of my head, no syntax-check/compile}