Version 1.5 of ai05s/ai05-0163-1.txt

• At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with "declaration", "statement", "clause", or "alternative", or one of the syntactic categories variant or exception_handler; but not in place of such a construct. Also at any place where a compilation_unit would be allowed.

• At any place where the syntax rules allow a construct defined by a syntactic category whose name ends with "declaration", "item", "statement", "clause", or "alternative", or one of the syntactic categories variant or exception_handler; but not in place of such a construct if the construct is required, or is part of a list that is required to have at least one such construct.

• In place of a statement in a sequence_of_statements.

• At any place where a compilation_unit is allowed.

From: Robert Dewar
Sent: Saturday, June 27, 2009  6:50 PM

[Split from a thread found in AI05-0135-1 - Editor]

> As a pragma, I agree with Brad, simply because this pragma would
> violate "good taste in pragmas". We recently added some discussion to
> the AARM to explain what good taste is (see 2.8(1.a/3) or AI05-0100-1
> if you don't have the draft 7 AARM handy). In particular, removing a
> pragma from a legal program should not make the program illegal

This really isn't vaguely true for existing pragmas!

For example, removing pragma Pack often makes a program illegal.

Removing a pragma Import almost certainly makes a program illegal.

Removing a pragma Convention can easily make a program illegal

Removing a pragma Pure, Preelaborate, or any of the other categorization pragmas
can make a program illegal.

Removing a pragma Elaborate can make a program illegal same of course with
Elaborate_All and Elaborate_Body.

Removing a pragma Atomic or Volatile can make a program illegal.

There aren't that many pragmas defined in the RM, and as we see many of them are
in "bad taste" :-)

Once we have done such a bad job of following our own bad taste rules, I can
hardly get upset at adding one more.

And since the language is so free in adding these bad taste pragmas (note that
most of these were added in Ada 95), I see no reason for implementors to feel
bound to stricter standards.

I guess to me, it is MUCH worse when removing a pragma can cause the progam to
become erroneous, or malfunction in mysterious ways. Ilegality is a nice outcome
of improperly removing a pragma compared to these alternatives!

Notionally if an implementation has only "good taste" pragmas, then you can
remove them all or ignore them all, and the program is still legal. But so what?
Pragmas are not there for amusement purposes, almost certainly they are
important to the correct functioning of the program. If you have a GNAT program
that uses pragma Weak_External, sure you can remove it and the compiler will
consider the program legal, but good luck at link time :-) And if you remove a
pragma Wide_Character_Encoding, it will be quite surprising if you can still
compile your source :-)

****************************************************************

From: Brad Moore
Sent: Sunday, June 28, 2009  1:04 AM

> Once we have done such a bad job of following our own bad taste rules,
> I can hardly get upset at adding one more.

Good point! Perhaps we should change the labels on the scale in the AARM from
"good taste" to "slightly-off taste", where good taste is the ideal that we'd
like to strive towards, but seldom achieve in practice. :-) Pragma Page comes to
mind as one of the "good taste" pragmas. It tastes good because it doesn't do
much. I do think however, that the level of taste drops below "slightly-off"
when removing a pragma does not cause any issues locally for the unit that
contains the pragma, but causes illegality in other units that may be somewhere
far away, possibly in other applications. Pragma Import does not fall into this
category, but pragmas such as Pure and Elaborate do - so we would not be
breaking new ground in depths of bad taste. :-)

****************************************************************

From: Robert Dewar
Sent: Sunday, June 28, 2009  1:46 AM

Note that in my list of bad taste examples, the "somewhere far away" effect can
happen for all these examples except pragma Import, that's the only one where
the illegality is bound to be local.

****************************************************************

From: Tucker Taft
Sent: Sunday, June 28, 2009  8:54 AM

I agree with Randy that we should avoid using pragmas that make things legal
that would otherwise be illegal (ignoring representational issues). Yes we have
some such pragmas now, but there are few, and it was back in Ada 9X that we
established this principle and did our best to stick with it. I don't like to
see us slipping backwards now.

****************************************************************

From: Robert Dewar
Sent: Sunday, June 28, 2009  9:18 AM

> I agree with Randy that we should avoid using pragmas that make things
> legal that would otherwise be illegal (ignoring representational
> issues).
> Yes we have some such pragmas now, but there are few, and it was back
> in Ada 9X that we established this principle and did our best to stick
> with it.

I don't buy that rewriting of history. Look at my list of problematic pragmas,
nearly all of them were introduced in Ada 95 (I think all, given that we got rid
of pragma interface, and you are somewhat arbitrarily excluding representation
pragmas).

> I don't like to see us slipping backwards now.

We never went forwards on this issue!

****************************************************************

From: Tucker Taft
Sent: Sunday, June 28, 2009  10:30 AM

I'm not rewriting history by saying that we established the principle.
Actually, Bob Duff was the first to voice the principle in my memory, and it was
pretty early in the 9X process when we were debating things like passive tasks,
etc.

You are pointing out that we failed miserably on following our principle, and
that is true in the area of conventions, where there are a number of cases that
require exact matching of conventions, and that can only be done using pragmas.

But I really see representational
issues as a separate domain from
non-representation-related legality rules.
Perhaps that is my own quirk...

****************************************************************

From: Bob Duff
Sent: Sunday, June 28, 2009  11:22 AM

> That's not really true for language-defined pragmas. Pragma Import is
> a pragma in bad taste, but it's pretty much impossible to avoid using
> it (as much as I'd like to). Imagine trying to write Claw without
> using pragma Import! :-)

I do not agree that pragma Import is in bad taste.  And if I wanted to add some
functionality similar to pragma Import, but slightly different in some way, an
implementation-defined pragma with similar properties would make sense to me.

If you erase all the pragmas from your program, your program is likely to break.
This is true for some language-defined pragmas (e.g. Import, Elaborate_All), and
for some impl-def pragmas (e.g. GNAT's pragmas Abort_Defer, Ada_2005,
Common_Object).  The idea that the broken program should remain legal is utterly
pointless.

AI05-0100-1 was supposed to fix some confusing wording about pragma placement
syntax.  Adding the AARM annotation as part of that AI was just plain wrong, and
if I'd been paying attention, I would have objected.  Luckily, AARM annotations
are non-normative, and all implementers will ignore this one -- no sane compiler
writer is going remove existing pragmas that violate this "taste" rule,
including the compiler writer who wrote that AI (which I'm guessing is our good
friend Tucker Taft, based on the style in which the !discussion is written ;-)).

****************************************************************

From: Robert Dewar
Sent: Sunday, June 28, 2009  11:20 AM

> I'm not rewriting history by saying that we established the principle.
> Actually, Bob Duff was the first to voice the principle in my memory,
> and it was pretty early in the 9X process when we were debating things
> like passive tasks, etc.
>
> You are pointing out that we failed miserably on following our
> principle, and that is true in the area of conventions, where there
> are a number of cases that require exact matching of conventions, and
> that can only be done using pragmas.
>
> But I really see representational
> issues as a separate domain from
> non-representation-related legality rules.
> Perhaps that is my own quirk...

But what about preelaborate, pure etc. These are not representation issues, and
removing a pragma here is particularly bad since it causes non-local
illegalities. Something that could not happen in Ada 83 pragmas except for
representation issues.

When I say it's bad, I mean bad by this arbitrary good taste rule. I don't think
it's a good rule anyway, and I see no good motivation for it :-)

All I am saying is that we should not let future language design be
over-influenced by this dubious principle which we have never followed in the
past :-)

****************************************************************

From: Bob Duff
Sent: Sunday, June 28, 2009  11:22 AM

> I'm not rewriting history by saying that we established the principle.
> Actually, Bob Duff was the first to voice the principle in my memory,
> and it was pretty early in the 9X process when we were debating things
> like passive tasks, etc.

Hmm.  One of us is misremembering.  The way I remember it, I was strongly
against documenting any "good taste" rules for pragmas, because my versions of
such rules are way too vague, and have way too many exceptions that I can't
explain in any logical way.

I find pragma Elaborate to be in poor taste.
Pragma Import, not so much.

I see nothing wrong with:

    procedure Check_Goodness (X : T) is
    begin
        pragma Assert (<some expression involving X>);
    end Check_Goodness;

which is illegal.

> You are pointing out that we failed miserably on following our
> principle, and that is true in the area of conventions, where there
> are a number of cases that require exact matching of conventions, and
> that can only be done using pragmas.
>
> But I really see representational
> issues as a separate domain from
> non-representation-related legality rules.
> Perhaps that is my own quirk...

I agree with you about representation pragmas.  I see a conceptual
(ill-defined) distinction between high-level semantics and low-level semantics,
and I'm more likely to cry "poor taste" when high-level semantics are affected
in such a way that removing a pragma breaks things.  Rep pragmas affect
low-level semantics.

****************************************************************

From: Tucker Taft
Sent: Sunday, June 28, 2009  12:47 PM

The "Mapping Specification" from 1991 said, roughly:

   An implementation-defined pragma cannot
   make an illegal program legal.

I think we ultimately dropped that to allow implementation-defined versions of
pragma Import, but the principle was there pretty early.

And I believe we agreed that language-defined pragmas should only rarely violate
the above. But my memory is certainly flaky enough to be mis-remembering who
first voiced concerns about "taste" in pragmas.

****************************************************************

From: Robert Dewar
Sent: Sunday, June 28, 2009  1:12 PM

it would have been a HORRIBLE restriction. To say that pragma Ada_2005 is
illegal is VERY unhelpful, there are many other examples! You would have forced
all kinds of things that are naturally configuration pragmas to be compiler
switches instead. Another example is Wide_Character_Encoding.

And if you did not make an exception for representation pragmas, that would have
been even worse.

Anyway, this bad idea did not survive, so no real point in taking pot shots at
it now, unless it surfaces to prevent choosing the best design in current
discussions.

I think we should choose between a pragma and syntax based on the particular
case, without reference to this bogus good-taste principle :-)

****************************************************************

From: Bob Duff
Sent: Sunday, June 28, 2009  1:35 PM

> The "Mapping Specification" from 1991 said, roughly:
>
>    An implementation-defined pragma cannot
>    make an illegal program legal.
>
> I think we ultimately dropped that to allow implementation-defined
> versions of pragma Import, but the principle was there pretty early.
>
> And I believe we agreed that language-defined pragmas should only
> rarely violate the above.
> But my memory is certainly flaky enough to be mis-remembering who
> first voiced concerns about "taste" in pragmas.

Well, my memory could be wrong, too.  But it's interesting that I joined the
project in July, 1991.  I think I had something to do with getting rid of that
as a rule, and making it a piece of folklore that is often, but not always,
true.  ;-)

****************************************************************

From: Bob Duff
Sent: Sunday, June 28, 2009  1:48 PM

Now I remember more: The statement above quoted from the Mapping Spec was a
deliberate backing off from the Ada 83 rule, which was that an impl-def pragma
cannot affect the legality in either direction.  We wanted to allow things like
pragma Restrictions, whose (legitimate) purpose is to make legal programs
illegal.

Then we backed off even further by removing the rule altogether.

Part of the argument was that any rules that attempt to limit
implementation-defined stuff (including pragmas) are formally nonsensical and
unenforcable, because the implementer can always say, "Oh, pragma
Legalize_Fortran_Syntax is not an impl-def Ada pragma -- it's only allowed in
some nonstandard mode (perhaps the default mode) which is not Ada, but merely
Ada-like".

****************************************************************

From: Robert Dewar
Sent: Sunday, June 28, 2009  11:44 AM

> I do not agree that pragma Import is in bad taste.  And if I wanted to
> add some functionality similar to pragma Import, but slightly
> different in some way, an implementation-defined pragma with similar
> properties would make sense to me.

Such as Import_Procedure and all the other "DEC" pragmas :-)

> If you erase all the pragmas from your program, your program is likely
> to break.  This is true for some language-defined pragmas (e.g.
> Import, Elaborate_All), and for some impl-def pragmas (e.g. GNAT's
> pragmas Abort_Defer, Ada_2005, Common_Object).  The idea that the
> broken program should remain legal is utterly pointless.

Actually, I would enunciate the following principle:

If you remove a pragma that will cause the program to misbehave, then it is
highly desirable that this show up as an illegality.

After all if we had some junk syntax to replace pragma Import

    import x with c (name);

or some such, then removing this would be exactly equivalent to removing the
pragma, so what's the point in creating some big distinction.

****************************************************************

From: Robert Dewar
Sent: Sunday, June 28, 2009  11:47 AM

> If you erase all the pragmas from your program, your program is likely
> to break.  This is true for some language-defined pragmas (e.g.
> Import, Elaborate_All), and for some impl-def pragmas (e.g. GNAT's
> pragmas Abort_Defer, Ada_2005, Common_Object).  The idea that the
> broken program should remain legal is utterly pointless.

Well removing Ada_2005 presumably causes an illegality (so I am supposed to
conclude this pragma is in bad taste???)

But Abort_Defer is a really good example. Removing this has VERY subtle effects.
If anything it is implementation pragmas that do NOT violate the rule about
illegality on removal that are worrisome!

****************************************************************

From: Robert Dewar
Sent: Sunday, June 28, 2009  11:51 AM

One little change I would REALLY like to see in pragmas is that they could
stand alone in a statement sequence. It is really annoying having to write junk
null statements.

    if cond then
       pragma Assert (bla bla)
    else
       bla bla
    end if;

should be legal. I see no downside in this, and it would clean up code.

****************************************************************

From: Randy Brukardt
Sent: Monday, June 29, 2009  9:30 PM

> > That's not really true for language-defined pragmas. Pragma Import
> > is a pragma in bad taste, but it's pretty much impossible to avoid
> > using it (as much as I'd like to). Imagine trying to write Claw
> > without using pragma Import! :-)
>
> I do not agree that pragma Import is in bad taste.  And if I wanted to
> add some functionality similar to pragma Import, but slightly
> different in some way, an implementation-defined pragma with similar
> properties would make sense to me.

I dislike all representation pragmas on general principles: representation is
too important a detail to hide away far away from a declaration. [I don't much
like the attribute definition clauses, either for the same reason.] But that's
pretty much irrelevant here.

> If you erase all the pragmas from your program, your program is likely
> to break.  This is true for some language-defined pragmas (e.g.
> Import, Elaborate_All), and for some impl-def pragmas (e.g. GNAT's
> pragmas Abort_Defer, Ada_2005, Common_Object).  The idea that the
> broken program should remain legal is utterly pointless.

I disagree. There is a strong point for "good taste" in implementation-defined
pragmas: it allows the code to remain portable even if some other compiler
doesn't recognize some impl-def pragma. I've always presumed that this was the
intent behind the idea of "good taste". After all, impl-def pragmas that change
the legality or correctness of a program are just as bad for vendor lock-in as
adding private syntax.

I'm sure that in the Ada 83 days such pragmas would have been considered very
bad: I know we avoided such things because it wasn't clear to us whether the
ACVC statement of conformance allowed impl-def pragmas of that kind.

Obviously, we've moved away from that level of portability. As a practical
matter, we may not have had any choice. (Implementers need *some* way to
describe target-specific features.) But that makes me worry about the future of
Ada (if it isn't reasonably portable, it has lost one of its most important
advantages).

> AI05-0100-1 was supposed to fix some confusing wording about pragma
> placement syntax.  Adding the AARM annotation as part of that AI was
> just plain wrong, and if I'd been paying attention, I would have
> objected.  Luckily, AARM annotations are non-normative, and all
> implementers will ignore this one
> -- no sane compiler writer is going remove existing pragmas that
> violate this "taste"
> rule, including the compiler writer who wrote that AI (which I'm
> guessing is our good friend Tucker Taft, based on the style in which
> the !discussion is written ;-)).

We needed to understand the point of the pragma placement rules. If there is no
point, then they should simply have been deleted or simplified down to "anywhere
that a semicolon is allowed". Once we understood the intent, it seemed important
to document it so we wouldn't have to argue about what these complex rules are
supposed to be doing.

Of course, had you come to the meeting, you might have convinced us to drop the
intent. But then I have no idea what the point of the placement rules is: we
surely would have needed an alternative intent. (After all, in early Janus/Ada,
pragmas were purely lexical and only supported simple id or literal arguments --
they were removed by the lexer and the parser never saw them. Pragmas could
literally appear anywhere, and it worked fine. But we eventually had to change
it to support those placement rules and to support complex expressions as pragma
arguments -- because the language required that. I've never seen any advantages
whatsoever to those more complex pragmas over proper syntax for specifying
things.)

So if you want some other intent, I think it would be important for you to
explain that intent in detail. I can't see any way to determine if the placement
rules are right without having *some* intent for the placement and use of
pragmas.

P.S. Are you and Robert calling for the reopening of AI05-0100-1?

****************************************************************

From: Robert Dewar
Sent: Tuesday, June 30, 2009  6:52 AM

> I dislike all representation pragmas on general principles:
> representation is too important a detail to hide away far away from a
> declaration. [I don't much like the attribute definition clauses,
> either for the same reason.] But that's pretty much irrelevant here.

I disagree .. whether representation details are or are not part of the visible
interface is a choice up to the designer of the interface. For example

       type R is bla bla bla

    private

       rep clauses to make R efficient for the internal
       implementation of the package

This is a useful and legitimate arrangement, you are saying that the client
should NOT depend on the representation of R in this example, and that the
implementor may change the representation expecting NOT to break clients.

Very useful, we do this all the time

> I disagree. There is a strong point for "good taste" in
> implementation-defined pragmas: it allows the code to remain portable
> even if some other compiler doesn't recognize some impl-def pragma.
> I've always presumed that this was the intent behind the idea of "good
> taste". After all, impl-def pragmas that change the legality or
> correctness of a program are just as bad for vendor lock-in as adding private syntax.

Well the design has something to say about legaitly, but NOTHING AT ALL to say
about correctness. It is quite deliberate

> I'm sure that in the Ada 83 days such pragmas would have been
> considered very bad: I know we avoided such things because it wasn't
> clear to us whether the ACVC statement of conformance allowed impl-def
> pragmas of that kind.

With respect to legality, perhaps, but with respect to changed behavior
certainly there was NO indication that such pragmas were undesirable, so if you
think the language should have discouraged such usage, fine, but you are not
talking about Ada as developed.

> Obviously, we've moved away from that level of portability. As a
> practical matter, we may not have had any choice. (Implementers need
> *some* way to describe target-specific features.) But that makes me
> worry about the future of Ada (if it isn't reasonably portable, it has
> lost one of its most important advantages).

It *is* reasonably portable. for one thing, implementors copy one anothers
pragmas and attributes (don't forget that attributes are in the same boat here,
and they immediately make things illegal if not implemented, there is no rule
for ignoring implementaiton dependent attributes, same with restrictions and
check names etc etc.

> We needed to understand the point of the pragma placement rules. If
> there is no point, then they should simply have been deleted or
> simplified down to "anywhere that a semicolon is allowed". Once we
> understood the intent, it seemed important to document it so we
> wouldn't have to argue about what these complex rules are supposed to be
> doing.

It is indeed annoying that pragmas can't be put anywhere

> Of course, had you come to the meeting, you might have convinced us to
> drop the intent. But then I have no idea what the point of the
> placement rules
> is: we surely would have needed an alternative intent. (After all, in
> early Janus/Ada, pragmas were purely lexical and only supported simple
> id or literal arguments -- they were removed by the lexer and the
> parser never saw them. Pragmas could literally appear anywhere, and it
> worked fine. But we eventually had to change it to support those
> placement rules and to support complex expressions as pragma arguments
> -- because the language required that. I've never seen any advantages
> whatsoever to those more complex pragmas over proper syntax for
> specifying things.)

I find this point of view amazing, and totally impractical. I can't imagine that
a compiler with such a limited view of pragmas could be useful in practice in
the Ada world. We support 170 pragmas, the majority of which are implementation
dependent, and in fact I would guess that about half of them are copied from
other compilers (actually in Ada 2005, fewer are ID, since several have been
copied by the standard :-)

They are an important part of the usability of the language, and the language
design recognizes and expects this by allowing the addition of pragmas. All
compilers that we see in the market place implement a rich set of pragmas, so it
seems a retrograde argument to argue against this.

> So if you want some other intent, I think it would be important for
> you to explain that intent in detail. I can't see any way to determine
> if the placement rules are right without having *some* intent for the
> placement and use of pragmas.

I agree that the placement rules are junk. In particular, not allowing pragmas
in subprogram parameter lists is a real pain.

> P.S. Are you and Robert calling for the reopening of AI05-0100-1?

yes, I think that would be a good idea

****************************************************************

From: Randy Brukardt
Sent: Monday, June 30, 2009  1:50 PM

> They are an important part of the usability of the language, and the
> language design recognizes and expects this by allowing the addition
> of pragmas. All compilers that we see in the market place implement a
> rich set of pragmas, so it seems a retrograde argument to argue
> against this.

Well, this sort of effect is predictable, given that the language doesn't have
any other way to create implementation-defined stuff. I personally don't think
that had to be the case (and that it would have been better if it was not the
case), but in any event it *is* the case and surely it is not going to change.

The real question is what, if anything, should be recommended for the design and
use of pragmas. In one sense, it doesn't matter (because implementers are going
to do whatever they want in any case), but in another sense, guidance for the
design of these things does seem valuable if it increases the possibility of
portability. Seems worth discussing further (although Bob better show up if he
wants a different result than the last time :-).

> > So if you want some other intent, I think it would be important for
> > you to explain that intent in detail. I can't see any way to
> > determine if the placement rules are right without having *some*
> > intent for the placement and use of pragmas.
>
> I agree that the placement rules are junk. In particular, not allowing
> pragmas in subprogram parameter lists is a real pain.

Fair enough.

> > P.S. Are you and Robert calling for the reopening of AI05-0100-1?
>
> yes, I think that would be a good idea

OK, we need a second. (Two members to move for reconsideration.)

****************************************************************

From: Bob Duff
Sent: Monday, June 30, 2009  3:39 PM

> The real question is what, if anything, should be recommended for the
> design and use of pragmas.

Nothing.  Our job is to define the language, not to give advice about language
extensions (including those extensions that are sanctioned by the RM -- pragmas
and attributes).

>...In one sense, it doesn't matter (because implementers  are going to
>do whatever they want in any case), but in another sense,  guidance for
>the design of these things does seem valuable if it increases  the
>possibility of portability.

I go with the "one sense", rather than the "'nother sense".

I really don't see how anything we say can have any beneficial effect on
portability.  Implementations copying each others' pragmas can help, as Robert
pointed out, but that's different.

>...Seems worth discussing further (although Bob  better show up if he
>wants a different result than the last time :-).

Well, I really hate traveling, so I won't make any promises.  The chair is
allowed to kick me off the committee if he doesn't like that.

If I don't show up, I can at least contribute something (hopefully useful) via
e-mail.

> > > So if you want some other intent, I think it would be important
> > > for you to explain that intent in detail. I can't see any way to
> > > determine if the placement rules are right without having *some*
> > > intent for the placement and use of pragmas.
> >
> > I agree that the placement rules are junk. In particular, not
> > allowing pragmas in subprogram parameter lists is a real pain.
>
> Fair enough.
>
> > > P.S. Are you and Robert calling for the reopening of AI05-0100-1?
> >
> > yes, I think that would be a good idea
>
> OK, we need a second. (Two members to move for reconsideration.)

Well, should I second?  I have no objection to the normative part of that AI --
I only object to the AARM wording, and it doesn't have any real effect, since
implementations are going to keep supporting whatever pragmas they support (and
perhaps add new ones).

I thought Robert's Rules said that in order to reconsider, somebody has to
change their mind, or something like that.  No?

****************************************************************

From: Randy Brukardt
Sent: Monday, June 30, 2009  4:28 PM

> Well, should I second?  I have no objection to the normative part of
> that AI -- I only object to the AARM wording, and it doesn't have any
> real effect, since implementations are going to keep supporting
> whatever pragmas they support (and perhaps add new ones).

Robert would like to relax the placement rules further (he has given two
examples, a pragma in place of "null;", and pragmas in parameter lists.

I personally think that if we agree your "no recommendations" recommendation,
then we should relax the placement rules some more. I doubt that they are
consistently enforced by compilers (there are a bunch of Ada 83 ACATS syntax
tests, but I don't think they come close to testing all of the possibilities).
(The cases that Robert would like to allow are tested, though.)

In any case, whatever the placement rules are, there needs to be justification
for them. No justification at all should mean no rules, and I don't think anyone
at all is suggesting no rules on the use of pragmas. So I do think that some
sort of "language design principle" is needed. If you don't like the one in the
AI, then I think you ought to suggest a replacement. (I cannot guess how you
think pragmas should work.)

> I thought Robert's Rules said that in order to reconsider, somebody
> has to change their mind, or something like that.  No?

My recollection (and looking back at the Venice minutes where this was decided
seems to confirm that) was that Tucker pretty much explained how he thought
things worked. There was at least some discomfort with the logical result of
that, but no one had a better idea (or, as I said in the minutes, perhaps they
were afraid that they would end up with the AI if they spoke up - it was treated
a lot like a hot potato). So I'm not that convinced that we ended up with a
consensus as much as an exhaustion.

The net effect is that we may not have ended up with the correct result, and as
such I'm willing to look at it again. But only if some strong advocate for some
other position steps forward and makes a concrete proposal and (preferably)
comes to a meeting to defend it. Otherwise, I would expect we'd come to the same
conclusion -- if the only person who seems to care is the same one that drove
the result the last time, I think we're likely to come up with the same result.

Procedurally, there is no clear way to reconsider a WG 9 approved AI (normally,
there should be a request for a letter ballot before it gets to that stage). Our
procedures are completely silent on this issue. In the past, we've simply
created a new AI to correct the previous one - but that's usually happened
because a clear error in the previous one. So that what we ought to do, assuming
that there is sufficient support for some alternative *and* Ed concurs (he would
be within his rights to keep it off of the agenda based on it having been
previously decided).

****************************************************************

From: Ed Schonberg
Sent: Monday, June 30, 2009  4:52 PM

Leaving aside the procedural issue concerning something already WG9 approved,
I'm certainly in favor of reopening the discussion (or creating a new AI) to
handle those two cases:  parameter lists, and null statement lists.  It is
certainly awkward that we cannot write:

else
   Assert (False);
end if;

which comes up often enough.

****************************************************************

From: Tucker Taft
Sent: Monday, June 30, 2009  4:56 PM

I would recommend we leave this as is, or make a special exception for statement
sequences, allowing a pragma to take the place of a statement, groddy as that
may seem.

Going much beyond that seems more trouble than it is worth.  There are a number
of tools, as Randy has said, that essentially ignore pragmas.  Of course they
can't do full legality checking that way, but they can probably do a fair amount
of useful stuff, including overload resolution, cross referencing, style
checking, etc.

A lot of tools presume the compiler already did all the relevant legality
checking, so they just barrel ahead assuming they have a legal program.  If some
"body" is missing because of some weird implementation-defined pragma that is
equivalent to "import," so be it.  They can usually survive pretty easily that
sort of thing.

****************************************************************

From: Bob Duff
Sent: Monday, June 30, 2009  5:37 PM

> Robert would like to relax the placement rules further (he has given
> two examples, a pragma in place of "null;", and pragmas in parameter lists.

I think that would require a new AI.  AI05-0100-1 didn't address the issue of
relaxing the syntax rules -- it just clarified what they are, and added an AARM
annotation.  The AARM annotation is bogus, IMHO, but relatively harmless.

> I personally think that if we agree your "no recommendations"
> recommendation, then we should relax the placement rules some more.

I could support that.  But I could also live with the language as is, even
though I agree with Robert's complaints.  Shrug.

>...I doubt
> that they are consistently enforced by compilers (there are a bunch of Ada
> 83 ACATS syntax tests, but I don't think they come close to testing
>all of  the possibilities). (The cases that Robert would like to allow
>are tested, though.)

I'll bet they are pretty close to "consistently enforced by compilers".

> In any case, whatever the placement rules are, there needs to be
> justification for them. No justification at all should mean no rules,
> and I don't think anyone at all is suggesting no rules on the use of
> pragmas. So I do think that some sort of "language design principle"
> is needed. If you don't like the one in the AI, then I think you ought
> to suggest a replacement.

The justification for the current Ada 2005 rules is clear: this is the way it
was in Ada 83, and this is the way compilers implemented it.  AI05-0100-1 (the
normative part, about syntax) matches the _intent_ of Jean Ichbiah, and I see no
reason why the ARG should justify his intent in AARM annotations.  Even if some
guy like Bob Duff comes along and claims that intent was bogus all along.

>... (I cannot guess how you think pragmas should work.)

I'm not even sure myself.

> > I thought Robert's Rules said that in order to reconsider, somebody
> > has to change their mind, or something like that.  No?
>
> My recollection (and looking back at the Venice minutes where this was
> decided seems to confirm that) was that Tucker pretty much explained
> how he thought things worked. There was at least some discomfort with
> the logical result of that, but no one had a better idea (or, as I
> said in the minutes, perhaps they were afraid that they would end up
> with the AI if they spoke up
> - it was treated a lot like a hot potato). So I'm not that convinced
> that we ended up with a consensus as much as an exhaustion.

OK, that convinces me that I do not want to second Robert's motion.
I do not want to end up being responsible for [re]writing AI05-0100-1, because
it's just not important enough to spend time on.

> The net effect is that we may not have ended up with the correct
> result, and as such I'm willing to look at it again. But only if some
> strong advocate for some other position steps forward and makes a
> concrete proposal and
> (preferably) comes to a meeting to defend it.

I sure ain't flyin' half-way 'round the world to argue about this particular
issue!  OTOH, if Tuck hosts the meeting at SofCheck, I'll happily go there.

>...Otherwise, I would expect we'd
> come to the same conclusion -- if the only person who seems to care is
>the  same one that drove the result the last time, I think we're likely
>to come  up with the same result.
>
> Procedurally, there is no clear way to reconsider a WG 9 approved AI
> (normally, there should be a request for a letter ballot before it
> gets to that stage). Our procedures are completely silent on this
> issue. In the past, we've simply created a new AI to correct the
> previous one - but that's usually happened because a clear error in
> the previous one. So that what we ought to do, assuming that there is
> sufficient support for some alternative
> *and* Ed concurs (he would be within his rights to keep it off of the
> agenda based on it having been previously decided).

A new AI is appropriate if someone thinks this issue is important enough.
I don't.  But I can change my mind.  ;-)

****************************************************************

From: Robert Dewar
Sent: Friday, July  3, 2009  9:06 AM

> I would recommend we leave this as is, or make a special exception for
> statement sequences, allowing a pragma to take the place of a
> statement, groddy as that may seem.

I agree with all this, except I don't think it is "groddy" (a rather extreme
word, typically meaning "beyond gross").

****************************************************************

From: Robert Dewar
Sent: Friday, July  3, 2009  3:00 PM

> The real question is what, if anything, should be recommended for the
> design and use of pragmas. In one sense, it doesn't matter (because
> implementers are going to do whatever they want in any case), but in
> another sense, guidance for the design of these things does seem
> valuable if it increases the possibility of portability. Seems worth
> discussing further (although Bob better show up if he wants a different result
> than the last time :-).

I don't think that guidance will have any effect whatsoever on implementors, who
will be guided by customer needs, not the ARG in this respect.

>>> P.S. Are you and Robert calling for the reopening of AI05-0100-1?
>> yes, I think that would be a good idea

On second thoughts, if I voted to reopen this, I withdraw my vote, seems a waste
of time (except possibly for the groddy rule :-))

****************************************************************

From: Robert Dewar
Sent: Friday, July  3, 2009  3:01 PM

> I thought Robert's Rules said that in order to reconsider, somebody
> has to change their mind, or something like that.  No?

That's true, but nowhere does it say we are governed by RR, we have our own
procedures!

****************************************************************

From: Robert Dewar
Sent: Friday, July  3, 2009  3:02 PM

Why not just make a new AI with the two useful extensions, (parameter list,
single statement) and avoid discussions on anything else :-)

****************************************************************

From: Jean-Pierre Rosen
Sent: Friday, July  3, 2009  5:21 PM

>> I thought Robert's Rules said that in order to reconsider, somebody
>> has to change their mind, or something like that.  No?
>
> That's true, but nowhere does it say we are governed by RR, we have our
> own procedures!                                         ^^

Is it the origin of the name RR Software?

****************************************************************

From: Bob Duff
Sent: Thursday, November 19, 2009  12:52 PM

Here's a new version of AI05-0163-1 [this is version /01 - ED], which allows a
sequence_of_statements to consist entirely of pragma(s), with no "null;"
required, as agreed at the ARG meeting.  Also, as agreed, it does not propose to
allow pragmas in procedure specs.

A possibly-controversial aspect is that I removed all the stuff from the RM and
AARM about "good taste in pragmas".  I just couldn't see how to reword it to
make sense with the new rule.  I know Tucker has some fondness for this
verbiage, so might want to argue against this change.

Let me point out the history (as I see it, of course):

Ada 83 forbade impl-def pragmas from affecting legality.
There is no sensible reason for this, and I advocated removing it in Ada 9X, but
instead it was weakened in several ways: only applies in one direction,
downgraded to Impl Advice, some exceptions added, weasel word "Normally, ..."
added, which allows implementations to add their own exceptions.

AI-150 added some Language Design Principles in the AARM.
The idea was that if we're going to have Advice, we need to defend it.  But this
Advice comes originally from Jean Ichbiah (with changes), and I have no idea
what Ichbiah was thinking. In short I see no need to defend anything, and indeed
no need for the advice at all.

So Tuck (or anybody else), if you want to argue in favor of having good-taste
rules of some sort, I suggest you address my rationale below, and also suggest
wording.  The current wording is certainly wrong, given the change made by this
AI.

Folks should also review my various related decisions mentioned below (no
changes to records, for ex.)

****************************************************************

From: Tucker Taft
Sent: Thursday, November 19, 2009  1:26 PM

I guess I do object to removing all this verbiage.

We are just making one special case to allow a pragma to act as a statement.
That hardly seems enough justification to erase all the advice about
implementation-defined pragmas.  I will make an attempt to fix the existing
advice to accommodate the special case we are making for statements, and keep an
eye out for clearly meaningless advice.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 19, 2009  2:37 PM

I strongly object to the pragma good taste rules. I say good riddance!

****************************************************************

From: Robert Dewar
Sent: Thursday, November 19, 2009  2:45 PM

> I guess I do object to removing all this verbiage.

Well I think the advice is pointless. Certainly we pay absolutely zero attention
to this advice in the case of GNAT, and many of the "bad taste" pragmas we have
are imported from other implementations, so we are certainly not alone in
ignoring this advice.

What's the point of stuff in the RM that has no effect whatever on
implementations?

We have only the following criteria for pragmas

a) they must be conformant to the standard, but we will stretch mightily to
   follow only the word and not any guessed spirit of any restrictions that
   stand in our way.

b) they must be useful to our users

****************************************************************

From: Tucker Taft
Sent: Thursday, November 19, 2009  2:50 PM

It seems to be a very important principle that implementors can generally add
pragmas without necessarily creating portability problems (unlike attributes). I
think we need to encourage that, and try to provide guidelines for how to
accomplish it, both for the benefit of users and vendors.

In any case, I don't believe the ARG decided that part of the "intent" of this
AI was gutting the implementation advice, so we at least need to consider that
as a group.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 19, 2009  4:53 PM

> It seems to be a very important principle that implementors can
> generally add pragmas without necessarily creating portability
> problems (unlike attributes).
> I think we need to encourage that, and try to provide guidelines for
> how to accomplish it, both for the benefit of users and vendors.

But in fact I don't think the words in the ARG have ANY effect WHATEVER in
encourging what you think (but I and others disagree) is good taste in this
respect.

The fact is that pragmas can indeed cause huge portability problems, even if
they only affect semantics and not legality, and in any case attributes, as
noted above, can cause very serious portability problems anyway.

Any user for whom this portability is a concern can avoid the use of
impl-defined pragmas/attributes and enforce this decision.

For a user and implementor who do NOT care about portability, the RM has no
useful advice wrt pragmas, so why offer gratuitous useless advice.

I understand the theoretical world in which Tuck is operating his portability
argument, but it has nothing to do with the real world, and is in any case a
figure in a dike that is leaking buckets at other points.

> In any case, I don't believe the ARG decided that part of the "intent"
> of this AI was gutting the implementation advice, so we at least need
> to consider that as a group.

Indeed, let's see what others think here!

****************************************************************

From: Jean-Pierre Rosen
Sent: Friday, November 20, 2009  12:55 AM

> Any user for whom this portability is a concern can avoid the use of
> impl-defined pragmas/attributes and enforce this decision.

But why restrict yourself to pragmas? You could say the same thing of any
language extension. "We have implemented full multiple inheritance in Ada,
people who want portability should avoid using it".

That's exactly what Ada was supposed to avoid: a core language, with many
extensions, all incompatible between vendors. Remember Ichbiah's fish?

****************************************************************

From: Robert Dewar
Sent: Friday, November 20, 2009  6:14 AM

> But why restrict yourself to pragmas? You could say the same thing of
> any language extension. "We have implemented full multiple inheritance
> in Ada, people who want portability should avoid using it".

Because the language very specifically allows pretty much arbitrary extension as
long as it is restricted to pragmas and attributes. Any other kind of extension
would be non-conforming.

> That's exactly what Ada was supposed to avoid: a core language, with
> many extensions, all incompatible between vendors. Remember Ichbiah's fish?

But the fact is that pragmas and particularly attributes were designed into the
language as a specific exception to this principle. So there is nothing
"non-Ada" about allowing implementations to extend the language with pragmas and
attributes.

The real point here is that having some weasel words about pragmas not affecting
legality is pointless because:

a) if you have pragmas that radically affect the semantics, e.g. pragma
   C_Pass_By_Copy which was initially an impl-defined pragma, or pragma
   Persistent_BSS, or pragma Machine_Attribute, or pragma Thread_Local_Storage,
   just to pick a few examples from GNAT, these pragmas 100% meet the IA. You
   can remove them, and the program compiles fine without them, so it compiles
   fine with some other compiler not recognizing these pragmas. But how does
   that promote portability? The resulting program has totally wrong semantics
   if the pragma is involved. So limiting the IA to legality is wholly
   insufficient.

b) in practice implementations ignore this IA in any case, so the idea that
   these words have some effect is a language lawyer delusion.

c) in any case attributes are not reigned in this way, and so
   extension-via-attribute is rampant, and causes even more portability problems
   than pragmas can cause.

If Ada went all the way and said that pragmas could affect neither legality nor
behavior, then that would be one thing. Of course it would mean that only the
most useless of pragmas, like Title, would be allowed, and in practice would
make Ada less usable. But the Ada design (including JDI with his fish)
recognized that a well-defined escape hatch for implementation defined additions
is needed.

Going back to JDI's point, it is of course just fine to add full multiple
inheritance to any Ada compiler provided it is done under an extension switch.
For example, GNAT today implements conditional expressions under the -gnatX
extension switch (shortly to be moved to the -gnat12 flag for Ada 2012). Nothing
wrong with that, but it's completely outside the language as formally defined.

Now in the case of pragmas and attributes, we don't need a switch.
The one thing that Ada 83 and Ada 95 missed was the need for a clear way for a
programmer to say "no impl-defined attributes/pragmas".

GNAT added that capability a long long time ago and finally that got added to
Ada 2005 (though for some reason, Ada 2005 still missed
No_Implementation_Restrictions, why?) At the point where
No_Implementation_Pragmas was added to the language, the vague IA should have
been dropped. NIP is definitive and forces full portability. It is what you want
if you are interested in portability. You cannot rely on the RM advice even if
compilers did follow it, because of the fact that unbounded semantic effects are
still allowed from pragmas.

****************************************************************

From: Tucker Taft
Sent: Friday, November 20, 2009  7:04 AM

It is true that implementation-defined attributes create portability problems,
but it is typically the case that implementation-defined pragmas don't.

This isn't theoretical as far as I am concerned, because on a daily basis we
compile our 300+KLOC Inspector sources through two different Ada compilers, and
although AdaMagic warns about many of the GNAT pragmas, the program in fact runs
identically (as far as testing can determine) with the two compilers.

Clearly someone had some "taste" who designed the GNAT pragmas. ;-) I have less
confidence in what users might try to torture their Ada vendors into providing.

I certainly don't want to reject programs just because they use a few "tasteful"
pragmas, and I would rather not have to look in detail at each such pragma to
decide whether or not it is in fact one of the "tasteful" ones.

In my view, implementations that provide a lot of non-tasteful pragmas are not
doing the language a favor, and I believe the RM ought to somehow communicate
that, both to the vendors, and to the users who might try to persuade their
vendor to create these pragmas.

****************************************************************

From: Robert Dewar
Sent: Friday, November 20, 2009  7:52 AM

> Clearly someone had some "taste" who designed the GNAT pragmas. ;-) I
> have less confidence in what users might try to torture their Ada
> vendors into providing.

There are dozens and dozens of GNAT pragmas that violate the RM IA, and also
many that affect semantics in a fundamental way. After all Inspector doesn't
care much if the program still does what it is supposed to do, it is about
finding problems that will indeed mostly be independent of pragmas. Users don't
have to torture us, we will pretty much provide any pragmas that make technical
sense, or have been made available in other vendors compilers. Our only
criterion is whether they make sense from a technical point of view, nothing
else.

> I certainly don't want to reject programs just because they use a few
> "tasteful" pragmas, and I would rather not have to look in detail at
> each such pragma to decide whether or not it is in fact one of the
> "tasteful" ones.

Well as I say, GNAT pays no attention whatever to the RM advice in this area.

> In my view, implementations that provide a lot of non-tasteful pragmas
> are not doing the language a favor, and I believe the RM ought to
> somehow communicate that, both to the vendors, and to the users who
> might try to persuade their vendor to create these pragmas.

Well GNAT certainly provides lots of pragmas of all kinds, if you think that all
the GNAT pragmas are in good taste, then for sure I can't imagine what might be
non-tasteful :-)

If the justification for this language is that it will influence users and
vendors, that certainly does not apply for GNAT. Does it apply for other
compilers, e.g. will Ada Magic suddenly go berserk adding pragmas if we remove
this implementation advice? I doubt it!

Actually, the provision of full preprocessing facilities is much more radical
than any pragmas, and most Ada compilers provide this capability (don't know
about Ada Magic, though people can always use e.g. the C preprocessor at a
pinch).

****************************************************************

From: Tucker Taft
Sent: Friday, November 20, 2009  8:35 AM

> There are dozens and dozens of GNAT pragmas that violate the RM IA,
> and also many that affect semantics in a fundamental way. After all
> Inspector doesn't care much if the program still does what it is
> supposed to do, it is about finding problems that will indeed mostly
> be independent of pragmas. Users don't have to torture us, we will
> pretty much provide any pragmas that make technical sense, or have
> been made available in other vendors compilers. Our only criterion is
> whether they make sense from a technical point of view, nothing else.

Two things:  I am not talking about running the Inspector on other people's
sources.  I am talking about compiling the Inspector itself, which is written in
Ada.

Secondly, you talk about "makes technical sense" but I think it helps to have
some guidelines in the RM for that decision. Obviously you disagree, but I will
say that when I first started using Ada, and first read the reference manual, it
was very helpful to understand the *intent* behind the pragma capability, and
how it was supposed to relate to the underlying semantics.  Yes you are right
that vendors can still do whatever they please, but it really helps to
understand what is the point of the pragma capability, as opposed to, for
example, the attribute capability, when reading the RM.

Anyway, it doesn't look we are convincing each other, so I'll shut up at this
point.

****************************************************************

From: Robert Dewar
Sent: Friday, November 20, 2009  8:48 AM

> Two things:  I am not talking about running the Inspector on other
> people's sources.  I am talking about compiling the Inspector itself,
> which is written in Ada.

OK, but the inspector code was written by chaps with a VERY good sense of what
pragmas to use while retaining portability. For interest, what are examples of
impl-defined pragmas you use in the inspector sources (I would have expected the
answer to be none, but apparently that is not the case).

> Secondly, you talk about "makes technical sense" but I think it helps
> to have some guidelines in the RM for that decision.

Well I have designed many of the pragmas for GNAT, and I always thought the
attempt in the RM to limit things was useless (remember my VERY early example of
pragma Fortran, which says roughly: all programs are erroneous, and if you want
to ask what happens if they are exected, the effect is to compile the comments
as fortran code and execute the result. Pragma Fortran is 100% conforming with
the severe restrictions in Ada 83 on pragmas.

It is not that I disagree that some level of good taste must reign in pragma
design. Obviously I would strongly disapprove of pragma Fortran as described
above. Indeed I thought DEC went too far in some of their pragma stuff. (and now
of course we have to copy that). My point is that I don't believe the RM is any
help in formulating the good taste.

In fact I think it is damaging. If you formulate a set of rules, then there is a
tedency to think that this gives a license for anything that follows the letter
of these rules (*), including pragma Fortran.

So I agree with your goals in reigning in pragmas and keeping them in good
taste. It is just that I think the RM language approach is at best useless, and
at worst actively harmful in achieving that goal.

(*) sort of like the extra payment for carbon offset when buying airline
tickets. Environmentalists have come to oppose this. Why? Because they want
people to fly less and generate less CO2. The carbon offsets may neutralize
guilt, and thus give people implicit permission to fly more :-)

****************************************************************

From: Bob Duff
Sent: Friday, November 20, 2009  8:53 AM

> I certainly don't want to reject programs just because they use a few
> "tasteful" pragmas, and I would rather not have to look in detail at
> each such pragma to decide whether or not it is in fact one of the
> "tasteful" ones.

I understand the "would rather not..." but, in fact, that's exactly what was
necessary.  You and I specifically discussed pragma Abort_Defer[*], which is
GNAT specific, and we decided not to use it.  We used protected objects and
finalization ops for our abort-deferred regions instead. The alternative would
have been to add that pragma to Ada Magic.

The point is: we didn't rely on any Impl Advice; we had to understand the
semantics of each impl-def pragma we considered using.

[*] Or is it Defer_Abort? -- I can never remember the name.

****************************************************************

From: Robert Dewar
Sent: Friday, November 20, 2009  9:01 AM

Abort_Defer .. I find the omission of this capability from Ada puzzling. It is
hard enough to write abort-safe code *with* this pragma, and *really* hard
without it!

****************************************************************

From: Bob Duff
Sent: Friday, November 20, 2009  9:03 AM

> In any case, I don't believe the ARG decided that part of the "intent"
> of this AI was gutting the implementation advice, so we at least need
> to consider that as a group.

Agreed -- I had no mandate to remove that Advice.  I just noticed that the
current Advice is clearly incompatible with "pragmas in place of null", and I
tried to rewrite it, and it got more and more complicated, and more and more
obviously-pointless.  We've moved over the years from "Thou shalt not do X" to
"Thou shalt not do X, except foo, and except bar, and except blah, and anyway we
don't really mean it."  The "pragmas in place of null" thing is one more
"except...".

Note that we still have the rule that if an implementation doesn't recognize a
given pragma name, the pragma has no effect (except a warning).  Nobody suggests
changing that.  I would think that would satisfy your portability-related
desire.  It's just the notion of textually erasing pragmas from the program that
doesn't work, and that's the part I propose to remove.

****************************************************************

From: Bob Duff
Sent: Friday, November 20, 2009  9:06 AM

> I will make an attempt to fix the existing advice to accommodate the
> special case we are making for statements, and keep an eye out for
> clearly meaningless advice.

OK.

But I think you also owe us specific rebuttals to the rationale I gave in the
proposed AI.  Otherwise, we're just talking past one another.  "Portability is
good."  "Yeah, but the Advice doesn't provide portability."  "Yeah, but
portability is good, and it's like an Ichbiah Fish."  "Yeah, but..." etc.

****************************************************************

From: Bob Duff
Sent: Friday, November 20, 2009  8:54 AM

> Remember Ichbiah's fish?

What's that?

****************************************************************

From: Jean-Pierre Rosen
Sent: Friday, November 20, 2009  9:08 AM

Ichbiah used to describe extension to programming languages as fish food, put in
a bottle in the water. The little fish enters the bottle, eats all the nice
food, becomes a bigger fish, and cannot exit any more.

I.e.: when you start to depend on nice extensions, you end up bound to a single
compiler vendor.

****************************************************************

From: Bob Duff
Sent: Friday, November 20, 2009  9:17 AM

> For interest, what are examples of impl-defined pragmas you use in the
> inspector sources (I would have expected the answer to be none, but
> apparently that is not the case).

Pragma Warnings was one.

****************************************************************

From: Tucker Taft
Sent: Friday, November 20, 2009  9:43 AM

Here is a nearly complete list:

Warning: Unrecognized pragma name => "Unmodified"
Warning: Unrecognized pragma name => "Ada_2005"
Warning: Unrecognized pragma name => "Finalize_Storage_Only"
Warning: Unrecognized pragma name => "No_Strict_Aliasing"
Warning: Unrecognized pragma name => "Style_Checks"
Warning: Unrecognized pragma name => "Unreferenced"
Warning: Unrecognized pragma name => "Unreserve_All_Interrupts"

We actually "recognize" and ignore pragma Warnings... ;-)

****************************************************************

From: Robert Dewar
Sent: Saturday, November 21, 2009  9:52 AM

An interesting set. Ada_2005 does of course affect legality, but in a rather
predictable way (I wonder whether this is a pragma that should be standardized).

Unmodified, Style_Checks, Unreferenced, Warnings are certainly "in good taste"
OK pragmas, but probably not ones to consider standardized.

Unreserve_All_Interrupts does definitely affect behavior, but at a level really
outside the RM.

Finalize_Storage_Only is just an optimization pragma, so again in "good taste".

No_Strict_Aliasing causes the behavior of erroneous programs to become
well-defined (the case is when conversion of access types with unchecked
conversion results in an erroneous situation because a pointer has a value
which strictly speaking is illegitimate, but we "know what we mean". This
situation is 100% analogous to the conversion of pointers in C, which is also
undefined by the C standard, but frequently used.

One thing this discussion suggests is that useful documentation for GNAT or any
other compiler would be a discussion of how the impl-defined pragmas affect
portability in practice. I will open an enhancement ticket for GNAT to work on
this one day.

****************************************************************