Ada 2005 box (<>) rules in default values

Ada 2005 box (<>) rules in default values

[Alex R. Mosteo]

Hi all,

I have a doubt with the box operator as newly introduced in Ada 2005 to 
allow in place initialization of limited types. I'm not sure of all the 
details so anything I say can be wrong; if so please correct me.

My understanding is that you use the <> value to denote the default 
value of a field in, for example a (limited or not) record:

Blah : constant Thing :=
  	(First_Component  => 3,
          Second_Component => 4,
          others => <>);

This actually compiles in GNAT GAP/GPL, but there's a thing happening 
that I don't know if it's that it isn't still completely implemented in 
Gnat, or is the expected behavior.

Say, for example, that Thing above is declared like:

type Thing is record
    First_Component  : Integer;
    Second_Component : Integer;
    Third_Component  : Integer := 5;
end record;

I'm finding that if I use the box as in the first example above, the 
third component will not receive its default value from the type 
definition (5), but will be uninitialized. I've noticed this because 
initializing types like this:

type Other_Thing is record
     X : Integer;
     L : List;
     -- From some instantiation of Ada.Containers.Doubly_Linked_Lists
end record;

with

Y : Other_Thing := (X => 5, others => <>);

This initialization more often than not will have an invalid list (i.e. 
not an empty list, but one with improper values that fails when used).

I've read the Aggregates Issues in the "Gnat and Ada 2005" document, and 
there the <> initializer is mentioned primarily in relation to limited 
types. From that document I read:

"The box notation ("<>") is now used to denote the default 
initialization for a component of an aggregate, that is to say an 
invocation of the initialization procedure for the component type."

And

"Note that the "others => <>" notation is allowed even when the 
associated components are not of the same type. Its meaning is as 
follows: if a component has a default expression in the record type, the 
expression is used; otherwise, the normal default initialization for its 
type is used."

 From these paragraphs I understand that Gnat is not implementing 
correctly that feature for the moment. So I ask if you knowledgeable lot 
agree with my impression. (A pointer to the amendment dealing with this 
will also be welcome).

Re: Ada 2005 box (<>) rules in default values

[Martin Dowie]

Alex R. Mosteo wrote:
> Hi all,
[snip]
> with this will also be welcome).

Your understanding seems to be what John Barnes describes in his paper at
"http://www.gnat.com/ada_2005.php#":

"The main change is that the box notation <> is now permitted as the value
in a named aggregate. The meaning is that the component of the aggregate
takes the default value if there is one.
So if we have a record type such as

type RT is record A: Integer := 7; B: access Integer; C: Float; end record;

then if we write

X: RT := (A => <>, B => <>, C => <>);

then X.A has the value 7, X.B has the value null and X.C is undefined. So
the default value is that given in the record type declaration or, in the
absence of such an explicit default value, it is the default value for the
type. If there is no explicit default value and the type does not have one
either then the value is simply undefined as usual.

The above example could be abbreviated to

X: RT := (others => <>); "

Re: Ada 2005 box (<>) rules in default values

[ME]

When will a Ada 2005 compiler become publicly available i.e. gnat 16.0P?
"Alex R. Mosteo" <devnull@mailinator.com> wrote in message 
news:43CCAB76.6050907@mailinator.com...
> Hi all,
>
> I have a doubt with the box operator as newly introduced in Ada 2005 to 
> allow in place initialization of limited types. I'm not sure of all the 
> details so anything I say can be wrong; if so please correct me.
>
> My understanding is that you use the <> value to denote the default value 
> of a field in, for example a (limited or not) record:
>
> Blah : constant Thing :=
>  (First_Component  => 3,
>          Second_Component => 4,
>          others => <>);
>
> This actually compiles in GNAT GAP/GPL, but there's a thing happening that 
> I don't know if it's that it isn't still completely implemented in Gnat, 
> or is the expected behavior.
>
> Say, for example, that Thing above is declared like:
>
> type Thing is record
>    First_Component  : Integer;
>    Second_Component : Integer;
>    Third_Component  : Integer := 5;
> end record;
>
> I'm finding that if I use the box as in the first example above, the third 
> component will not receive its default value from the type definition (5), 
> but will be uninitialized. I've noticed this because initializing types 
> like this:
>
> type Other_Thing is record
>     X : Integer;
>     L : List;
>     -- From some instantiation of Ada.Containers.Doubly_Linked_Lists
> end record;
>
> with
>
> Y : Other_Thing := (X => 5, others => <>);
>
> This initialization more often than not will have an invalid list (i.e. 
> not an empty list, but one with improper values that fails when used).
>
> I've read the Aggregates Issues in the "Gnat and Ada 2005" document, and 
> there the <> initializer is mentioned primarily in relation to limited 
> types. From that document I read:
>
> "The box notation ("<>") is now used to denote the default initialization 
> for a component of an aggregate, that is to say an invocation of the 
> initialization procedure for the component type."
>
> And
>
> "Note that the "others => <>" notation is allowed even when the associated 
> components are not of the same type. Its meaning is as follows: if a 
> component has a default expression in the record type, the expression is 
> used; otherwise, the normal default initialization for its type is used."
>
> From these paragraphs I understand that Gnat is not implementing correctly 
> that feature for the moment. So I ask if you knowledgeable lot agree with 
> my impression. (A pointer to the amendment dealing with this will also be 
> welcome). 

