Ada2012 : Expression functions and extended return statements

Ada2012 : Expression functions and extended return statements

[Martin]

Am I correct in thinking these 2 parts of the language can't be
'mixed'?...

There doesn't seem to be anything that allows anything like, e.g.

package Foo is
   type T (<>) is tagged private;
   function Create return T is
      (Result : T do Result.I := 1);
private
   type T is tagged record
      I : Integer;
   end record;
end Foo;

Also, on the topic of extended return statements...

What's the rational for having to explicitly repeat the return type?
Seems rather redundant to my eyes. I wouldn't have minded:

function Bar return Some_Type is
begin
   return Result : <> do
      -- something to initialise 'Result'
   end return;
end Bar;

or even

function Bar return Some_Type is
begin
   return Result do
      -- something to initialise 'Result'
   end return;
end Bar;

In this case, 'Result' can't be anything other than of type
'Some_Type' can it?

-- Martin

Re: Ada2012 : Expression functions and extended return statements

[stefan-lucks]

On Fri, 6 Jan 2012, Martin wrote:

> Also, on the topic of extended return statements...
> 
> What's the rational for having to explicitly repeat the return type?
> Seems rather redundant to my eyes. I wouldn't have minded:

I guess, this is because the object actually returned may not necessarily 
be of exactly the same type of subtype as the declared return type -- like 
the ordinary return statement. See the following examples:

   function Characters(I: Integer; Filler: Character := '_') return String is
   begin
      return Result: String(1..I) := (others => Filler) do
        return;
      end return;
   end Characters; 

   type T is tagged record I: Integer; end record;
   type S is new T with record J: Natural; end record;

   function Fun(N, M: Natural) return T'Class is
   begin
      return Result: S do
        Result.I := M;
        Result.J := N;
      end return; 
   end Fun;


-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Ada2012 : Expression functions and extended return statements

[Martin]

On Jan 6, 9:45 am, stefan-lu...@see-the.signature wrote:
> On Fri, 6 Jan 2012, Martin wrote:
> > Also, on the topic of extended return statements...
>
> > What's the rational for having to explicitly repeat the return type?
> > Seems rather redundant to my eyes. I wouldn't have minded:
>
> I guess, this is because the object actually returned may not necessarily
> be of exactly the same type of subtype as the declared return type -- like
> the ordinary return statement. See the following examples:
>
>    function Characters(I: Integer; Filler: Character := '_') return String is
>    begin
>       return Result: String(1..I) := (others => Filler) do
>         return;
          ^^^^^^^

I think you mean
        null;
or
        return Result: String(1..I) := (others => Filler);


>       end return;
>    end Characters;
>
>    type T is tagged record I: Integer; end record;
>    type S is new T with record J: Natural; end record;
>
>    function Fun(N, M: Natural) return T'Class is
>    begin
>       return Result: S do
>         Result.I := M;
>         Result.J := N;
>       end return;
>    end Fun;
>
> --
> ---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
>     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
> ------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------


Ah ok, yes, that makes sense...thanks. Never had need of
this...yet! :-)

I still think it would be nice to have a short-hand e.g. 'return
Result : <> do'. If anything it would then draw the eye to the more
interesting case when the 2 are different.

-- Martin

Re: Ada2012 : Expression functions and extended return statements

[Peter C. Chapin]

On 2012-01-06 05:02, Martin wrote:

> I still think it would be nice to have a short-hand e.g. 'return
> Result :<>  do'. If anything it would then draw the eye to the more
> interesting case when the 2 are different.

You need to repeat the type for ordinary returns as well.

function F return Integer is
   Result : Integer;  -- Duplication of return type here.
begin
   Result := 1;
   return Result;
end F;

To be consistent it seems like you'd need to be able to use '<>' 
throughout the body of the function.

function F return Integer is
   Result : <>;  -- Shorthand for function's return type.
begin
   Result := 1;
   return Result;
end F;

Considering Ada's tendency to require one to repeat information in 
earlier declarations, this seems a bit unAda-like to me. Also this would 
allow '<>' to show up in a lot of strange looking places such as type 
conversions and type qualifications.

Peter

Re: Ada2012 : Expression functions and extended return statements

[Martin]

On Jan 6, 11:23 am, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
> On 2012-01-06 05:02, Martin wrote:
>
> > I still think it would be nice to have a short-hand e.g. 'return
> > Result :<>  do'. If anything it would then draw the eye to the more
> > interesting case when the 2 are different.
>
> You need to repeat the type for ordinary returns as well.
>
> function F return Integer is
>    Result : Integer;  -- Duplication of return type here.
> begin
>    Result := 1;
>    return Result;
> end F;
>
> To be consistent it seems like you'd need to be able to use '<>'
> throughout the body of the function.
>
> function F return Integer is
>    Result : <>;  -- Shorthand for function's return type.
> begin
>    Result := 1;
>    return Result;
> end F;
>
> Considering Ada's tendency to require one to repeat information in
> earlier declarations, this seems a bit unAda-like to me. Also this would
> allow '<>' to show up in a lot of strange looking places such as type
> conversions and type qualifications.
>
> Peter

The difference is that the declaration of 'Return' in the extended
return is that the compiler 'knows' that this is the declaration of
something that's going to be returned - it can't know that in the
ordinary return case. Well, at least not when it first parses the
declaration, not without just assuming it is...and that might be
messy...

It would certainly be a departure from current Ada - adding a little
bit of "Type Inferencing" to the language. But I'm not adverse to
that...so long as the inferencing is safe. I like SML/NJ :-)

It's not that big a leap, at least not in my head, as "<>" is already
used to mean "default" (i.e. infer what I mean from what's visible)
and this would simply be "use the default return type, i.e. the one
that's in the the function declaration".

-- Martin

Re: Ada2012 : Expression functions and extended return statements

[Dmitry A. Kazakov]

On Fri, 6 Jan 2012 03:37:27 -0800 (PST), Martin wrote:

> On Jan 6, 11:23�am, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
>> On 2012-01-06 05:02, Martin wrote:
>>
>>> I still think it would be nice to have a short-hand e.g. 'return
>>> Result :<> �do'. If anything it would then draw the eye to the more
>>> interesting case when the 2 are different.
>>
>> You need to repeat the type for ordinary returns as well.
>>
>> function F return Integer is
>> � �Result : Integer; �-- Duplication of return type here.
>> begin
>> � �Result := 1;
>> � �return Result;
>> end F;
>>
>> To be consistent it seems like you'd need to be able to use '<>'
>> throughout the body of the function.
>>
>> function F return Integer is
>> � �Result : <>; �-- Shorthand for function's return type.
>> begin
>> � �Result := 1;
>> � �return Result;
>> end F;
>>
>> Considering Ada's tendency to require one to repeat information in
>> earlier declarations, this seems a bit unAda-like to me. Also this would
>> allow '<>' to show up in a lot of strange looking places such as type
>> conversions and type qualifications.
>>
> The difference is that the declaration of 'Return' in the extended
> return is that the compiler 'knows' that this is the declaration of
> something that's going to be returned - it can't know that in the
> ordinary return case.

This is not a declaration, because the result is not an object.

Note that your argument applies to other parameters of a subprogram:

   procedure Foo (X : Integer);  -- Declares X

   procedure Foo (X : Integer) is -- Reiterates what is already known
      ...
   end Foo;

> It would certainly be a departure from current Ada - adding a little
> bit of "Type Inferencing" to the language. But I'm not adverse to
> that...so long as the inferencing is safe. I like SML/NJ :-)

Maybe. There are lots of cases where repetition is boring and error prone.
E.g.:

   if X in T'Class then
      declare
         XX : T'Class renames T'Class (X);

or

   if X /= null then
      declare
         XX : T renames X.all;

or

   X : Subarray renames Array_Thing;  -- Legal, but broken

As for return, the second best (the first one is to ditch return statement
altogether) would be:

   X : return -- Loop label syntax
      ...
   end X;

BTW, Ada could have the result explicitly named like other parameters are.
E.g.

   function F return X : Integer := 1 is
   begin
      if Something then
        X := 2;
      end if;
   end F; -- No explicit return needed, obviously

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

Re: Ada2012 : Expression functions and extended return statements

[Martin Dowie]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> On Fri, 6 Jan 2012 03:37:27 -0800 (PST), Martin wrote:
> 
>> On Jan 6, 11:23 am, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
>>> On 2012-01-06 05:02, Martin wrote:
>>> 
>>>> I still think it would be nice to have a short-hand e.g. 'return
>>>> Result :<>  do'. If anything it would then draw the eye to the more
>>>> interesting case when the 2 are different.
>>> 
>>> You need to repeat the type for ordinary returns as well.
>>> 
>>> function F return Integer is
>>>    Result : Integer;  -- Duplication of return type here.
>>> begin
>>>    Result := 1;
>>>    return Result;
>>> end F;
>>> 
>>> To be consistent it seems like you'd need to be able to use '<>'
>>> throughout the body of the function.
>>> 
>>> function F return Integer is
>>>    Result : <>;  -- Shorthand for function's return type.
>>> begin
>>>    Result := 1;
>>>    return Result;
>>> end F;
>>> 
>>> Considering Ada's tendency to require one to repeat information in
>>> earlier declarations, this seems a bit unAda-like to me. Also this would
>>> allow '<>' to show up in a lot of strange looking places such as type
>>> conversions and type qualifications.
>>> 
>> The difference is that the declaration of 'Return' in the extended
>> return is that the compiler 'knows' that this is the declaration of
>> something that's going to be returned - it can't know that in the
>> ordinary return case.
> 
> This is not a declaration, because the result is not an object.

2012 RM 3.1 6/3 says it is a declaration (but I should have written
'Result' not 'Return').


> 
> Note that your argument applies to other parameters of a subprogram:
> 
>    procedure Foo (X : Integer);  -- Declares X
> 
>    procedure Foo (X : Integer) is -- Reiterates what is already known
>       ...
>    end Foo;

Yes but here you may not have a procedure declaration and even if you did,
they need not be close or even in the same. The chances of a extended
return statement not being close to the 'return ... Is' seems remote.

>> It would certainly be a departure from current Ada - adding a little
>> bit of "Type Inferencing" to the language. But I'm not adverse to
>> that...so long as the inferencing is safe. I like SML/NJ :-)
> 
> Maybe. There are lots of cases where repetition is boring and error prone.
> E.g.:
> 
>    if X in T'Class then
>       declare
>          XX : T'Class renames T'Class (X);
> 
> or
> 
>    if X /= null then
>       declare
>          XX : T renames X.all;
> 
> or
> 
>    X : Subarray renames Array_Thing;  -- Legal, but broken
> 
> As for return, the second best (the first one is to ditch return statement
> altogether) would be:
> 
>    X : return -- Loop label syntax
>       ...
>    end X;
> 
> BTW, Ada could have the result explicitly named like other parameters are.
> E.g.
> 
>    function F return X : Integer := 1 is
>    begin
>       if Something then
>         X := 2;
>       end if;
>    end F; -- No explicit return needed, obviously

A bit like Pascal(?), didn't use the function's name at the point of
return?...so for function 'Foo' you wrote something like,

Foo := 100;

?

The evolution of Ada has always resulted in adding things that aren't
"Ada-like" when compared to the previous revision. There was a paper around
at one time with a proposal to add implicit generic instantiation to the
language...

-- Martin



-- 
-- Sent from my iPad

Re: Ada2012 : Expression functions and extended return statements

[Martin]

On Jan 6, 2:45 pm, Martin Dowie <mar...@re.mo.ve.thedowies.com> wrote:
> they need not be close or even in the same. The chances of a extended
                      ...or even in the same file. The...

Re: Ada2012 : Expression functions and extended return statements

[Robert A Duff]

Martin Dowie <martin@re.mo.ve.thedowies.com> writes:

> 2012 RM 3.1 6/3 says it is a declaration (but I should have written
> 'Result' not 'Return').

Right, and it declares an object.

> A bit like Pascal(?), didn't use the function's name at the point of
> return?...so for function 'Foo' you wrote something like,
>
> Foo := 100;
>
> ?

Yes, that's the Pascal method.  The problem with it is that
if you say something like "Foo := Foo + 1;" it does something
very wrong, especially if Foo has no parameters.

But the general principle that the result should have a
name is a good one.

- Bob

Re: Ada2012 : Expression functions and extended return statements

[Martin Dowie]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> Martin Dowie <martin@re.mo.ve.thedowies.com> writes:
> 
>> 2012 RM 3.1 6/3 says it is a declaration (but I should have written
>> 'Result' not 'Return').
> 
> Right, and it declares an object.
> 
>> A bit like Pascal(?), didn't use the function's name at the point of
>> return?...so for function 'Foo' you wrote something like,
>> 
>> Foo := 100;
>> 
>> ?
> 
> Yes, that's the Pascal method.  The problem with it is that
> if you say something like "Foo := Foo + 1;" it does something
> very wrong, especially if Foo has no parameters.
> 
> But the general principle that the result should have a
> name is a good one.
> 
> - Bob

Hmmm, I think the function name is the best clue...and thats all you have
with an expression function now. Also, I tend to only use a variable called
 'Result' these days, which works for both ordinary and extended return
statements but does say what the result represents - so thats kind of a
special case, all other variables are named to give, at least, a clue as to
what the value represents!

-- Martin
-- 
-- Sent from my iPad

Re: Ada2012 : Expression functions and extended return statements

[David Thompson]

On Fri, 06 Jan 2012 11:40:16 -0500, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

> Martin Dowie <martin@re.mo.ve.thedowies.com> writes:

> > A bit like Pascal(?), didn't use the function's name at the point of
> > return?...so for function 'Foo' you wrote something like,
> >
> > Foo := 100;
> >
> > ?
> 
> Yes, that's the Pascal method.  The problem with it is that
> if you say something like "Foo := Foo + 1;" it does something
> very wrong, especially if Foo has no parameters.
> 
> But the general principle that the result should have a
> name is a good one.
> 
Classic FORTRAN used the FUNCTION name as the result variable, even on
RHS because it didn't support recursion. F90 added options to specify
a different name for the result variable, and for recursive.

Re: Ada2012 : Expression functions and extended return statements

[Dmitry A. Kazakov]

On Fri, 06 Jan 2012 08:45:22 -0600, Martin Dowie wrote:

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

>> This is not a declaration, because the result is not an object.
> 
> 2012 RM 3.1 6/3 says it is a declaration (but I should have written
> 'Result' not 'Return').

Surely it says so, but it is not a declaration of the result object.

When the result is copy-out, it is another object which value could become
the value of the result object proper.

Even for limited types it is still not necessarily the result object. In
fact it is undecidable to figure out if it is:

   return X : Limited_T do
      if Halt (p) then
         raise I_Want_It_Otherwise;
      end if;
      ...
   end return;
exception
   when I_Want_It_Otherwise =>
      return Y : Limited_T do
          ...
      end return;

Who is the result object, X or Y?

The problem is that it is inherently inconsistent to have result objects
declared within the function body. What Ada actually does is no different
from a local variable, because there is no other way to return anything
from a subprogram. Why bother introducing awful syntax, which does not mean
what it is supposed to do?

> The evolution of Ada has always resulted in adding things that aren't
> "Ada-like" when compared to the previous revision.

Alas. Return statement is certainly not.

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

Re: Ada2012 : Expression functions and extended return statements

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1292hrynqxgnm$.12shf160d3gpi.dlg@40tude.net...
> On Fri, 06 Jan 2012 08:45:22 -0600, Martin Dowie wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>
>>> This is not a declaration, because the result is not an object.
>>
>> 2012 RM 3.1 6/3 says it is a declaration (but I should have written
>> 'Result' not 'Return').
>
> Surely it says so, but it is not a declaration of the result object.

Yes it is, because the result object (and, as you point out, there can be 
more than one) is formally a separate object from whatever the result is 
assigned into. (This becomes obvious when the result is renamed or directly 
indexed, because in those cases there is no assigned object, but there still 
has to be a result object). This is true even for limited types; in that 
case, the result object "morphs" into the assigned object, but still they 
formally are separate objects. For other objects, the compiler can also use 
build-in-place and avoid materializing the result object, but in all cases 
it exists formally.

And the result object has to be an object, because it doesn't make sense to 
assign into parts of something that isn't an object.

I think your model of what is an object is different than Ada's (which dates 
back to the original Ada 80). Which is fine, but you confuse the issue when 
your terminology deviates from the accepted Ada meaning.

                                       Randy.

Re: Ada2012 : Expression functions and extended return statements

[Dmitry A. Kazakov]

On Fri, 6 Jan 2012 19:47:21 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1292hrynqxgnm$.12shf160d3gpi.dlg@40tude.net...
>> On Fri, 06 Jan 2012 08:45:22 -0600, Martin Dowie wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>
>>>> This is not a declaration, because the result is not an object.
>>>
>>> 2012 RM 3.1 6/3 says it is a declaration (but I should have written
>>> 'Result' not 'Return').
>>
>> Surely it says so, but it is not a declaration of the result object.
> 
> Yes it is, because the result object (and, as you point out, there can be 
> more than one) is formally a separate object from whatever the result is 
> assigned into. (This becomes obvious when the result is renamed or directly 
> indexed, because in those cases there is no assigned object, but there still 
> has to be a result object). This is true even for limited types; in that 
> case, the result object "morphs" into the assigned object, but still they 
> formally are separate objects. For other objects, the compiler can also use 
> build-in-place and avoid materializing the result object, but in all cases 
> it exists formally.
> 
> And the result object has to be an object, because it doesn't make sense to 
> assign into parts of something that isn't an object.
> 
> I think your model of what is an object is different than Ada's (which dates 
> back to the original Ada 80).

I never care much about exact definitions given in RM in discussions about
Ada as *a* language. They can illustrate the point, but can never serve as
an argument, because to be able to discuss a language or any system you
have to leave it first. If somebody claimed that "jump" would be better
than "goto," then answering that RM 5.8(2) specifies it as "goto" would be
just silly.

> Which is fine, but you confuse the issue when 
> your terminology deviates from the accepted Ada meaning.

But it does its job perfectly well. I mean the job of describing what is
going on, and, note, without resorting to "morphing objects" and other
phantasms.

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

Re: Ada2012 : Expression functions and extended return statements

[Adam Beneschan]

On Jan 6, 5:13 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > The difference is that the declaration of [Result] in the extended
> > return is that the compiler 'knows' that this is the declaration of
> > something that's going to be returned - it can't know that in the
> > ordinary return case.
>
> This is not a declaration, because the result is not an object.

Not sure what you mean here, but 3.1(6) says it is indeed a
declaration, and 3.3(10) and 3.3(20.1) say it's an object.

                         -- Adam

Re: Ada2012 : Expression functions and extended return statements

[Adam Beneschan]

On Jan 6, 2:02 am, Martin <mar...@thedowies.com> wrote:
>
> >    function Characters(I: Integer; Filler: Character := '_') return String is
> >    begin
> >       return Result: String(1..I) := (others => Filler) do
> >         return;
>
>           ^^^^^^^
>
> I think you mean
>         null;
> or
>         return Result: String(1..I) := (others => Filler);

Stefan's code is legal Ada--there's nothing wrong with it.  Of course,
adding a "do" part would be redundant if it doesn't do anything except
return immediately.

                       -- Adam

Re: Ada2012 : Expression functions and extended return statements

[stefan-lucks]

On Fri, 6 Jan 2012, Martin wrote:

> On Jan 6, 9:45�am, stefan-lu...@see-the.signature wrote:
> > On Fri, 6 Jan 2012, Martin wrote:
> > > Also, on the topic of extended return statements...
> >
> > > What's the rational for having to explicitly repeat the return type?
> > > Seems rather redundant to my eyes. I wouldn't have minded:
> >
> > I guess, this is because the object actually returned may not necessarily
> > be of exactly the same type of subtype as the declared return type -- like
> > the ordinary return statement. See the following examples:
> >
> > � �function Characters(I: Integer; Filler: Character := '_') return String is
> > � �begin
> > � � � return Result: String(1..I) := (others => Filler) do
> > � � � � return;
>           ^^^^^^^
> 
> I think you mean
>         null;
> or
>         return Result: String(1..I) := (others => Filler);

The following compiles fine (with gnat 2011), and the output is xxxyyx, as 
to be expected:

<lang Ada>

with Ada.Text_IO;

procedure Y is

   function Characters(I: Integer; Filler: Character := '_') return String is
   begin
      return Result: String(1..I) := (others => Filler) do
        return;
      end return;
   end Characters;

begin
   Ada.Text_IO.Put(Characters(3, 'x'));
   Ada.Text_IO.Put(Characters(2, 'y'));
   Ada.Text_IO.Put(Characters(1, 'x'));
   Ada.Text_IO.Put(Characters(0, 'y'));
end Y;

</lang>

> 
> > � � � end return;
> > � �end Characters;
> >
> > � �type T is tagged record I: Integer; end record;
> > � �type S is new T with record J: Natural; end record;
> >
> > � �function Fun(N, M: Natural) return T'Class is
> > � �begin
> > � � � return Result: S do
> > � � � � Result.I := M;
> > � � � � Result.J := N;
> > � � � end return;
> > � �end Fun;
> >
> > --
> > ---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany �----
> > � � <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
> > ------ �I �love �the �taste �of �Cryptanalysis �in �the �morning! �------
> 
> 
> Ah ok, yes, that makes sense...thanks. Never had need of
> this...yet! :-)
> 
> I still think it would be nice to have a short-hand e.g. 'return
> Result : <> do'. If anything it would then draw the eye to the more
> interesting case when the 2 are different.
> 
> -- Martin
> 

-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Ada2012 : Expression functions and extended return statements

[Dmitry A. Kazakov]

On Sat, 7 Jan 2012 15:54:44 +0100, stefan-lucks@see-the.signature wrote:

>    function Characters(I: Integer; Filler: Character := '_') return String is
>    begin
>       return Result: String(1..I) := (others => Filler) do
>         return;
>       end return;
>    end Characters;

OT: a return statement inside another return statement is funny.

   return X : Boolean := True do -- Illegal, I hope
      return False;
   end return;

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

Re: Ada2012 : Expression functions and extended return statements

[stefan-lucks]

On Sat, 7 Jan 2012, Dmitry A. Kazakov wrote:

> On Sat, 7 Jan 2012 15:54:44 +0100, stefan-lucks@see-the.signature wrote:
> 
> >    function Characters(I: Integer; Filler: Character := '_') return String is
> >    begin
> >       return Result: String(1..I) := (others => Filler) do
> >         return;
> >       end return;
> >    end Characters;
> 
> OT: a return statement inside another return statement is funny.
> 
>    return X : Boolean := True do -- Illegal, I hope
>       return False;
>    end return;

This is a syntax error:

  extended_return_statement cannot return value; use ""return;""

-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Ada2012 : Expression functions and extended return statements

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1bjpifgqn93x.yp3mckcm2qds$.dlg@40tude.net...
> On Sat, 7 Jan 2012 15:54:44 +0100, stefan-lucks@see-the.signature wrote:
>
>>    function Characters(I: Integer; Filler: Character := '_') return 
>> String is
>>    begin
>>       return Result: String(1..I) := (others => Filler) do
>>         return;
>>       end return;
>>    end Characters;
>
> OT: a return statement inside another return statement is funny.

It's funny, but allowed, for the same reason that it is useful in any 
decent-sized chunk of code -- sometimes you need to exit in the middle. 
Hopefully it won't happen very often.

>   return X : Boolean := True do -- Illegal, I hope
>      return False;
>   end return;

The "return False" is illegal, because the outer return has already 
specified the result. You can only use a return without an expression inside 
of an extended-return.

                                     Randy.

Re: Ada2012 : Expression functions and extended return statements

[J-P. Rosen]

Le 06/01/2012 10:45, stefan-lucks@see-the.signature a �crit :
> On Fri, 6 Jan 2012, Martin wrote:
> 
>> Also, on the topic of extended return statements...
>>
>> What's the rational for having to explicitly repeat the return type?
>> Seems rather redundant to my eyes. I wouldn't have minded:
> 
> I guess, this is because the object actually returned may not necessarily 
> be of exactly the same type of subtype as the declared return type -- like 
> the ordinary return statement. 
That's a good reason, but there is also a general principle that
whenever an object is declared, it's type appears in the same
declaration. This means that when you read the code, you know the type
of the object, without needing to look elsewhere - for example, renaming
could have used the type of the renamed object, but then the reader
could be forced to follow a chain of renaming declarations to discover
the type of the object.

In Ada, we favour the reader over the writer, don't we?

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Ada2012 : Expression functions and extended return statements

[Martin]

On Jan 6, 3:11 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
[snip]
> In Ada, we favour the reader over the writer, don't we?

Not necessarily, with the advent of expression functions!! ;-)

-- Martin

Re: Ada2012 : Expression functions and extended return statements

[Randy Brukardt]

"Martin" <martin@thedowies.com> wrote in message 
news:a40448ab-4508-4861-99ae-1a7b63d59f69@ck5g2000vbb.googlegroups.com...
On Jan 6, 3:11 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
>[snip]
>> In Ada, we favour the reader over the writer, don't we?
>
>Not necessarily, with the advent of expression functions!! ;-)

Huh? An expression function is just a shorthand for writing a simple 
function; it argubly easier to read because it has less noise. "begin" "end" 
"return" don't add much information here, and you still can add the 
whitespace if you think it helps readability.

                                         Randy.

Re: Ada2012 : Expression functions and extended return statements

[Martin]

On Jan 7, 1:50 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Martin" <mar...@thedowies.com> wrote in message
>
> news:a40448ab-4508-4861-99ae-1a7b63d59f69@ck5g2000vbb.googlegroups.com...
> On Jan 6, 3:11 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
>
> >[snip]
> >> In Ada, we favour the reader over the writer, don't we?
>
> >Not necessarily, with the advent of expression functions!! ;-)
>
> Huh? An expression function is just a shorthand for writing a simple
> function; it argubly easier to read because it has less noise. "begin" "end"
> "return" don't add much information here, and you still can add the
> whitespace if you think it helps readability.
>
>                                          Randy.

http://groups.google.com/group/comp.lang.ada/browse_frm/thread/4bb12335caa3231a/91a870f32263ab04?lnk=gst&q=enjoying#91a870f32263ab04

:-O

-- Martin

Re: Ada2012 : Expression functions and extended return statements

[Simon Wright]

Martin <martin@thedowies.com> writes:

> On Jan 7, 1:50 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> "Martin" <mar...@thedowies.com> wrote in message
>>
>> news:a40448ab-4508-4861-99ae-1a7b63d59f69@ck5g2000vbb.googlegroups.com...
>> On Jan 6, 3:11 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
>>
>> >[snip]
>> >> In Ada, we favour the reader over the writer, don't we?
>>
>> >Not necessarily, with the advent of expression functions!! ;-)
>>
>> Huh? An expression function is just a shorthand for writing a simple
>> function; it argubly easier to read because it has less noise. "begin" "end"
>> "return" don't add much information here, and you still can add the
>> whitespace if you think it helps readability.
>>
>>                                          Randy.
>
> http://groups.google.com/group/comp.lang.ada/browse_frm/thread/4bb12335caa3231a/91a870f32263ab04?lnk=gst&q=enjoying#91a870f32263ab04

It's always been possible to write Ada that won't get past a code review!

Re: Ada2012 : Expression functions and extended return statements

[Martin]

On Jan 7, 12:22 pm, Simon Wright <si...@pushface.org> wrote:
> Martin <mar...@thedowies.com> writes:
> > On Jan 7, 1:50 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> >> "Martin" <mar...@thedowies.com> wrote in message
>
> >>news:a40448ab-4508-4861-99ae-1a7b63d59f69@ck5g2000vbb.googlegroups.com...
> >> On Jan 6, 3:11 pm, "J-P. Rosen" <ro...@adalog.fr> wrote:
>
> >> >[snip]
> >> >> In Ada, we favour the reader over the writer, don't we?
>
> >> >Not necessarily, with the advent of expression functions!! ;-)
>
> >> Huh? An expression function is just a shorthand for writing a simple
> >> function; it argubly easier to read because it has less noise. "begin" "end"
> >> "return" don't add much information here, and you still can add the
> >> whitespace if you think it helps readability.
>
> >>                                          Randy.
>
> >http://groups.google.com/group/comp.lang.ada/browse_frm/thread/4bb123...
>
> It's always been possible to write Ada that won't get past a code review!

True, but I've never seen anything like this before...

...I did see one chap trying to write COBOL in Ada! All variables in a
"Data Division" - no matter what the required scope was. Testament to
Ada was that his code work! Hideously inefficient, but working!!

-- Martin

Re: Ada2012 : Expression functions and extended return statements

[Randy Brukardt]

"Martin" <martin@thedowies.com> wrote in message 
news:50ec6d9a-5062-477f-826f-239fd2712a09@f11g2000yql.googlegroups.com...
On Jan 7, 1:50 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> >> In Ada, we favour the reader over the writer, don't we?
>>
>> >Not necessarily, with the advent of expression functions!! ;-)
>>
>> Huh? An expression function is just a shorthand for writing a simple
>> function; it argubly easier to read because it has less noise. "begin" 
>> "end"
>> "return" don't add much information here, and you still can add the
>> whitespace if you think it helps readability.
>
>http://groups.google.com/group/comp.lang.ada/browse_frm/thread/4bb12335caa3231a/91a870f32263ab04?>lnk=gst&q=enjoying#91a870f32263ab04
>
>:-O

The expression functions have nothing to do with the readability issues 
here, it is intentionally confusing use of case and if expressions (that is, 
conditional expressions). These aren't the same thing, you know.

I'd have had more sympathy if you had commented on conditional expressions; 
I do think you have to use them carefully in order to avoid a mess. (But 
avoiding them can easily lead to a bigger mess, such as the idioms for 
writing static expressions that effectively contain conditional 
expressions.) But that has nothing to do with expression functions.

                                Randy.

Re: Ada2012 : Expression functions and extended return statements

[Martin Dowie]

"Randy Brukardt" <randy@rrsoftware.com> wrote:
> "Martin" <martin@thedowies.com> wrote in message 
> news:50ec6d9a-5062-477f-826f-239fd2712a09@f11g2000yql.googlegroups.com...
> On Jan 7, 1:50 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>>>> In Ada, we favour the reader over the writer, don't we?
>>> 
>>>> Not necessarily, with the advent of expression functions!! ;-)
>>> 
>>> Huh? An expression function is just a shorthand for writing a simple
>>> function; it argubly easier to read because it has less noise. "begin" 
>>> "end"
>>> "return" don't add much information here, and you still can add the
>>> whitespace if you think it helps readability.
>> 
>> http://groups.google.com/group/comp.lang.ada/browse_frm/thread/4bb12335caa3231a/91a870f32263ab04?>lnk=gst&q=enjoying#91a870f32263ab04
>> 
>> :-O
> 
> The expression functions have nothing to do with the readability issues 
> here, it is intentionally confusing use of case and if expressions (that is, 
> conditional expressions). These aren't the same thing, you know.
> 
> I'd have had more sympathy if you had commented on conditional expressions; 
> I do think you have to use them carefully in order to avoid a mess. (But 
> avoiding them can easily lead to a bigger mess, such as the idioms for 
> writing static expressions that effectively contain conditional 
> expressions.) But that has nothing to do with expression functions.

Agreed. I only had a vague recall of Georg's OP (had to google for it
again). The whole thing horrified me so much I quickly closed the browser
tab!

But, to my eyes at least, mixing of conditional expressions inside a
function expression is particularly ugly.

-- 
-- Sent from my iPad

Re: Ada2012 : Expression functions and extended return statements

[Yannick Duchêne (Hibou57)]

Le Mon, 09 Jan 2012 07:21:34 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> I'd have had more sympathy if you had commented on conditional  
> expressions;
> I do think you have to use them carefully in order to avoid a mess. (But
> avoiding them can easily lead to a bigger mess, such as the idioms for
> writing static expressions that effectively contain conditional
> expressions.)

Like multiplying by 1 or 0 :D (I use to do this … a bit)


-- 
“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: Ada2012 : Expression functions and extended return statements

[Adam Beneschan]

On Jan 6, 12:45 am, Martin <mar...@thedowies.com> wrote:

> Also, on the topic of extended return statements...
>
> What's the rational for having to explicitly repeat the return type?
> Seems rather redundant to my eyes. I wouldn't have minded:
>
> function Bar return Some_Type is
> begin
>    return Result : <> do
>       -- something to initialise 'Result'
>    end return;
> end Bar;
>
> or even
>
> function Bar return Some_Type is
> begin
>    return Result do
>       -- something to initialise 'Result'
>    end return;
> end Bar;
>
> In this case, 'Result' can't be anything other than of type
> 'Some_Type' can it?

Yes, it can.  If Some_Type is a class-wide type, Result's type must be
a specific type.  If Some_Type is, say, an unconstrained array type,
Result's type must be a constrained subtype.

                             -- Adam

Re: Ada2012 : Expression functions and extended return statements

[Adam Beneschan]

On Jan 6, 8:33 am, Adam Beneschan <a...@irvine.com> wrote:
> On Jan 6, 12:45 am, Martin <mar...@thedowies.com> wrote:
>
>
>
>
>
> > Also, on the topic of extended return statements...
>
> > What's the rational for having to explicitly repeat the return type?
> > Seems rather redundant to my eyes. I wouldn't have minded:
>
> > function Bar return Some_Type is
> > begin
> >    return Result : <> do
> >       -- something to initialise 'Result'
> >    end return;
> > end Bar;
>
> > or even
>
> > function Bar return Some_Type is
> > begin
> >    return Result do
> >       -- something to initialise 'Result'
> >    end return;
> > end Bar;
>
> > In this case, 'Result' can't be anything other than of type
> > 'Some_Type' can it?
>
> Yes, it can.  If Some_Type is a class-wide type, Result's type must be
> a specific type.  If Some_Type is, say, an unconstrained array type,
> Result's type must be a constrained subtype.

Oops, I goofed.  Result's type doesn't *have* to be a specific,
constrained subtype, if there is an initial value (which could be a
function call, say); the specific type and subtype are then determined
from the value.  If there is no initial value, however, then Result's
type does have to be constrained.

                        -- Adam

Re: Ada2012 : Expression functions and extended return statements

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> On Jan 6, 8:33�am, Adam Beneschan <a...@irvine.com> wrote:
>> On Jan 6, 12:45�am, Martin <mar...@thedowies.com> wrote:
>>
>> > Also, on the topic of extended return statements...
>>
>> > What's the rational for having to explicitly repeat the return type?
>> > Seems rather redundant to my eyes. I wouldn't have minded:
>>
>> > function Bar return Some_Type is
>> > begin
>> > � �return Result : <> do
>> > � � � -- something to initialise 'Result'
>> > � �end return;
>> > end Bar;
>>
>> > or even
>>
>> > function Bar return Some_Type is
>> > begin
>> > � �return Result do
>> > � � � -- something to initialise 'Result'
>> > � �end return;
>> > end Bar;
>>
>> > In this case, 'Result' can't be anything other than of type
>> > 'Some_Type' can it?
>>
>> Yes, it can. �If Some_Type is a class-wide type, Result's type must be
>> a specific type. �If Some_Type is, say, an unconstrained array type,
>> Result's type must be a constrained subtype.
>
> Oops, I goofed.  Result's type doesn't *have* to be a specific,
> constrained subtype, if there is an initial value (which could be a
> function call, say); the specific type and subtype are then determined
> from the value.  If there is no initial value, however, then Result's
> type does have to be constrained.

Well, the examples above don't have an initial value, so I took
your "must be constrained" comment to mean "for this example,
because there's no initial value".

Anyway, the rule is the same as for an object_declaration -- if there's
no initial value, the subtype has to be definite.

- Bob

Re: Ada2012 : Expression functions and extended return statements

[Yannick Duchêne (Hibou57)]

Le Fri, 06 Jan 2012 09:45:26 +0100, Martin <martin@thedowies.com> a écrit:

> Am I correct in thinking these 2 parts of the language can't be
> 'mixed'?...
>
> There doesn't seem to be anything that allows anything like, e.g.
>
> package Foo is
>    type T (<>) is tagged private;
>    function Create return T is
>       (Result : T do Result.I := 1);
> private
>    type T is tagged record
>       I : Integer;
>    end record;
> end Foo;

Private stuff in the public part is funny, don't you think ?

> Also, on the topic of extended return statements...
>
> What's the rational for having to explicitly repeat the return type?
> Seems rather redundant to my eyes. I wouldn't have minded:

At least because Ada does not have Type Inference. You have to declare the  
returned entity, just like you would do with a classic return‑by‑copy (*).  
You have to build something in‑place, so have to declare what you build,  
even if it's not tagged and class‑wide.

Sorry, can't see better words to explain.

(*) Example:

    function F return String
    is
       Result : String;
    begin
       Result := "....";
       P (Result); -- in/out Result
       -- Etc.
       return Result;
    end F;


-- 
“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