* Ada2012 : Expression functions and extended return statements @ 2012-01-06 8:45 Martin 2012-01-06 9:45 ` stefan-lucks ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Martin @ 2012-01-06 8:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 8:45 Ada2012 : Expression functions and extended return statements Martin @ 2012-01-06 9:45 ` stefan-lucks 2012-01-06 10:02 ` Martin 2012-01-06 15:11 ` J-P. Rosen 2012-01-06 16:33 ` Adam Beneschan 2012-01-31 23:20 ` Yannick Duchêne (Hibou57) 2 siblings, 2 replies; 33+ messages in thread From: stefan-lucks @ 2012-01-06 9:45 UTC (permalink / raw) 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! ------ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 9:45 ` stefan-lucks @ 2012-01-06 10:02 ` Martin 2012-01-06 11:23 ` Peter C. Chapin ` (2 more replies) 2012-01-06 15:11 ` J-P. Rosen 1 sibling, 3 replies; 33+ messages in thread From: Martin @ 2012-01-06 10:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 10:02 ` Martin @ 2012-01-06 11:23 ` Peter C. Chapin 2012-01-06 11:37 ` Martin 2012-01-06 16:36 ` Adam Beneschan 2012-01-07 14:54 ` stefan-lucks 2 siblings, 1 reply; 33+ messages in thread From: Peter C. Chapin @ 2012-01-06 11:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 11:23 ` Peter C. Chapin @ 2012-01-06 11:37 ` Martin 2012-01-06 13:13 ` Dmitry A. Kazakov 0 siblings, 1 reply; 33+ messages in thread From: Martin @ 2012-01-06 11:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 11:37 ` Martin @ 2012-01-06 13:13 ` Dmitry A. Kazakov 2012-01-06 14:45 ` Martin Dowie 2012-01-06 16:45 ` Adam Beneschan 0 siblings, 2 replies; 33+ messages in thread From: Dmitry A. Kazakov @ 2012-01-06 13:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 13:13 ` Dmitry A. Kazakov @ 2012-01-06 14:45 ` Martin Dowie 2012-01-06 15:07 ` Martin ` (2 more replies) 2012-01-06 16:45 ` Adam Beneschan 1 sibling, 3 replies; 33+ messages in thread From: Martin Dowie @ 2012-01-06 14:45 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 14:45 ` Martin Dowie @ 2012-01-06 15:07 ` Martin 2012-01-06 16:40 ` Robert A Duff 2012-01-06 17:20 ` Dmitry A. Kazakov 2 siblings, 0 replies; 33+ messages in thread From: Martin @ 2012-01-06 15:07 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 14:45 ` Martin Dowie 2012-01-06 15:07 ` Martin @ 2012-01-06 16:40 ` Robert A Duff 2012-01-06 17:04 ` Martin Dowie 2012-01-19 7:47 ` David Thompson 2012-01-06 17:20 ` Dmitry A. Kazakov 2 siblings, 2 replies; 33+ messages in thread From: Robert A Duff @ 2012-01-06 16:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 16:40 ` Robert A Duff @ 2012-01-06 17:04 ` Martin Dowie 2012-01-19 7:47 ` David Thompson 1 sibling, 0 replies; 33+ messages in thread From: Martin Dowie @ 2012-01-06 17:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 16:40 ` Robert A Duff 2012-01-06 17:04 ` Martin Dowie @ 2012-01-19 7:47 ` David Thompson 1 sibling, 0 replies; 33+ messages in thread From: David Thompson @ 2012-01-19 7:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 14:45 ` Martin Dowie 2012-01-06 15:07 ` Martin 2012-01-06 16:40 ` Robert A Duff @ 2012-01-06 17:20 ` Dmitry A. Kazakov 2012-01-07 1:47 ` Randy Brukardt 2 siblings, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2012-01-06 17:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 17:20 ` Dmitry A. Kazakov @ 2012-01-07 1:47 ` Randy Brukardt 2012-01-07 9:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 33+ messages in thread From: Randy Brukardt @ 2012-01-07 1:47 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 1:47 ` Randy Brukardt @ 2012-01-07 9:21 ` Dmitry A. Kazakov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry A. Kazakov @ 2012-01-07 9:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 13:13 ` Dmitry A. Kazakov 2012-01-06 14:45 ` Martin Dowie @ 2012-01-06 16:45 ` Adam Beneschan 1 sibling, 0 replies; 33+ messages in thread From: Adam Beneschan @ 2012-01-06 16:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 10:02 ` Martin 2012-01-06 11:23 ` Peter C. Chapin @ 2012-01-06 16:36 ` Adam Beneschan 2012-01-07 14:54 ` stefan-lucks 2 siblings, 0 replies; 33+ messages in thread From: Adam Beneschan @ 2012-01-06 16:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 10:02 ` Martin 2012-01-06 11:23 ` Peter C. Chapin 2012-01-06 16:36 ` Adam Beneschan @ 2012-01-07 14:54 ` stefan-lucks 2012-01-07 15:11 ` Dmitry A. Kazakov 2 siblings, 1 reply; 33+ messages in thread From: stefan-lucks @ 2012-01-07 14:54 UTC (permalink / raw) 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! ------ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 14:54 ` stefan-lucks @ 2012-01-07 15:11 ` Dmitry A. Kazakov 2012-01-08 9:41 ` stefan-lucks 2012-01-09 6:16 ` Randy Brukardt 0 siblings, 2 replies; 33+ messages in thread From: Dmitry A. Kazakov @ 2012-01-07 15:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 15:11 ` Dmitry A. Kazakov @ 2012-01-08 9:41 ` stefan-lucks 2012-01-09 6:16 ` Randy Brukardt 1 sibling, 0 replies; 33+ messages in thread From: stefan-lucks @ 2012-01-08 9:41 UTC (permalink / raw) 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! ------ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 15:11 ` Dmitry A. Kazakov 2012-01-08 9:41 ` stefan-lucks @ 2012-01-09 6:16 ` Randy Brukardt 1 sibling, 0 replies; 33+ messages in thread From: Randy Brukardt @ 2012-01-09 6:16 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 9:45 ` stefan-lucks 2012-01-06 10:02 ` Martin @ 2012-01-06 15:11 ` J-P. Rosen 2012-01-06 15:26 ` Martin 1 sibling, 1 reply; 33+ messages in thread From: J-P. Rosen @ 2012-01-06 15:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 15:11 ` J-P. Rosen @ 2012-01-06 15:26 ` Martin 2012-01-07 1:50 ` Randy Brukardt 0 siblings, 1 reply; 33+ messages in thread From: Martin @ 2012-01-06 15:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 15:26 ` Martin @ 2012-01-07 1:50 ` Randy Brukardt 2012-01-07 10:12 ` Martin 0 siblings, 1 reply; 33+ messages in thread From: Randy Brukardt @ 2012-01-07 1:50 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 1:50 ` Randy Brukardt @ 2012-01-07 10:12 ` Martin 2012-01-07 12:22 ` Simon Wright 2012-01-09 6:21 ` Randy Brukardt 0 siblings, 2 replies; 33+ messages in thread From: Martin @ 2012-01-07 10:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 10:12 ` Martin @ 2012-01-07 12:22 ` Simon Wright 2012-01-07 17:10 ` Martin 2012-01-09 6:21 ` Randy Brukardt 1 sibling, 1 reply; 33+ messages in thread From: Simon Wright @ 2012-01-07 12:22 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 12:22 ` Simon Wright @ 2012-01-07 17:10 ` Martin 0 siblings, 0 replies; 33+ messages in thread From: Martin @ 2012-01-07 17:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-07 10:12 ` Martin 2012-01-07 12:22 ` Simon Wright @ 2012-01-09 6:21 ` Randy Brukardt 2012-01-09 7:57 ` Martin Dowie 2012-01-31 23:34 ` Yannick Duchêne (Hibou57) 1 sibling, 2 replies; 33+ messages in thread From: Randy Brukardt @ 2012-01-09 6:21 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-09 6:21 ` Randy Brukardt @ 2012-01-09 7:57 ` Martin Dowie 2012-01-31 23:34 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 33+ messages in thread From: Martin Dowie @ 2012-01-09 7:57 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-09 6:21 ` Randy Brukardt 2012-01-09 7:57 ` Martin Dowie @ 2012-01-31 23:34 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 33+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-01-31 23:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 8:45 Ada2012 : Expression functions and extended return statements Martin 2012-01-06 9:45 ` stefan-lucks @ 2012-01-06 16:33 ` Adam Beneschan 2012-01-06 16:38 ` Adam Beneschan 2012-01-31 23:20 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 33+ messages in thread From: Adam Beneschan @ 2012-01-06 16:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 16:33 ` Adam Beneschan @ 2012-01-06 16:38 ` Adam Beneschan 2012-01-06 22:12 ` Robert A Duff 0 siblings, 1 reply; 33+ messages in thread From: Adam Beneschan @ 2012-01-06 16:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 16:38 ` Adam Beneschan @ 2012-01-06 22:12 ` Robert A Duff 0 siblings, 0 replies; 33+ messages in thread From: Robert A Duff @ 2012-01-06 22:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ada2012 : Expression functions and extended return statements 2012-01-06 8:45 Ada2012 : Expression functions and extended return statements Martin 2012-01-06 9:45 ` stefan-lucks 2012-01-06 16:33 ` Adam Beneschan @ 2012-01-31 23:20 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 33+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-01-31 23:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2012-01-31 23:34 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-06 8:45 Ada2012 : Expression functions and extended return statements Martin 2012-01-06 9:45 ` stefan-lucks 2012-01-06 10:02 ` Martin 2012-01-06 11:23 ` Peter C. Chapin 2012-01-06 11:37 ` Martin 2012-01-06 13:13 ` Dmitry A. Kazakov 2012-01-06 14:45 ` Martin Dowie 2012-01-06 15:07 ` Martin 2012-01-06 16:40 ` Robert A Duff 2012-01-06 17:04 ` Martin Dowie 2012-01-19 7:47 ` David Thompson 2012-01-06 17:20 ` Dmitry A. Kazakov 2012-01-07 1:47 ` Randy Brukardt 2012-01-07 9:21 ` Dmitry A. Kazakov 2012-01-06 16:45 ` Adam Beneschan 2012-01-06 16:36 ` Adam Beneschan 2012-01-07 14:54 ` stefan-lucks 2012-01-07 15:11 ` Dmitry A. Kazakov 2012-01-08 9:41 ` stefan-lucks 2012-01-09 6:16 ` Randy Brukardt 2012-01-06 15:11 ` J-P. Rosen 2012-01-06 15:26 ` Martin 2012-01-07 1:50 ` Randy Brukardt 2012-01-07 10:12 ` Martin 2012-01-07 12:22 ` Simon Wright 2012-01-07 17:10 ` Martin 2012-01-09 6:21 ` Randy Brukardt 2012-01-09 7:57 ` Martin Dowie 2012-01-31 23:34 ` Yannick Duchêne (Hibou57) 2012-01-06 16:33 ` Adam Beneschan 2012-01-06 16:38 ` Adam Beneschan 2012-01-06 22:12 ` Robert A Duff 2012-01-31 23:20 ` Yannick Duchêne (Hibou57)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox