Dueling Compilers

Dueling Compilers

[Jeffrey R. Carter]

Consider the package

with Ada.Containers.Bounded_Doubly_Linked_Lists;

generic
    type E is private;
package Preelaborable is
    package EL is new Ada.Containers.Bounded_Doubly_Linked_Lists
       (Element_Type => E);
end Preelaborable;

Two Ada-12 compilers give different results on this. Compiler G accepts it 
without problem. Compiler O rejects it with the error message

preelaborable.ads: Error: line 6 col82 LRM:10.2.1(11.8/2), If a pragma 
Preelaborable_Initialization has been applied to the generic formal, the 
corresponding actual type must have preelaborable initialization

AFAICT from the ARM, the generic formal Element_Type of 
Ada.Containers.Bounded_Doubly_Linked_Lists does not have pragma 
Preelaborable_Initialization applied to it. However, the type List, which 
probably has [sub]components of Element_Type, does.

Which compiler is correct? What is the intent of the ARM?

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Dueling Compilers

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:rploh9$3kd$1@dont-email.me...
> Consider the package
>
> with Ada.Containers.Bounded_Doubly_Linked_Lists;
>
> generic
>    type E is private;
> package Preelaborable is
>    package EL is new Ada.Containers.Bounded_Doubly_Linked_Lists
>       (Element_Type => E);
> end Preelaborable;
>
> Two Ada-12 compilers give different results on this. Compiler G accepts it 
> without problem. Compiler O rejects it with the error message
>
> preelaborable.ads: Error: line 6 col82 LRM:10.2.1(11.8/2), If a pragma 
> Preelaborable_Initialization has been applied to the generic formal, the 
> corresponding actual type must have preelaborable initialization
>
> AFAICT from the ARM, the generic formal Element_Type of 
> Ada.Containers.Bounded_Doubly_Linked_Lists does not have pragma 
> Preelaborable_Initialization applied to it. However, the type List, which 
> probably has [sub]components of Element_Type, does.
>
> Which compiler is correct? What is the intent of the ARM?

I'd say both compilers are wrong, in that the RM clearly has a bug here and 
one of the implementers should have complained about it to the ARG long ago. 
:-) I'd suggest you post this question to Ada-Comment so that it gets on the 
ARG's radar.

(I'll call Preelaborable_Initialization "PI" in the following for my sanity. 
:-)

It's clear from 10.2.1 that a type with pragma PI which has components of a 
generic formal type has to have components that have a type with PI. It 
isn't possible to initialize such components without a function call, so the 
other possibility does not exist. The Bounded containers are designed such 
that there are components of the element type (more accurately, a component 
of an array of the element type). In order for there to be such a component, 
the formal type must have PI. Ergo, any body for a bounded container written 
in Ada is necessarily illegal. This is a problem that someone should have 
brought up at the ARG.

Since it is not required to write language-defined package bodies in Ada, 
one could imagine that both compilers are correct in the sense that they are 
using some non-Ada language to implement the containers. But that is is a 
fiction in the case of the containers (every implementation I know of is in 
Ada), and in any case, we intended the containers to be implementable in 
Ada. If they are not, that is a bug.

I don't know what the fix ought to be: adding PI to the formal private type 
would work, but it would reduce the usabibility of the containers in 
non-preelaborated contexts. Similarly, removing the PI from the container 
would work, but would reduce the usability of the containers in 
preelaborated contexts. Both seem pretty bad.

I'd be in favor of removing PI and Preelaboration in general from the 
language (it serves no purpose other than to encourage implementers to make 
optimizations that they should make anyway - the other intentions don't work 
or are better handled with other mechanisms), but I doubt that I'd get any 
support for that.

So this will have to be an ARG question -- I can't answer it definitively.

                                 Randy.

P.S. If you post this question to Ada-Comment, do me a favor and post this 
analysis along with it. That will save me having to reproduce it later.

Re: Dueling Compilers

[Jeffrey R. Carter]

On 11/26/20 3:19 AM, Randy Brukardt wrote:
> 
> It's clear from 10.2.1 that a type with pragma PI which has components of a
> generic formal type has to have components that have a type with PI. It
> isn't possible to initialize such components without a function call, so the
> other possibility does not exist. The Bounded containers are designed such
> that there are components of the element type (more accurately, a component
> of an array of the element type). In order for there to be such a component,
> the formal type must have PI. Ergo, any body for a bounded container written
> in Ada is necessarily illegal. This is a problem that someone should have
> brought up at the ARG.

I think both compilers are doing macro-expansion of generics, so a generic is 
only really compiled when it is instantiated. Presumably any test code used 
actual parameters that the compiler could tell were PI, so they compiled OK.

> I don't know what the fix ought to be: adding PI to the formal private type
> would work, but it would reduce the usabibility of the containers in
> non-preelaborated contexts. Similarly, removing the PI from the container
> would work, but would reduce the usability of the containers in
> preelaborated contexts. Both seem pretty bad.

I presumed that leaving PI on the container was an oversight.

> So this will have to be an ARG question -- I can't answer it definitively.

OK, I'll research the format of submissions to Ada-Comment and send it in.

> P.S. If you post this question to Ada-Comment, do me a favor and post this
> analysis along with it. That will save me having to reproduce it later.

I would have done that anyway. Thanks for confirming my suspicion that something 
is rotten in Denmark.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Dueling Compilers

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:rpqa2q$hau$1@dont-email.me...
> On 11/26/20 3:19 AM, Randy Brukardt wrote:
>>
>> It's clear from 10.2.1 that a type with pragma PI which has components of 
>> a
>> generic formal type has to have components that have a type with PI. It
>> isn't possible to initialize such components without a function call, so 
>> the
>> other possibility does not exist. The Bounded containers are designed 
>> such
>> that there are components of the element type (more accurately, a 
>> component
>> of an array of the element type). In order for there to be such a 
>> component,
>> the formal type must have PI. Ergo, any body for a bounded container 
>> written
>> in Ada is necessarily illegal. This is a problem that someone should have
>> brought up at the ARG.
>
> I think both compilers are doing macro-expansion of generics, so a generic 
> is only really compiled when it is instantiated. Presumably any test code 
> used actual parameters that the compiler could tell were PI, so they 
> compiled OK.

That would be an incorrect implementation of generic units in Ada. One has 
to enforce the language rules only knowing the guarenteed properties of the 
formal types (knowing nothing about the actual). There is a later legality 
recheck in the specification of an instance, but that would be irrelevant in 
this case since the generic unit already is illegal.

>> I don't know what the fix ought to be: adding PI to the formal private 
>> type
>> would work, but it would reduce the usabibility of the containers in
>> non-preelaborated contexts. Similarly, removing the PI from the container
>> would work, but would reduce the usability of the containers in
>> preelaborated contexts. Both seem pretty bad.
>
> I presumed that leaving PI on the container was an oversight.

It definitely is intended, if the unit is Preelaborated, we definitely want 
any private types in it to be PI (lest they be unable to be used in 
Preelaborated units.


>> So this will have to be an ARG question -- I can't answer it 
>> definitively.
>
> OK, I'll research the format of submissions to Ada-Comment and send it in.
>
>> P.S. If you post this question to Ada-Comment, do me a favor and post 
>> this
>> analysis along with it. That will save me having to reproduce it later.
>
> I would have done that anyway. Thanks for confirming my suspicion that 
> something is rotten in Denmark.

Thanks for sending this along.

                     Randy.

Re: Dueling Compilers

[Jeffrey R. Carter]

On 11/28/20 3:35 AM, Randy Brukardt wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
> news:rpqa2q$hau$1@dont-email.me...
>> On 11/26/20 3:19 AM, Randy Brukardt wrote:
> 
>>> So this will have to be an ARG question -- I can't answer it
>>> definitively.
>>
>> OK, I'll research the format of submissions to Ada-Comment and send it in.

For those who are interested, this became AI12-0409-1, approved 2020-12-09

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0409-1.txt

-- 
Jeff Carter
"[I]f you ask, 'Why does Ada do/have this?',
the answer often makes you a better programmer."
Chad R. Meiners
177

Re: Dueling Compilers

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:rrgemq$bbh$1@dont-email.me...
> On 11/28/20 3:35 AM, Randy Brukardt wrote:
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
>> news:rpqa2q$hau$1@dont-email.me...
>>> On 11/26/20 3:19 AM, Randy Brukardt wrote:
>>
>>>> So this will have to be an ARG question -- I can't answer it
>>>> definitively.
>>>
>>> OK, I'll research the format of submissions to Ada-Comment and send it 
>>> in.
>
> For those who are interested, this became AI12-0409-1, approved 2020-12-09
>
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0409-1.txt

For what it's worth, that approval included moving most of AI12-0399-1 to 
this AI, and making this AI a Binding Interpretation so it applies to Ada 
2012 as well. We agreed not to require in the ACATS that implementations 
define the Preelaborable_Initialization aspect (if they have some other 
existing way to do this, that's fine by us for Ada 2012), but they can if 
they want. We will insist that bounded containers have P_I if the element 
type has P_I, and that they can be instantiated if the element type does not 
have P_I.

                           Randy.

Re: Dueling Compilers

[Shark8]

On Wednesday, November 25, 2020 at 7:08:43 AM UTC-7, Jeffrey R. Carter wrote:
> Consider the package 
> 
> with Ada.Containers.Bounded_Doubly_Linked_Lists; 
> 
> generic 
> type E is private; 
> package Preelaborable is 
> package EL is new Ada.Containers.Bounded_Doubly_Linked_Lists 
> (Element_Type => E); 
> end Preelaborable; 
> 
> Two Ada-12 compilers give different results on this. Compiler G accepts it 
> without problem. Compiler O rejects it with the error message 
> 
> preelaborable.ads: Error: line 6 col82 LRM:10.2.1(11.8/2), If a pragma 
> Preelaborable_Initialization has been applied to the generic formal, the 
> corresponding actual type must have preelaborable initialization 
> 
> AFAICT from the ARM, the generic formal Element_Type of 
> Ada.Containers.Bounded_Doubly_Linked_Lists does not have pragma 
> Preelaborable_Initialization applied to it. However, the type List, which 
> probably has [sub]components of Element_Type, does. 
> 
> Which compiler is correct? What is the intent of the ARM? 

Acceptance is the correct evaluation.
"package NAME is" is quite clearly the proper construction, there is no aspect here, and so aspect "preelaborable" is *NOT* indicated, EVEN IF the given NAME is "preelaborable".

Re: Dueling Compilers

[AdaMagica]

Shark8 schrieb am Mittwoch, 2. Dezember 2020 um 16:41:51 UTC+1:
> > Which compiler is correct? What is the intent of the ARM?
> Acceptance is the correct evaluation. 
> "package NAME is" is quite clearly the proper construction, there is no aspect here, and so aspect "preelaborable"
> is *NOT* indicated, EVEN IF the given NAME is "preelaborable".

You misunderstood the problem.