Re: Overring function and its returned type

["Randy Brukardt" <randy@rrsoftware.com>]

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

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wn0ieqnqule2fv@cardamome...
>Le Sun, 18 Nov 2012 15:53:28 +0100, AdaMagica 
><christ-usch.grein@t-online.de> a �crit:
>
...
>> How can this be? The actual of an out-parameter exists already, whereas 
>> the return object is newly created.
>
>He meant it, semantically. You can return a value into an already existing 
>object, and in practice, except with purely functional languages, that's 
>always how it goes (even if the target may be adjusted in some way for 
>many reasons).

That's definitely *not* the case in Ada - "always" is way too strong here. 
There are a number of ways for the result of a function to be a new object 
that is never put into an existing object. Two that come to mind are:

      A := F(I).Comp; -- where Comp is a record component of an elementary 
type.

The record object returned by F(I) is never put into any existing object in 
this case, and even the component is copied. I've occassionally done this in 
my programs.

    P (F(I)); -- P is a procedure with an "in" parameter of the type of 
F(I).

Here, the record object returned by F(I) is passed to P; again this is a new 
object that is never put into an existing object. I've done this quite a few 
times in my programs.

Cases like this complicate the definition of function returns in Ada, and 
these are quite different than the situation with "out" parameters (which 
cannot create a new object). (They also complicate the finalization rules, 
as you might guess.)

I know that Bob has always wanted "out" parameters and function results to 
work as similarly as possible, but it should be clear that there are 
differences between them that are fundemental. I don't think that a language 
could work without something like function results ("out" parameters aren't 
quite so fundemental). You could get them closer in Ada if you could somehow 
allow more objects to have mutable discriminants and especially mutable 
array bounds, but I think that would make most objects more expensive than 
Ada's currently are (much more dynamic allocation would be required). And 
you still need very short-lived objects (as in the examples above).

                                             Randy.




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