Overring function and its returned type

Overring function and its returned type

[Yannick Duchêne (Hibou57)]

I feel a bit disappointed with a construct I never attempted before, and  
which seems to not be valid according to GNAT, which I believe is not  
wrong, as I can't recall to have read it's allowed. First a snippet, then  
some comments.


     procedure Ex
     is

        -- ========================================

        package P1 is

           type R is interface;
           type T is interface;

           not overriding
           function F
             (E : T)
              return R'Class
              is abstract;
        end;

        -- ========================================

        package P2 is

           type R is interface and P1.R;
           type T is interface and P1.T;

           overriding
           function F
             (E : T)
              return R'Class -- Not overriding :-(
              is abstract;
        end;

        -- ========================================

        package P3 is

           type R is new P1.R with null record;
           type T is new P1.T with null record;

           overriding
           function F
             (E : T)
              return P1.R'Class;
        end;

        -- ----------------------------------------

        package body P3 is

           overriding
           function F
             (E : T)
              return P1.R'Class
           is
              X : R;
           begin
              return X; -- This is OK
           end;
        end;

        -- ========================================

     begin
        null;
     end Ex;


In `P2`, `R` inherits from `P1.R`, so belongs to `P1.R'Class`, and is a  
value returned type for an concrete function `F`, as `P3` shows. But GNAT  
reject it, complaining `P2.F` is not overriding (by the way, the example  
also shows how much it is safer to always add an “[not] overriding”  
qualification to dispatching subprograms).

As `P2.R'Class` is compatible with `P1.R'Class`, why not allow this for an  
overriding function? This case makes me think of the one fixed by Ada  
2012, about the returned class wide type of a function and the extended  
returned statement, explained in [Extended return  
statements](http://www.ada-auth.org/standards/12rat/html/Rat12-4-6.html).

If that's not allowed with good reasons, then what are these?

A work around could be to use overloading instead of overriding, but that  
may cause troubles when there is no other arguments to the function, in  
which case this will probably looks ambiguous in some contexts. This can  
also cause issues when there are predicates using `F` in `P1`. I could  
give a tiny example of such a case if someone need one to see why it may  
be an issue.

If that could be OK to allow overriding functions to change their return  
type to a compatible type when this type is class wide, then is there a  
chance to add it as a last minute change for Ada 2012?


-- 
“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: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Fri, 09 Nov 2012 08:13:23 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> In `P2`, `R` inherits from `P1.R`, so belongs to `P1.R'Class`, and is a  
> value returned type for an concrete function `F`

Please, read “and is a *valid* returned type”.


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

Re: Overring function and its returned type

[Dmitry A. Kazakov]

On Fri, 09 Nov 2012 08:13:23 +0100, Yannick Duch�ne (Hibou57) wrote:

>            overriding
>            function F
>              (E : T)
>               return R'Class -- Not overriding :-(
>               is abstract;

What is this? "overriding" + "abstract" does not make sense.

In any case it is the default. When you do nothing, you get F through
inheritance and it is abstract when the parent's F was.

Ada's declarations are not idempotent, in the sense that you cannot repeat
them like you could in C++. So "F ... is abstract" always
overloads/conflicts.

P.S. They should really have used the syntax with the keyword "overriding"
trailing behind "is" rather than preceding "function/procedure."

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

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Fri, 09 Nov 2012 09:24:18 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Fri, 09 Nov 2012 08:13:23 +0100, Yannick Duchêne (Hibou57) wrote:
>
>>            overriding
>>            function F
>>              (E : T)
>>               return R'Class -- Not overriding :-(
>>               is abstract;
>
> What is this? "overriding" + "abstract" does not make sense.

Overriding sometime do nothing, just remind something, recall an inherited  
definition explicitly. Not the same, but a bit comparable to subtyping  
used for type renaming (except I hate the latter and rather like the  
former).

Overriding may also be used to add a postcondition or replace a class wide  
precondition by another.

I you prefer, you can instead think of `P3.F` returning `P3.R'Class`  
instead of `P1.R'Class`, which would be overriding in the strict way you  
expect.

> In any case it is the default. When you do nothing, you get F through
> inheritance and it is abstract when the parent's F was.

I know, but sometime you want something more explicit.

> Ada's declarations are not idempotent, in the sense that you cannot  
> repeat
> them like you could in C++. So "F ... is abstract" always
> overloads/conflicts.

I don't get conflict when it happens I do it, it works fine.

> P.S. They should really have used the syntax with the keyword  
> "overriding"
> trailing behind "is" rather than preceding "function/procedure."

Matter of taste. Personally, it happens I think I would have preferred  
“new” instead of “not overriding”, but I don't mind too much. That's to be  
added to the list of tiny things which may be nice, but not required.


-- 
“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: Overring function and its returned type

[Dmitry A. Kazakov]

On Fri, 09 Nov 2012 10:14:32 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Fri, 09 Nov 2012 09:24:18 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Fri, 09 Nov 2012 08:13:23 +0100, Yannick Duch�ne (Hibou57) wrote:
>>
>>>            overriding
>>>            function F
>>>              (E : T)
>>>               return R'Class -- Not overriding :-(
>>>               is abstract;
>>
>> What is this? "overriding" + "abstract" does not make sense.
> 
> Overriding sometime do nothing, just remind something, recall an inherited  
> definition explicitly.

No, overriding *always* does something. It overrides the part of the
polymorphic body it specifies.

------------
Alas, I overlooked that you used "R" for two different types. Yet another
argument for consequent use of "use" clauses! Down with "with" (:-))

I don't see a good reason why nominal type equivalence should be further
eroded. When you derive a new interface you get another type. It may have
operations of its own. So, it is not automatically compatible.

A more general question is about overriding out-operations to narrower
subtypes, and/or overriding in-operations to wider subtypes. That could
work.

Specifically regarding class-wide types they are not considered subtypes. I
believe there could be too many conflicts to make them subtypes. I mean a
model in which when S is derived from T, then S'Class is a subtype of
T'Class (constrained to S and its descendants).

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

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Fri, 09 Nov 2012 14:11:38 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> A more general question is about overriding out-operations to narrower
> subtypes, and/or overriding in-operations to wider subtypes. That could
> work.

Nice to read this. Made me think of it too, with the added rule that `in  
out` would need to be fixed in overriding methods and not change their  
type. However, about `out` mode, that may be more easy with function  
returned object than with object “returned” by an `out` parameter. An  
`out` parameter may not be updated as a whole, which is required for  
example to change the type of a discriminated type with default  
discriminants. The function result case is safer because more predictive.  
Or else, would have to require some `out` parameters to be updated as a  
whole.

-- 
“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: Overring function and its returned type

[Adam Beneschan]

On Friday, November 9, 2012 12:25:17 AM UTC-8, Dmitry A. Kazakov wrote:
> On Fri, 09 Nov 2012 08:13:23 +0100, Yannick Duchêne (Hibou57) wrote:
> 
> >            overriding
> >            function F
> >              (E : T)
> >               return R'Class -- Not overriding :-(
> >               is abstract;
> 
> What is this? "overriding" + "abstract" does not make sense.

I don't see that.  It's true that if you define an abstract type T1 with an abstract operation Op, and if you derive an abstract type T2 from T1, Op will be inherited, so it doesn't affect the semantics it you redeclare an abstract Op.  Still, I can certainly understand why a programmer would want to redeclare Op anyway, so that a person reading the package that defines T2 will see all the operations available for T2, and won't have to hunt for the definition of T1 to see what other operations might be defined for T2.  And if the programmer does redeclare Op for T2, then it's a good idea to add the "overriding" keyword to prevent accidents.

Also, it's legal to declare an abstract type derived from a non-abstract type.  In that case, you may actually want to override the non-abstract inherited operation with an abstract one.

                         -- Adam



> 
> 
> In any case it is the default. When you do nothing, you get F through
> 
> inheritance and it is abstract when the parent's F was.
> 
> 
> 
> Ada's declarations are not idempotent, in the sense that you cannot repeat
> 
> them like you could in C++. So "F ... is abstract" always
> 
> overloads/conflicts.
> 
> 
> 
> P.S. They should really have used the syntax with the keyword "overriding"
> 
> trailing behind "is" rather than preceding "function/procedure."
> 
> 
> 
> -- 
> 
> Regards,
> 
> Dmitry A. Kazakov
> 
> http://www.dmitry-kazakov.de

Re: Overring function and its returned type

[Adam Beneschan]

On Thursday, November 8, 2012 11:15:06 PM UTC-8, Hibou57 (Yannick Duchêne) wrote:
 
> If that could be OK to allow overriding functions to change their return   
> type to a compatible type when this type is class wide, then is there a  
> chance to add it as a last minute change for Ada 2012?

Although I'm not on the ARG, I can confidently say that the answer to this question is "absolutely not".  What you're asking for is a major change that would need a lot of consideration to get the semantics right and make sure it wouldn't have any impact on any other part of the language.  And at this point, I don't think even minor changes are being considered unless they're actual errors or perhaps editorial issues.  

                               -- Adam

Re: Overring function and its returned type

[J-P. Rosen]

Le 09/11/2012 20:34, Adam Beneschan a �crit :

> Although I'm not on the ARG, I can confidently say that the answer to
> this question is "absolutely not".
Point of information: the final vote of national bodies is due within a
few days. So, it is definitely far too late for even the smallest changes.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Fri, 09 Nov 2012 23:00:39 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:

> Le 09/11/2012 20:34, Adam Beneschan a écrit :
>
>> Although I'm not on the ARG, I can confidently say that the answer to
>> this question is "absolutely not".
> Point of information: the final vote of national bodies is due within a
> few days. So, it is definitely far too late for even the smallest  
> changes.

OK


-- 
“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: Overring function and its returned type

[sbelmont700]

More generally, you are talking about 'covariant return types', which is a feature only a handful of languages support (notably C++).  IMHO, i don't really see the need for it; a type is either a child (and matches the parent, as in P3) or it doesn't and it's not (as in P2).  The whole point is to use the abstract parent classwide type exclusively, so I never saw the need to tinker around with the concrete child types (i would be interested in a real life scenario in which you would want this construct)

-sb

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

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

> More generally, you are talking about 'covariant return types', which is  
> a feature only a handful of languages support (notably C++).
May be (I feel to remember this, while unsure).

>  IMHO, i don't really see the need for it; a type is either a child (and  
> matches the parent, as in P3) or it doesn't and it's not (as in P2).   
> The whole point is to use the abstract parent classwide type  
> exclusively, so I never saw the need to tinker around with the concrete  
> child types (i would be interested in a real life scenario in which you  
> would want this construct)

I won't post here the real thing, I'm only OK to post samples and  
snippets. You will have to trust me when I say it make sense (so much, I  
wrote things straight away, without suspecting it could be rejected).  
Still, to give you an idea, imagine this:


In `P3` spec, replace the definition of `F` with this one:


           overriding
           function F
             (E : T)
              return P1.R'Class
              with Post'Class =>
                 F'Result in R'Class;


Then, a sample use case would look like this:


        A : P3.T;
        B : P3.R'Class := P3.R'Class (A.F);


That looks weird, as much weird as writing something like this:


        type IST is new Integer range 1 .. 10;

        function F return Integer
           with Post =>
              F'Result in 1 .. 10;

        function F return Integer
        is begin
           return 1;
        end;

        D : IST := IST (F);


Reading the above, one may say “that's silly, if you know the returned  
type, just specify it in the declaration, and this would additionally  
avoid a cumbersome checked conversion at every call place”. That's exactly  
what I feel adding a postcondition to `F` just to state what the returned  
type is, and adding a conversion at the call place. My words may looks a  
too hard, but I would say I would expect Ada to not require to specify  
types via pre/post condition, but in signature instead.

I will also try to workaround with an overloading instead of an  
overriding, but I'm afraid of getting into a mess with this solution. Will  
choose which cause the less troubles, and although the  
postcondition+conversion solution looks like bloat, I believe that's still  
the safest. I will still try both to really get an idea…


-- 
“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: Overring function and its returned type

[sbelmont700]

On Friday, November 9, 2012 4:10:09 PM UTC-5, Hibou57 (Yannick Duchêne) wrote:
>
> Reading the above, one may say “that's silly, if you know the returned  
> 
> type, just specify it in the declaration, and this would additionally  
> 
> avoid a cumbersome checked conversion at every call place”.
> 
>

That's silly, because in such a case your classwide types are just for show.  If you are already coupled directly to P3, and already know that A is a P3.T, then you don't need to override or extend or cast anything: you already have full visibility for direct calls on anything in P3, and will have to go back and change the unit either way if down the road you create a P4.  Just create a non-overriding, not-necessarily-overloading function in P3 that returns whatever type you want, with whatever pre/post conditions you like.


-sb

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Fri, 09 Nov 2012 22:10:05 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> I will also try to workaround with an overloading instead of an  
> overriding, but I'm afraid of getting into a mess with this solution.  
> Will choose which cause the less troubles, and although the  
> postcondition+conversion solution looks like bloat, I believe that's  
> still the safest. I will still try both to really get an idea…

Two attempts, with a comment comparing both at the end.


First attempt
=============

Something I tried, which lead to an interesting issue. I don't know if  
GNAT is right or wrong, this will require a careful reading of the RM.

Replace `P3` spec with:


        package P3 is

           type R is new P1.R with null record;
           type T is new P1.T with null record;

           overriding
           function F
             (E : T)
              return P1.R'Class
              with Post'Class =>
                 F'Result in R'Class;

           -- Not a primitive operation.
           function F
             (E : T'Class)
              return R'Class
              is (R'Class (P1.T (E).F));
        end;


And a use case, which fails:


        A : P3.T;
        B : P1.R'Class := A.F;
        C : P3.R'Class := A.F; -- Fails here


That's C's assignment which fails. Seems GNAT cannot resolve it figure it  
refers to the second `F` function (it does not even complains about an  
ambiguity). Will have to look at the RM for it. I feel this should be OK  
and could be resolved as expected, but may be the RM states otherwise.

The second `F` function cannot be a primitive, due to its “inline”  
expression.


Second attempt
==============

Another way to solve it:


        package P3 is

           type R is new P1.R with null record;
           type T is new P1.T with null record;

           overriding
           function F
             (E : T)
              return P1.R'Class
              with Post'Class =>
                 F'Result in R'Class;

           not overriding
           function F
             (E : T)
              return R'Class;
        end;

        -- ----------------------------------------

        package body P3 is

           overriding
           function F
             (E : T)
              return P1.R'Class
           is
              X : R;
           begin
              return X;
           end;

           not overriding
           function F
             (E : T)
              return R'Class
           is begin
              return R'Class (P1.T (E).F);
           end;
        end;


And the sample use case:


        A : P3.T;
        B : P1.R'Class := A.F; -- Fails here
        C : P3.R'Class := A.F;


Assignment to `B` is considered ambiguous, but that's not an issue, as  
only the case corresponding to the assignment to `C` is expected. Anyway,  
the case of the assignment to `B` can be solved this way:


        B : P1.R'Class := P1.R'Class'(A.F); -- Resolved ambiguity


Comparing both
==============

What's nice with the first attempt, is that what's returned is explicitly  
shown in the spec. What's nice with the second attempt, is that it works  
(good point, cheese), and that it's a primitive (if ever that matters  
really), but as a cons, it is not as explicit as in the first attempt.

May be the best solution is to do as in the second attempt, and give the  
second `F` function, a comment “specifying” the returned result is exactly  
the same as the with the first `F`, expect explicitly of type `R'Class`.

That's not as clean as one could expect, but at least I don't see it as  
presenting any potential issues in the case where `P1` holds a primitive  
with a predicate referring to `F`. The human reader could infer such a  
predicate would applies to the second `F` function too, as long as it is  
clear enough both returns the same thing, except for their explicit types.  
The compiler won't know, but the human reader will.


-- 
“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: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Sat, 10 Nov 2012 01:28:54 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> What's nice with the second attempt, is that it works

It works, but it's unsafe on the long‑run: if there are, one of the  
preconditions of the inherited `F` must be reported to the other `F`, and  
the same with postconditions, except you have to report them all. This is  
too risky, as something may be forgotten and the language does not help  
here. Even more risky if maintenance occurs on the inherited `F` in an  
ancestors type, and some predicates are changed, or worst predicates added  
while there were none.

Even if annoying, the only safe way is really the initial one, that is to  
just have one `F`, the inherited one overrided, with an added  
postcondition and an explicit checked type conversion at call places  
(which may be removed in the future if ever a day Ada starts to supports  
this).

-- 
“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: Overring function and its returned type

[Peter C. Chapin]

On 11/09/2012 02:57 PM, sbelmont700@gmail.com wrote:

> More generally, you are talking about 'covariant return types', which
> is a feature only a handful of languages support (notably C++).
> IMHO, i don't really see the need for it; a type is either a child
> (and matches the parent, as in P3) or it doesn't and it's not (as in
> P2).

I realize this thread is dead but I found it interesting and looked into 
the topic a little. It is true that C++ supports covariant refinement of 
return types as does, for example, Scala. In theory it should also be 
type safe to allow contravariant refinement of parameter types. Scala 
does not allow that... which surprised me considering Scala's reputation 
of having a very expressive type system.

I talked with some people in the Scala community and it turns out the 
reason for the restriction is related to overload resolution and 
ambiguity. In the case of C++ there is no overloading on return types 
and thus allowing covariant refinement of return types is straight 
forward there. However, since Ada does allow overloading on return 
types, complications arise.

To illustrate let me start with a simple derivation class:

package Vehicles is
   type Vehicle is interface;
   type Car is abstract new Vehicle with null record;
   type Sports_Car is abstract new Car with null record;
end Vehicles;

Now consider:

with Vehicles;

package Animals is
   type Animal is interface;
   function F(A : Animal) return Vehicles.Vehicle'Class is abstract;
   function F(A : Animal) return Vehicles.Car'Class is abstract;

   type Cat is abstract new Animal with null record;
   overriding function F(C: Cat) return Vehicles.Sports_Car'Class is 
abstract;
end Animals;


Suppose covariant refinement of return types was allowed in Ada. In that 
case which F is being overridden here? Since Sports_Car <: Vehicle and 
also Sports_Car <: Car the overriding is ambiguous.

I suppose rules could be written to clarify these things but it probably 
wouldn't be worth the additional language complexity.

Peter

Re: Overring function and its returned type

[Maciej Sobczak]

W dniu czwartek, 15 listopada 2012 16:13:06 UTC+1 użytkownik Peter C. Chapin napisał:

> I talked with some people in the Scala community and it turns out the 
> reason for the restriction is related to overload resolution and 
> ambiguity.

Which have a very simple solution: report the problem when (and *only* when) there is a problem.

> To illustrate let me start with a simple derivation class:

> In that 
> case which F is being overridden here?

In the case of ambiguity, let the compiler inform you about that.

The problem is that this single example is very artificial and represents some corner case that might actually never materialize in any of our projects. There are many more examples that are practical and do not hit any corner cases of overload resolution and that could be easily handled - and therefore could become an added value in the type system.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Overring function and its returned type

[Peter C. Chapin]

On 11/16/2012 05:40 AM, Maciej Sobczak wrote:

> The problem is that this single example is very artificial and
> represents some corner case that might actually never materialize in
> any of our projects. There are many more examples that are practical
> and do not hit any corner cases of overload resolution and that could
> be easily handled - and therefore could become an added value in the
> type system.


Yes, good point. I think it's in keeping with C++'s philosophy to allow 
what seems reasonable and, like you said, only complain if a problem 
actually arises. I can see the value of that approach. Yet I wonder if 
it increases the risk of an "unrelated" change breaking an existing code 
base by introducing an ambiguity where none existed before.

Peter

Re: Overring function and its returned type

[Maciej Sobczak]

W dniu piątek, 16 listopada 2012 13:39:50 UTC+1 użytkownik Peter C. Chapin napisał:

> Yet I wonder if 
> it increases the risk of an "unrelated" change breaking an existing code 
> base by introducing an ambiguity where none existed before.

I'm not sure - probably, today, it is too late to add this to the language for the reasons that you have mentioned. However, this feature could have been safely added together with other OO-related features, as the whole support for OO was new in the language and there was no existing codebase that would break.

An interesting property of Ada, and what makes this issue more difficult than in C++ is that Ada supports out parameters, which from the language design point of view should work like return values. Covariant return types are easy to picture, but covariant out parameters? Hm... Maybe this is where things would start to shake.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Overring function and its returned type

[Peter C. Chapin]

On 11/16/2012 10:27 AM, Maciej Sobczak wrote:

> An interesting property of Ada, and what makes this issue more
> difficult than in C++ is that Ada supports out parameters, which from
> the language design point of view should work like return values.
> Covariant return types are easy to picture, but covariant out
> parameters? Hm... Maybe this is where things would start to shake.


Yes, interesting point about parameter modes!

Peter

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Fri, 16 Nov 2012 16:27:37 +0100, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
> An interesting property of Ada, and what makes this issue more difficult  
> than in C++ is that Ada supports out parameters, which from the language  
> design point of view should work like return values.

But it is not the same as a returned value. It may be like a return, it  
may be like an update, all depends on what the sub‑program do. May be a  
`return` mode is an idea…

-- 
“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: Overring function and its returned type

[Robert A Duff]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 16 Nov 2012 16:27:37 +0100, Maciej Sobczak
> <see.my.homepage@gmail.com> a écrit:
>> An interesting property of Ada, and what makes this issue more
>> difficult  than in C++ is that Ada supports out parameters, which from
>> the language  design point of view should work like return values.
>
> But it is not the same as a returned value.

But it should be.

>... It may be like a return, it
> may be like an update, all depends on what the sub‑program do. May be a
> `return` mode is an idea…

- Bob

Re: Overring function and its returned type

[AdaMagica]

On Saturday, November 17, 2012 8:11:23 PM UTC+1, Robert A Duff wrote:
> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> > Le Fri, 16 Nov 2012 16:27:37 +0100, Maciej Sobczak
> > <see.my.homepage@gmail.com> a écrit:
> >> An interesting property of Ada, and what makes this issue more
> >> difficult  than in C++ is that Ada supports out parameters, which from
> >> the language  design point of view should work like return values.
> > But it is not the same as a returned value.
> But it should be.

How can this be? The actual of an out-parameter exists already, whereas the return object is newly created.

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Sun, 18 Nov 2012 15:53:28 +0100, AdaMagica  
<christ-usch.grein@t-online.de> a écrit:

> On Saturday, November 17, 2012 8:11:23 PM UTC+1, Robert A Duff wrote:
>> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>> > Le Fri, 16 Nov 2012 16:27:37 +0100, Maciej Sobczak
>> > <see.my.homepage@gmail.com> a écrit:
>> >> An interesting property of Ada, and what makes this issue more
>> >> difficult  than in C++ is that Ada supports out parameters, which  
>> from
>> >> the language  design point of view should work like return values.
>> > But it is not the same as a returned value.
>> But it should be.
>
> 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).


-- 
“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: Overring function and its returned type

[AdaMagica]

On Monday, November 19, 2012 9:41:07 AM UTC+1, Hibou57 (Yannick Duchêne) wrote:
> > 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).

From this point of view, they are semantically the same in Ada. But for me, it's a non sequitur.

An out parameter as an update is like an assignment A := B; hidden inside some procedure; a return object is constructed somehow. This is fundamentally different for me.

Is (1) equal to (2):
 declare
   A: T := Some_Value; -- (1)
 begin
   A := Some_Value;  -- (2)

Re: Overring function and its returned type

[Dmitry A. Kazakov]

On Mon, 19 Nov 2012 05:04:25 -0800 (PST), AdaMagica wrote:

> On Monday, November 19, 2012 9:41:07 AM UTC+1, Hibou57 (Yannick Duch�ne) wrote:
>>> 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).
> 
> From this point of view, they are semantically the same in Ada. But for me, it's a non sequitur.
> 
> An out parameter as an update is like an assignment A := B; hidden inside
> some procedure; a return object is constructed somehow.

Even if the target already exists?

Out parameters cannot be used together with assignment but I would not
consider it a semantic difference. It is a syntactic artefact IMO.

> This is fundamentally different for me.
> 
> Is (1) equal to (2):
>  declare
>    A: T := Some_Value; -- (1)
>  begin
>    A := Some_Value;  -- (2)

But function result is definitely not initialization, if you meant that. So
1 and 2 are exactly same, except for semantically broken limited returns,
of course.

Furthermore, starting with Ada 2005 which borrowed FORTRAN's idea of named
result you could have the result constructed inside a function:

   return Result : T do
       -- It is constructed here
   end return;

You could even have it constructed and destructed more than once!
(unfortunately)

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

Re: Overring function and its returned type

[Randy Brukardt]

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

Re: Overring function and its returned type

[Randy Brukardt]

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

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wnhvol1wule2fv@cardamome...

>     procedure Ex  is
>
>        -- ========================================
>
>        package P1 is
>
>           type R is interface;
>           type T is interface;
>
>          not overriding
>           function F
>             (E : T)
>              return R'Class
>              is abstract;
>        end;
>
>        -- ========================================
>
>        package P2 is
>
>           type R is interface and P1.R;
>           type T is interface and P1.T;
>
>           overriding
>           function F
>             (E : T)
>              return R'Class -- Not overriding :-(
>              is abstract;
>        end;
>
>        -- ========================================

I'd strongly suggest to use different names for different types in examples, 
otherwise you'll confuse everyone (and yourself). Just because you can use 
the same name in the real code (and might want to in unusual circumstances) 
is no good reason to make examples that confuse the heck out of everyone.

In any case, overriding requires subtype conformance. And if you properly 
named the types, the problem would be obvious.

        package P2 is

           type R2 is interface and P1.R;
           type T2 is interface and P1.T;

           overriding
           function F
             (E : T2)
              return R2'Class -- Not overriding :-(
              is abstract;
        end;

Since overriding requires subtype conformance (among other things, requiring 
the same subtype on all non-controlling parameters and results), and 
R2'Class /= R'Class (and this isn't a controlling result), no overriding is 
possible. There are good reasons for these restrictions (mostly 
implementation-oriented).

I'm sure there exist (very limited) cases where it might make sense to relax 
subtype conformance, but there would need to be a strong justification for 
the significant added complication in the language rules and implementation. 
I'm pretty certain that an example using types T and R isn't it.

In any case, Ada 2012 is finished (with possibility of some editorial 
corrections in the final edition, but nothing substansive). If we were going 
to fix anything in it, it would be the handful of bad bugs that have been 
identified, surely nothing involving features that are unchanged in Ada 2012 
(which is the case with overriding, modulo wording bugs).

                                                       Randy.

Re: Overring function and its returned type

[Yannick Duchêne (Hibou57)]

Le Sat, 10 Nov 2012 08:55:11 +0100, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> I'd strongly suggest to use different names for different types in  
> examples,
> otherwise you'll confuse everyone (and yourself). Just because you can  
> use
> the same name in the real code (and might want to in unusual  
> circumstances)
> is no good reason to make examples that confuse the heck out of everyone.

Though it was clear, since there was package prefixes. Hope every one who  
has read it understood it the way it was to be.

> Since overriding requires subtype conformance (among other things,  
> requiring
> the same subtype on all non-controlling parameters and results), and
> R2'Class /= R'Class (and this isn't a controlling result), no overriding  
> is possible.

That's how it is actually, yes.

> There are good reasons for these restrictions (mostly
> implementation-oriented).

Not convinced at all, as I gave an Ada interpretation of this, using a  
postcondition and a type conversion, which can be checked to be valid: if  
you replace the postcondition by a proper returned result type, the  
postcondition is statically checked and not needed any more, and the same  
for the type conversion. I also explained why one could expect Ada to  
obviously support it. I don't believe they are implementation issue here,  
except may be AdaCore or their clients not being at all interested in this  
kind of constructs (I name AdaCore, as there seems to be the near only  
ones implicitly referred to, when talking about compiler implementation,  
and good reason for integration of Ada features).

Dmitry's idea of a more general application of the same principle is nice,  
but may indeed present more issues. I gave one example issue, but I'm  
thinking about another even with simple `in` mode parameters. I still  
believe his idea should be feasible too and good for Ada (and to be as  
much sounds).

> I'm sure there exist (very limited) cases where it might make sense to  
> relax
> subtype conformance, but there would need to be a strong justification  
> for
> the significant added complication in the language rules and  
> implementation.
> I'm pretty certain that an example using types T and R isn't it.
>
> In any case, Ada 2012 is finished (with possibility of some editorial
> corrections in the final edition, but nothing substansive). If we were  
> going
> to fix anything in it, it would be the handful of bad bugs that have been
> identified, surely nothing involving features that are unchanged in Ada  
> 2012
> (which is the case with overriding, modulo wording bugs).

Yes, I understand it's far too late for Ada 2012. I will wait and send a  
proposal to the Ada‑Comment list a future day (I believe not before some   
months), … this will leave enough years to figure the case in deeper  
details.

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