Re: Ada 2005 box (<>) rules in default values

[Pascal Obry]

ME a �crit :
> When will a Ada 2005 compiler become publicly available i.e. gnat 16.0P?

AFAIK there is no such beast yet! Compilers are being developed to
support the new Ada 2005 features but no one is still 100% complete.

You can try GNAT 2005 GPL Edition (http://libre.adacore.com) which has
some Ada 2005 features.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada 2005 box (<>) rules in default values

[Randy Brukardt]

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

"Pascal Obry" <pascal@obry.net> wrote in message
news:43CD2724.3090204@obry.net...
> ME a �crit :
> > When will a Ada 2005 compiler become publicly available i.e. gnat 16.0P?
>
> AFAIK there is no such beast yet! Compilers are being developed to
> support the new Ada 2005 features but no one is still 100% complete.

Nor could there be, as the Amendment isn't finished yet; we're in the
(hopefully) last round of formal comments. There probably will be a few
(small) changes in syntax and semantics from those comments, so even if a
compiler fully implemented draft 15, it would still not implement (exactly)
the final language.

(Of course, that is primarily of academic interest; most uses wouldn't run
into any of the changes.)

                   Randy Brukardt, Editor, 8652 AMD.1

Re: Ada 2005 box (<>) rules in default values

[Randy Brukardt]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:43CCAB76.6050907@mailinator.com...
...
>  From these paragraphs I understand that Gnat is not implementing
> correctly that feature for the moment. So I ask if you knowledgeable lot
> agree with my impression. (A pointer to the amendment dealing with this
> will also be welcome).

I agree; the default value should be used here. The reference you want is:

http://www.adaic.com/standards/05rm/html/RM-4-3-1.html

for record aggregates, and

http://www.adaic.com/standards/05rm/html/RM-4-3-3.html

for array aggregates. (Keep in mind that this "consolidated" RM is an
unofficial construction, and if it has any differences with the Amendment
document, the Amendment has the correct language. But the Amendment is
pretty hard to make sense of, as it is just a list of changed paragraphs.
Thank Ada Europe for sponsoring the development of the "consolidated" RM.)

                        Randy Brukardt

Re: Ada 2005 box (<>) rules in default values

[Björn Persson]

Alex R. Mosteo wrote:
> My understanding is that you use the <> value to denote the default 
> value of a field in, for example a (limited or not) record:
> 
> Blah : constant Thing :=
>      (First_Component  => 3,
>          Second_Component => 4,
>          others => <>);
> 
> This actually compiles in GNAT GAP/GPL, but there's a thing happening 
> that I don't know if it's that it isn't still completely implemented in 
> Gnat, or is the expected behavior.
> 
> Say, for example, that Thing above is declared like:
> 
> type Thing is record
>    First_Component  : Integer;
>    Second_Component : Integer;
>    Third_Component  : Integer := 5;
> end record;
> 
> I'm finding that if I use the box as in the first example above, the 
> third component will not receive its default value from the type 
> definition (5), but will be uninitialized.

This appears to be corrected in GCC 4.0.2 on Gnu/Linux, as it passes the 
test below. Alex, could you please compile this program and verify that 
it triggers the bug in your environment? If not, you might want to post 
a compilable test case that does display the error.

with Ada.Text_IO; use Ada.Text_IO;

procedure Uninitialized_Field_2005 is

    type Thing is record
       First_Component  : Integer;
       Second_Component : Integer;
       Third_Component  : Integer := 5;
    end record;

    Blah : constant Thing :=
      (First_Component  => 3,
       Second_Component => 4,
       others => <>);

begin
    if Blah.Third_Component = 5 then
       Put("Passed");
    else
       Put("Failed");
    end if;
    Put_Line(": Blah.Third_Component = " &
             Integer'Image(Blah.Third_Component));
end Uninitialized_Field_2005;

$ gnatmake -gnat05 uninitialized_field_2005.adb
gcc -c -gnat05 uninitialized_field_2005.adb
gnatbind -x uninitialized_field_2005.ali
gnatlink uninitialized_field_2005.ali
$ ./uninitialized_field_2005
Passed: Blah.Third_Component =  5

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada 2005 box (<>) rules in default values

[Alex R. Mosteo]

Bj�rn Persson wrote:

> This appears to be corrected in GCC 4.0.2 on Gnu/Linux, as it passes the 
> test below. Alex, could you please compile this program and verify that 
> it triggers the bug in your environment? If not, you might want to post 
> a compilable test case that does display the error.

I'm sorry the example I wrote was made up on the way. Upon reflexion, I 
think I always saw this problem in relation with Controlled types. 
Here's an example which fails with my current GPL:

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Finalization; use Ada.Finalization;

procedure Bug2005 is

    type Thing is new Controlled with record
       First_Component  : Integer;
       Second_Component : Integer;
       Third_Component  : Integer;
    end record;

    procedure Initialize (This : in out Thing) is
    begin
       This.Third_Component := 5;
    end Initialize;

    type Superthing is record
       Innerthing : Thing;
    end record;

    Blah :          Superthing := (others => <>);
    Bleh :          Superthing;
    Blih : constant Superthing := (others => <>);
    Bloh : constant Superthing := (Innerthing => <>);
    Bluh : constant Superthing := (Innerthing =>
      (Controlled with others => <>));

begin
    Put_Line(": Blah.Innerthing.Third_Component = " &
      Integer'Image(Blah.Innerthing.Third_Component));
    Put_Line(": Bleh.Innerthing.Third_Component = " &
      Integer'Image(Bleh.Innerthing.Third_Component));
    Put_Line(": Blih.Innerthing.Third_Component = " &
      Integer'Image(Blih.Innerthing.Third_Component));
    Put_Line(": Bloh.Innerthing.Third_Component = " &
      Integer'Image(Bloh.Innerthing.Third_Component));
    Put_Line(": Bluh.Innerthing.Third_Component = " &
      Integer'Image(Bluh.Innerthing.Third_Component));
end Bug2005;

Execution:

$ gnatmake -gnat05 bug2005.adb
gcc -c -gnat05 bug2005.adb
gnatbind -x bug2005.ali
gnatlink bug2005.ali

$ ./bug2005
: Blah.Innerthing.Third_Component = -1208571208
: Bleh.Innerthing.Third_Component =  5
: Blih.Innerthing.Third_Component = -1208516512
: Bloh.Innerthing.Third_Component = -1208569267
: Bluh.Innerthing.Third_Component =  0

I think this is perhaps a different problem than the one I asked 
originally. But there's two things that make me think this is still an 
error, or at least a dangerous trap in the new Ada. In the link kindly 
provided by Mr. Brukardt I read (emphasis mine):

"if the component_declaration has a default_expression, that 
default_expression defines the value for the associated component(s); 
otherwise, the associated component(s) are initialized by default as for 
a *stand-alone object* of the component subtype (see 3.3.1)."

In a stand-alone object, as Bleh shows, the field would receive 
initialization.

Furthermore, if here Thing were a private type coming from elsewhere, I 
reasonably would expect that its default value were correct (I could in 
fact ignore that it is Controlled if this is declared in the private 
part of some package).

Indeed, this second case is the one that was biting me, with objects 
from the new standard container library.

Now I read in 7.6(10/2) (ARM05):

"During the elaboration or evaluation of a construct that causes an 
object to be initialized by default, for every controlled subcomponent 
of the object that is not assigned an initial value (as defined in 
3.3.1), Initialize is called on that subcomponent. Similarly, if the 
object that is initialized by default as a whole is controlled, 
Initialize is called on the object."

This justifies Bluh being wrong (and I agree, we are initializing 
explicitely the fields to default values in the type declaration, so 
Initialize doesn't get called. This comes from Ada95 already).

In the other cases, the controlled object is receiving default 
initialization as a whole, so I guess Initialize should be called? This 
certainly would take care of the "trap" I'm seeing here. The trap being 
that the implementer of a private controlled type should assure that a 
default object without suffering Initialization should be correct.

Your thoughts?

Re: Ada 2005 box (<>) rules in default values

[Jean-Pierre Rosen]

Alex R. Mosteo a �crit :
> Bj�rn Persson wrote:
> 
>> This appears to be corrected in GCC 4.0.2 on Gnu/Linux, as it passes 
>> the test below. Alex, could you please compile this program and verify 
>> that it triggers the bug in your environment? If not, you might want 
>> to post a compilable test case that does display the error.
> 
> 
> I'm sorry the example I wrote was made up on the way. Upon reflexion, I 
> think I always saw this problem in relation with Controlled types. 
> Here's an example which fails with my current GPL:
> 
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Finalization; use Ada.Finalization;
> 
> procedure Bug2005 is
> 
>    type Thing is new Controlled with record
>       First_Component  : Integer;
>       Second_Component : Integer;
>       Third_Component  : Integer;
>    end record;
> 
>    procedure Initialize (This : in out Thing) is
>    begin
>       This.Third_Component := 5;
>    end Initialize;
> 
>    type Superthing is record
>       Innerthing : Thing;
>    end record;
> 
>    Blah :          Superthing := (others => <>);
>    Bleh :          Superthing;
>    Blih : constant Superthing := (others => <>);
>    Bloh : constant Superthing := (Innerthing => <>);
>    Bluh : constant Superthing := (Innerthing =>
>      (Controlled with others => <>));
> 
> begin
>    Put_Line(": Blah.Innerthing.Third_Component = " &
>      Integer'Image(Blah.Innerthing.Third_Component));
>    Put_Line(": Bleh.Innerthing.Third_Component = " &
>      Integer'Image(Bleh.Innerthing.Third_Component));
>    Put_Line(": Blih.Innerthing.Third_Component = " &
>      Integer'Image(Blih.Innerthing.Third_Component));
>    Put_Line(": Bloh.Innerthing.Third_Component = " &
>      Integer'Image(Bloh.Innerthing.Third_Component));
>    Put_Line(": Bluh.Innerthing.Third_Component = " &
>      Integer'Image(Bluh.Innerthing.Third_Component));
> end Bug2005;
> 
That's totally different. Third_Component is not default-initialized, it 
is initialized by the Initialize procedure. And Initialize is /not/ 
called on aggregates.

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

Re: Ada 2005 box (<>) rules in default values

[Alex R. Mosteo]

Jean-Pierre Rosen wrote:
> Alex R. Mosteo a �crit :
> 
>> Bj�rn Persson wrote:
>>
>>> This appears to be corrected in GCC 4.0.2 on Gnu/Linux, as it passes 
>>> the test below. Alex, could you please compile this program and 
>>> verify that it triggers the bug in your environment? If not, you 
>>> might want to post a compilable test case that does display the error.
>>
>>
>>
>> I'm sorry the example I wrote was made up on the way. Upon reflexion, 
>> I think I always saw this problem in relation with Controlled types. 
>> Here's an example which fails with my current GPL:
>>
>> with Ada.Text_IO; use Ada.Text_IO;
>> with Ada.Finalization; use Ada.Finalization;
>>
>> procedure Bug2005 is
>>
>>    type Thing is new Controlled with record
>>       First_Component  : Integer;
>>       Second_Component : Integer;
>>       Third_Component  : Integer;
>>    end record;
>>
>>    procedure Initialize (This : in out Thing) is
>>    begin
>>       This.Third_Component := 5;
>>    end Initialize;
>>
>>    type Superthing is record
>>       Innerthing : Thing;
>>    end record;
>>
>>    Blah :          Superthing := (others => <>);
>>    Bleh :          Superthing;
>>    Blih : constant Superthing := (others => <>);
>>    Bloh : constant Superthing := (Innerthing => <>);
>>    Bluh : constant Superthing := (Innerthing =>
>>      (Controlled with others => <>));
>>
>> begin
>>    Put_Line(": Blah.Innerthing.Third_Component = " &
>>      Integer'Image(Blah.Innerthing.Third_Component));
>>    Put_Line(": Bleh.Innerthing.Third_Component = " &
>>      Integer'Image(Bleh.Innerthing.Third_Component));
>>    Put_Line(": Blih.Innerthing.Third_Component = " &
>>      Integer'Image(Blih.Innerthing.Third_Component));
>>    Put_Line(": Bloh.Innerthing.Third_Component = " &
>>      Integer'Image(Bloh.Innerthing.Third_Component));
>>    Put_Line(": Bluh.Innerthing.Third_Component = " &
>>      Integer'Image(Bluh.Innerthing.Third_Component));
>> end Bug2005;
>>
> That's totally different. Third_Component is not default-initialized, it 
> is initialized by the Initialize procedure. And Initialize is /not/ 
> called on aggregates.

Yes, I said something about it in the part not quoted. But what about 
the other RM paragraphs I've quoted? Am I misinterpreting them? Really 
exists the problem I'm suggesting?

Re: Ada 2005 box (<>) rules in default values

[Randy Brukardt]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:43CE65E8.1040307@mailinator.com...
> Jean-Pierre Rosen wrote:
> >> I'm sorry the example I wrote was made up on the way. Upon reflexion,
> >> I think I always saw this problem in relation with Controlled types.
> >> Here's an example which fails with my current GPL:
> >>
> >> with Ada.Text_IO; use Ada.Text_IO;
> >> with Ada.Finalization; use Ada.Finalization;
> >>
> >> procedure Bug2005 is
> >>
> >>    type Thing is new Controlled with record
> >>       First_Component  : Integer;
> >>       Second_Component : Integer;
> >>       Third_Component  : Integer;
> >>    end record;
> >>
> >>    procedure Initialize (This : in out Thing) is
> >>    begin
> >>       This.Third_Component := 5;
> >>    end Initialize;
> >>
> >>    type Superthing is record
> >>       Innerthing : Thing;
> >>    end record;
> >>
> >>    Blah :          Superthing := (others => <>);
> >>    Bleh :          Superthing;
> >>    Blih : constant Superthing := (others => <>);
> >>    Bloh : constant Superthing := (Innerthing => <>);
> >>    Bluh : constant Superthing := (Innerthing =>
> >>      (Controlled with others => <>));
...
> > That's totally different. Third_Component is not default-initialized, it
> > is initialized by the Initialize procedure. And Initialize is /not/
> > called on aggregates.
>
> Yes, I said something about it in the part not quoted. But what about
> the other RM paragraphs I've quoted? Am I misinterpreting them? Really
> exists the problem I'm suggesting?

No, but perhaps there is something wrong with your interpretation of them.

As J-P said, Initialize is never called for an aggregate. But it should be
called for <>; 7.6(10) was reworded to ensure that happens. (BTW, the
wording "initialized by default" is a defined term in Ada 200Y; it means to
follow the rules in 3.3.1. We found that the rules for this were duplicated
all over the standard, and they were not quite right in many places; clearly
these need to be the same everywhere, especially the bizarre stuff about
ordering.)

So, it's necessary to look at what "others" represents here. As you point
out:
    Blih : Superthing := (others => <>);
and
    Bloh : Superthing := (Innerthing => <>);
are the same. Clearly, Initialze should be called in these cases (the
aggregate is on Superthing, not Thing).

If you had:
    Blop : Thing := (others => <>);
then Initialize would not be called. But that's not the case here.

As you pointed out, this certainly ought to work properly when Thing is
private; the end user shouldn't need to know or care how the type is
implemented. And certainly using <> somewhere shouldn't break abstractions -
nothing should be able to break abstractions (presuming the abstractions
themselves aren't broken).

So I conclude the compiler is wrong; I'd suggest sending a bug report.

                             Randy.

Re: Ada 2005 box (<>) rules in default values

[Alex R. Mosteo]

Randy Brukardt wrote:

> So I conclude the compiler is wrong; I'd suggest sending a bug report.

Thanks Randy, I feel relieved. I'll file the bug tomorrow if nobody else 
has anything to say that contradicts this conclusion, and also thanks to 
the other people who has been following the thread.

Re: Ada 2005 box (<>) rules in default values

[Björn Persson]

Alex R. Mosteo wrote:
> Here's an example which fails with my current GPL:

OK, I can't test that one in GCC 4.0.2*, but with GCC 4.1.0 20051112 I 
get the same result as you:

: Blah.Innerthing.Third_Component = -1080341224
: Bleh.Innerthing.Third_Component =  5
: Blih.Innerthing.Third_Component =  494580228
: Bloh.Innerthing.Third_Component =  0
: Bluh.Innerthing.Third_Component =  3167952


* GCC 4.0.2 requires that the controlled type be declared at the library 
level. That's obviously taken care of.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu