* Question[s] about aliased extended return.
@ 2012-11-02 15:55 Shark8
2012-11-09 0:43 ` Randy Brukardt
0 siblings, 1 reply; 16+ messages in thread
From: Shark8 @ 2012-11-02 15:55 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-02 15:55 Question[s] about aliased extended return Shark8
@ 2012-11-09 0:43 ` Randy Brukardt
2012-11-09 3:40 ` Yannick Duchêne (Hibou57)
2012-11-09 19:42 ` Shark8
0 siblings, 2 replies; 16+ messages in thread
From: Randy Brukardt @ 2012-11-09 0:43 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 0:43 ` Randy Brukardt
@ 2012-11-09 3:40 ` Yannick Duchêne (Hibou57)
2012-11-10 7:34 ` Randy Brukardt
2012-11-09 19:42 ` Shark8
1 sibling, 1 reply; 16+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2012-11-09 3:40 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 3:40 ` Yannick Duchêne (Hibou57)
@ 2012-11-10 7:34 ` Randy Brukardt
0 siblings, 0 replies; 16+ messages in thread
From: Randy Brukardt @ 2012-11-10 7:34 UTC (permalink / raw)
[-- 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 0:43 ` Randy Brukardt
2012-11-09 3:40 ` Yannick Duchêne (Hibou57)
@ 2012-11-09 19:42 ` Shark8
2012-11-09 20:53 ` sbelmont700
2012-11-10 1:08 ` Jeffrey Carter
1 sibling, 2 replies; 16+ messages in thread
From: Shark8 @ 2012-11-09 19:42 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 19:42 ` Shark8
@ 2012-11-09 20:53 ` sbelmont700
2012-11-09 21:44 ` Yannick Duchêne (Hibou57)
2012-11-10 1:08 ` Jeffrey Carter
1 sibling, 1 reply; 16+ messages in thread
From: sbelmont700 @ 2012-11-09 20:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 20:53 ` sbelmont700
@ 2012-11-09 21:44 ` Yannick Duchêne (Hibou57)
2012-11-09 22:04 ` sbelmont700
2012-11-09 22:54 ` Shark8
0 siblings, 2 replies; 16+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2012-11-09 21:44 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 21:44 ` Yannick Duchêne (Hibou57)
@ 2012-11-09 22:04 ` sbelmont700
2012-11-09 22:56 ` Shark8
2012-11-09 22:54 ` Shark8
1 sibling, 1 reply; 16+ messages in thread
From: sbelmont700 @ 2012-11-09 22:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 22:04 ` sbelmont700
@ 2012-11-09 22:56 ` Shark8
0 siblings, 0 replies; 16+ messages in thread
From: Shark8 @ 2012-11-09 22:56 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 21:44 ` Yannick Duchêne (Hibou57)
2012-11-09 22:04 ` sbelmont700
@ 2012-11-09 22:54 ` Shark8
2012-11-10 7:27 ` Randy Brukardt
1 sibling, 1 reply; 16+ messages in thread
From: Shark8 @ 2012-11-09 22:54 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 22:54 ` Shark8
@ 2012-11-10 7:27 ` Randy Brukardt
2012-11-10 16:08 ` Shark8
0 siblings, 1 reply; 16+ messages in thread
From: Randy Brukardt @ 2012-11-10 7:27 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-10 7:27 ` Randy Brukardt
@ 2012-11-10 16:08 ` Shark8
0 siblings, 0 replies; 16+ messages in thread
From: Shark8 @ 2012-11-10 16:08 UTC (permalink / raw)
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}
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-09 19:42 ` Shark8
2012-11-09 20:53 ` sbelmont700
@ 2012-11-10 1:08 ` Jeffrey Carter
2012-11-10 1:52 ` Shark8
1 sibling, 1 reply; 16+ messages in thread
From: Jeffrey Carter @ 2012-11-10 1:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-10 1:08 ` Jeffrey Carter
@ 2012-11-10 1:52 ` Shark8
2012-11-10 2:17 ` Yannick Duchêne (Hibou57)
2012-11-10 10:59 ` Bill Findlay
0 siblings, 2 replies; 16+ messages in thread
From: Shark8 @ 2012-11-10 1:52 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-10 1:52 ` Shark8
@ 2012-11-10 2:17 ` Yannick Duchêne (Hibou57)
2012-11-10 10:59 ` Bill Findlay
1 sibling, 0 replies; 16+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2012-11-10 2:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question[s] about aliased extended return.
2012-11-10 1:52 ` Shark8
2012-11-10 2:17 ` Yannick Duchêne (Hibou57)
@ 2012-11-10 10:59 ` Bill Findlay
1 sibling, 0 replies; 16+ messages in thread
From: Bill Findlay @ 2012-11-10 10:59 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-11-16 9:33 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-02 15:55 Question[s] about aliased extended return Shark8
2012-11-09 0:43 ` Randy Brukardt
2012-11-09 3:40 ` Yannick Duchêne (Hibou57)
2012-11-10 7:34 ` Randy Brukardt
2012-11-09 19:42 ` Shark8
2012-11-09 20:53 ` sbelmont700
2012-11-09 21:44 ` Yannick Duchêne (Hibou57)
2012-11-09 22:04 ` sbelmont700
2012-11-09 22:56 ` Shark8
2012-11-09 22:54 ` Shark8
2012-11-10 7:27 ` Randy Brukardt
2012-11-10 16:08 ` Shark8
2012-11-10 1:08 ` Jeffrey Carter
2012-11-10 1:52 ` Shark8
2012-11-10 2:17 ` Yannick Duchêne (Hibou57)
2012-11-10 10:59 ` Bill Findlay
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox