record extension aggregate for returned type legal?

record extension aggregate for returned type legal?

[Georg Bauhaus]

Using two different compilers, I get contradicting messages
for the following package, viz no message at all, and an
error message pointing to LRM 4.3.2(4). Which one is right?


package Ext is

   type T is tagged private;

   package B is
      function make return T;
   end B;

private
   type T is tagged record
      n: Natural;
   end record;
end Ext;



package body Ext is

   package body B is
      function make return T is
      begin
         return (T with n => 0);  -- here
         --return (n => 0);
      end make;

   end B;

end Ext;


-- TIA, georg

Re: record extension aggregate for returned type legal?

[Martin Krischik]

Georg Bauhaus wrote:

> Using two different compilers, I get contradicting messages
> for the following package, viz no message at all, and an
> error message pointing to LRM 4.3.2(4). Which one is right?
> 
> 
> package Ext is
> 
>    type T is tagged private;
> 
>    package B is
>       function make return T;
>    end B;
> 
> private
>    type T is tagged record
>       n: Natural;
>    end record;
> end Ext;
> 
> 
> 
> package body Ext is
> 
>    package body B is
>       function make return T is
>       begin
>          return (T with n => 0);  -- here

This syntax is for child classes which first initialise there parent class
and then there own data. Like in:

return Child'(Parent with n=> 0);

>          --return (n => 0);

Should that not be

      return T'(n => 0);

?

>       end make;
> 
>    end B;
> 
> end Ext;
> 

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: record extension aggregate for returned type legal?

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: Georg Bauhaus wrote:

:> package body Ext is
:> 
:>    package body B is
:>       function make return T is
:>       begin
:>          return (T with n => 0);  -- here
: 
: This syntax is for child classes which first initialise there parent class
: and then there own data.

Yes, but one compiler finds no fault with the line in question,
the other says No.

: 
:>          --return (n => 0);
: 
: Should that not be
: 
:      return T'(n => 0);

Same as (n => 0) in return expression?

Re: record extension aggregate for returned type legal?

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: T' (spoken T kick) tells the compiler that the next expression is of type T.
: i.E: Positive'(1) means that you want a Positive and not an Integer. If you
: won't say anything the compiler will choose automaticly.

In this case T is specific, and `make` is not a primitive operation
of T (because make is in child package B). So does the compiler
have a choice at all?

LRM 4.3.2, quoted in one compiler's error message, says,

  4. The expected type for an extension_aggregate shall be a single
     nonlimited type that is a record extension. If the ancestor_part
     is an expression, it is expected to be of any nonlimited tagged
     type.

Do I understand this phrase? The expected type in the return expression
for "function make return T" is the specific tagged type T.
In "return (n => 0)", there is no extension aggregate.
In "return (T with n => 0)", there is an extension aggregate,
the ancestor part being T.

T is not limited.
T is not an extension (a record extension?).
Does T have an ancestor (does T maybe count as an ancestor of T here?)


-- Georg

Re: record extension aggregate for returned type legal?

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> : T' (spoken T kick) tells the compiler that the next expression is of
> : type T. i.E: Positive'(1) means that you want a Positive and not an
> : Integer. If you won't say anything the compiler will choose automaticly.
> 
> In this case T is specific, and `make` is not a primitive operation
> of T (because make is in child package B). So does the compiler
> have a choice at all?
> 
> LRM 4.3.2, quoted in one compiler's error message, says,
> 
>   4. The expected type for an extension_aggregate shall be a single
>      nonlimited type that is a record extension. If the ancestor_part
>      is an expression, it is expected to be of any nonlimited tagged
>      type.
> 
> Do I understand this phrase? The expected type in the return expression
> for "function make return T" is the specific tagged type T.
> In "return (n => 0)", there is no extension aggregate.
> In "return (T with n => 0)", there is an extension aggregate,
> the ancestor part being T.

But T in your example is a root class and therefore has no ancestor. T needs
an standart aggregate and not an extension aggregate.

> T is not limited.
> T is not an extension (a record extension?).
> Does T have an ancestor (does T maybe count as an ancestor of T here?)

Consider the other constructor pattern:

type P is abstract tagged private;
type C is new P with private;

function Create returns P'Class;

function Create
returns
    P'Class
is
begin
    return C'(P with ...);
end Create

With Regards.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: record extension aggregate for returned type legal?

[Jean-Pierre Rosen]

Martin Krischik a écrit :

> i.E. "return (0)" might not work since the compiler could to choose
> Integer'(0). However T'(0) will work. You need to be a language lawyer to
> know what works and what does not. Normal people will have to experiment or
> just write down the T' all the time ;-). 
> 
Normal people trust the compiler, and just try it.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Is T an ancestor of T?

[Georg Bauhaus]

Bj�rn Persson <spam-away@nowhere.nil> wrote:

: - AARM 4.3.2(5)

Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17985

-- Georg

Re: Is T an ancestor of T? (was: Re: record extension aggregate for returned type legal?)

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> : Georg Bauhaus wrote:
> : 
> :> LRM 4.3.2, quoted in one compiler's error message, says,
> :> 
> :>   4. The expected type for an extension_aggregate shall be a single
> :>      nonlimited type that is a record extension. If the ancestor_part
> :>      is an expression, it is expected to be of any nonlimited tagged
> :>      type.
> :> 
> :> Do I understand this phrase? The expected type in the return expression
> :> for "function make return T" is the specific tagged type T.
> :> In "return (n => 0)", there is no extension aggregate.
> :> In "return (T with n => 0)", there is an extension aggregate,
> :> the ancestor part being T.
> : 
> : But T in your example is a root class and therefore has no ancestor.
> 
> T seems to have an ancestor, by the following statement form LRM
> 3.4.1(10): "A specific type T2 is defined to be a descendant of a type T1
> if T2 is the same as T1, or if T2 is derived (directly or indirectly) from
> T1."

Wow. Would not have thought that.

> So T can be T's ancestor (that's different from what I was used to
> in the real world ;-).

Well thinking about it: It's probably needed for dispatching calls.
 
> 'class as return type of constructor functions creates a number of
> not-so-nice conversion necessities that I'd like to avoid.

I thought as an example. Not to actually use this constructor pattern. 

> All issues are easily avoided using the constructor child package
> pattern.

If it suits your problem best.
 
> Now is GNAT right,
>  accepting return (T with n => 0), and
>  accepting return (n => 0)
> or is ObjectAda right,
>  rejecting return (T with n => 0), but
>  accepting return (n => 0)
> where T is the expected tagged return type (not classwide)?

I thing Object Ada is right. The aggregate allows you to move up the the
tree. i.E.

type R is tagged private;
type P  is new R with private;
type C is new P with private;

X : C := (R with P_Attribute => ..., C_Attribute => ...)

R is default initialised. P and C are specified. Now, if you move that line
of thought into the other direction you have just defined n twice. Look:

return (T with n => 0)

T is allready default initialised - and then you specify n again.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: record extension aggregate for returned type legal?

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> T' (spoken T kick)
               ^^^^  tick, surely?

Re: record extension aggregate for returned type legal?

[Martin Krischik]

Samuel Tardieu wrote:

>>>>>> "Jean-Pierre" == Jean-Pierre Rosen <rosen@adalog.fr> writes:
> 
> Jean-Pierre> Normal people trust the compiler, and just try it.
> 
> You're kidding, right? I can't believe you encourage people to code
> this way, by changing the code at random until it works.

Well in Ada thats quite Ok. If you do something syntacticly silly the
compiler will shout at you.

We where talking about syntax details here here. The use of "return
(n=> ...)" compared to "return T'(n => ...) ". Which is better which isn't.

And in Ada experiments like this give you an compiler error and not faulty
code like in some other languages ;-) .

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Is T an ancestor of T?

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
>  
> :> 'class as return type of constructor functions creates a number of
> :> not-so-nice conversion necessities that I'd like to avoid.
> : 
> : I thought as an example. Not to actually use this constructor pattern.
> 
> Interestingly, GNAT complains if T is derived from some other
> type Base. For example,
> 
>       function Make return T'Class is
>       begin
>          return T'(T with N => 42);
>       end Make;
> 
> 
>      7.          return T'(T with N => 42);
>                            |
>         >>> expect ancestor type of "T"
> 
> (Same for specific T.)

Well T is not an ancestor of T. T is T itself. You might want try the
example with a tagged type which actually has a parent to see the
difference.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Is T an ancestor of T?

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: Georg Bauhaus wrote:
: 
:> Martin Krischik <krischik@users.sourceforge.net> wrote:
:>  
:> :> 'class as return type of constructor functions creates a number of
:> :> not-so-nice conversion necessities that I'd like to avoid.
:> : 
:> : I thought as an example. Not to actually use this constructor pattern.
:> 
:> Interestingly, GNAT complains if T is derived from some other
:> type Base. For example,
:> 
:>       function Make return T'Class is
:>       begin
:>          return T'(T with N => 42);
:>       end Make;
:> 
:> 
:>      7.          return T'(T with N => 42);
:>                            |
:>         >>> expect ancestor type of "T"
:> 
:> (Same for specific T.)
: 
: Well T is not an ancestor of T.

Not in this example where it is derived from another type, named Base.

: T is T itself. You might want try the
: example with a tagged type which actually has a parent to see the
: difference.

This is exactly what I have been doing, the results above are
for a T that is derived from another type, named Base.
In this GNAT spits out this error message. Otherwise it doesn't.

I still don't know whether or not a type is an ancestor of itself,
given that it is a descendant of itself.


-- Georg

Re: record extension aggregate for returned type legal?

[Georg Bauhaus]

Jean-Pierre Rosen <rosen@adalog.fr> wrote:
 
: Unless I missed something, this thread was about *legality rules*.
: And yes, I find more efficient to ask the compiler rather than dig into 
: the ARM.

In the case of (T with T_Component => value) GNAT's answer
contradicts ObjectAda's answer if T is at the root of a hierarchy of
tagged types.


-- Georg

Re: Is T an ancestor of T?

[Martin Krischik]

Georg Bauhaus wrote:

> I still don't know whether or not a type is an ancestor of itself,
> given that it is a descendant of itself.

Well we discussed it long enough here and if you really want to know then
there is only one option left. A mail to:

ada-comment@ada-auth.org

This is the mail address of the Ada Authority. If they don't know knowbody
does. (Please note: While Ada Authority is open "for question from the
general public" one should allways ask at comp.lang.ada first).

Don't foreget to subscribe as well otherwise you will never see the answer:

listserv@ada-auth.org

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com