Re: Dueling Compilers

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

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