* Dueling Compilers
@ 2020-11-25 14:08 Jeffrey R. Carter
2020-11-26 2:19 ` Randy Brukardt
2020-12-02 15:41 ` Shark8
0 siblings, 2 replies; 8+ messages in thread
From: Jeffrey R. Carter @ 2020-11-25 14:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dueling Compilers
2020-11-25 14:08 Dueling Compilers Jeffrey R. Carter
@ 2020-11-26 2:19 ` Randy Brukardt
2020-11-27 7:32 ` Jeffrey R. Carter
2020-12-02 15:41 ` Shark8
1 sibling, 1 reply; 8+ messages in thread
From: Randy Brukardt @ 2020-11-26 2:19 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dueling Compilers
2020-11-26 2:19 ` Randy Brukardt
@ 2020-11-27 7:32 ` Jeffrey R. Carter
2020-11-28 2:35 ` Randy Brukardt
0 siblings, 1 reply; 8+ messages in thread
From: Jeffrey R. Carter @ 2020-11-27 7:32 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dueling Compilers
2020-11-27 7:32 ` Jeffrey R. Carter
@ 2020-11-28 2:35 ` Randy Brukardt
2020-12-17 20:22 ` Jeffrey R. Carter
0 siblings, 1 reply; 8+ messages in thread
From: Randy Brukardt @ 2020-11-28 2:35 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dueling Compilers
2020-11-25 14:08 Dueling Compilers Jeffrey R. Carter
2020-11-26 2:19 ` Randy Brukardt
@ 2020-12-02 15:41 ` Shark8
2020-12-02 16:08 ` AdaMagica
1 sibling, 1 reply; 8+ messages in thread
From: Shark8 @ 2020-12-02 15:41 UTC (permalink / raw)
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".
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dueling Compilers
2020-12-02 15:41 ` Shark8
@ 2020-12-02 16:08 ` AdaMagica
0 siblings, 0 replies; 8+ messages in thread
From: AdaMagica @ 2020-12-02 16:08 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dueling Compilers
2020-11-28 2:35 ` Randy Brukardt
@ 2020-12-17 20:22 ` Jeffrey R. Carter
2020-12-19 2:00 ` Randy Brukardt
0 siblings, 1 reply; 8+ messages in thread
From: Jeffrey R. Carter @ 2020-12-17 20:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Dueling Compilers
2020-12-17 20:22 ` Jeffrey R. Carter
@ 2020-12-19 2:00 ` Randy Brukardt
0 siblings, 0 replies; 8+ messages in thread
From: Randy Brukardt @ 2020-12-19 2:00 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-12-19 2:00 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-25 14:08 Dueling Compilers Jeffrey R. Carter
2020-11-26 2:19 ` Randy Brukardt
2020-11-27 7:32 ` Jeffrey R. Carter
2020-11-28 2:35 ` Randy Brukardt
2020-12-17 20:22 ` Jeffrey R. Carter
2020-12-19 2:00 ` Randy Brukardt
2020-12-02 15:41 ` Shark8
2020-12-02 16:08 ` AdaMagica
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox