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

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: Bob Duff
Sent: Sunday, June 28, 2009  11:20 PM

> 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: 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?

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