Version 1.1 of acs/ac-00115.txt

Unformatted version of acs/ac-00115.txt version 1.1
Other versions for file acs/ac-00115.txt

!standard 2.8(4)          05-10-21 AC95-00115/01
!class Amendment 05-10-21
!status received no action 05-10-21
!status received 05-04-12
!subject
!summary
!appendix

From: Robert Dewar
Date: Tuesday, April 12, 2005  1:11 AM

RM 2.8(4) says:

     4   In a pragma, any pragma_argument_associations without a pragma_
     argument_identifier shall precede any associations with a pragma_
     argument_identifier.

I don't see the purpose of this arbitrary rule, which serves no functional
goal. It seems to go half way but no further in drawing tha analogy between
pragmas and subprogram calls.

I think we should either remove this useless rule, or go all the way and
say that if argument identifiers are given, then arguments can be reordered.

P.S. GNAT has never checked this rule till last night (I did not even know
the rule existed, and would not have anticipated it, since it makes no sense),
and that means no one ever had trouble porting, though to be fair, more code
gets ported *to* GNAT than *from* GNAT.

The AARM provides no enlightenment.

The reason I think that we should not retain the status quo is that the current
RM wording tends to encourage the common misconception that arguments to
pragmas can be reordered (further fueled by the fact that all DEC extra
pragmas allow such reordering).

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

From: Bob Duff
Date: Tuesday, April 12, 2005  9:33 AM

> The reason I think that we should not retain the status quo is that the current
> RM wording tends to encourage the common misconception that arguments to
> pragmas can be reordered (further fueled by the fact that all DEC extra
> pragmas allow such reordering).

I see no value in allowing them to be reordered.  If people have that
"common misconception", they'll find out soon enough.

But I'm biased, in that I don't think subprogram calls should
allow reordering, either.  Named assocs are supposed to increase
readability, and being inconsistent with order doesn't help.

I think the reason we didn't allow reordering is that it's easier
to write the RM that way.  The rules are presented in BNF, and it would
either increase the size of the BNF, or require a special rule that
says, "never mind what the BNF says; you can reorder".
In fact, now that I think about it, doesn't RM 2.8(4) *follow*
from the BNF rules?

I wouldn't mind allowing mixed named/positional, if this were 1992,
but at this point, I think: not sufficiently broken to bother fixing.

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

From: Randy Brukardt
Date: Tuesday, April 12, 2005  12:55 PM

> I think we should either remove this useless rule, or go all the way and
> say that if argument identifiers are given, then arguments can be
> reordered.

AI-36 says that pragmas work like subprogram calls. This matters for pragma
Import and Export, which have optional arguments. And reordering is not
allowed.

> P.S. GNAT has never checked this rule till last night (I did not even know
> the rule existed, and would not have anticipated it, since it makes no sense),
> and that means no one ever had trouble porting, though to be fair, more code
> gets ported *to* GNAT than *from* GNAT.
>
> The AARM provides no enlightenment.

It does a bit in B.1(51.b), but of course that's in the newest AARM that
hasn't even been posted yet. So nevermind. :-)

> The reason I think that we should not retain the status quo is that the
> current RM wording tends to encourage the common misconception that
> arguments to pragmas can be reordered (further fueled by the fact that
> all DEC extra > pragmas allow such reordering).

Well, I've always thought that reordering should be allowed (if the
arguments have names, most don't). I don't much want to have to implement
that, but it is just too inconsistent with the rest of the language to not
allow it.

But this whole issue was discussed in the context of AI-00036, so I have to
wonder if enough has changed in the intervening years to reopen the
discussion.

But if we want to do something in *this* Amendment, we need an AI in the
next few hours, as the final agenda for Boston will be frozen tomorrow
morning -- and we won't consider anything non-essential after we leave
Boston. (We're still planning to start the formal approval process this
summer.)

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

From: Pascal Leroy
Date: Tuesday, April 12, 2005  12:09 PM

> I don't see the purpose of this arbitrary rule, which serves
> no functional goal. It seems to go half way but no further in
> drawing tha analogy between pragmas and subprogram calls.

You might want to take a look at AI95-00036 where this and other rules
were discussed, and it was decided to preserve the status quo.

> I think we should either remove this useless rule, or go all
> the way and say that if argument identifiers are given, then
> arguments can be reordered.

If we discuss this topic, I am going to vehemently argue against the "no
reordering" rule which is actively harmful, doesn't simplify
implementations, and can only degrade readability.

You must be aware though that there is an ARG meeting next week-end, so if
you want this topic to be discussed at that meeting, you'll need to send
an AI within the next 24 hours.

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

From: Robert Dewar
Date: Tuesday, April 12, 2005  7:53 AM

> I think the reason we didn't allow reordering is that it's easier
> to write the RM that way.  The rules are presented in BNF, and it would
> either increase the size of the BNF, or require a special rule that
> says, "never mind what the BNF says; you can reorder".
> In fact, now that I think about it, doesn't RM 2.8(4) *follow*
> from the BNF rules?

chuckle chuckle, this is EXACTLY why I don't like 2.8(4). No,
this section does not follow from the BNF rules. They could have
been written that way but it would [greatly] "increase the size of the
BNF", so instead we introduced the special rule 2.8(4) that says
"never mind what the BNF says; you can't mix named/positional".

Ugly! Or if you tolerate this ugliness, then why not go a step
forward and allow ordering. The current rule is completely useless
and serves no functin, at least a rule allowing ordering would
serve some purpose.
>
> I wouldn't mind allowing mixed named/positional, if this were 1992,
> but at this point, I think: not sufficiently broken to bother fixing.

Well it's a minor cleanup. This check won't fall out free for any
compiler, since it is a perturbation to the syntax, it will have to
be checked by a junk specific check, easxy to remove, so certainly
no burden on compilers to remove this rule.

As for the quoted AI, it really doesn't address this issue, but instead
the issue of clearly wrong BNF syntax for pragma Import, I trust this
will be fixed!

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

From: Bob Duff
Date: Friday, April 15, 2005  8:08 AM

> chuckle chuckle, this is EXACTLY why I don't like 2.8(4). No,
> this section does not follow from the BNF rules.

I don't understand why.  For example, 11.5 says:

                                   Syntax

3     The form of a pragma Suppress is as follows:

4       pragma Suppress(identifier [, [On =>] name]);

which does *not* allow:

    pragma Suppress(On => Mumble, Range_Check);

And all the other pragmas have similar syntax.  It seems to me that if
we wanted to allow that, we would need more complicated BNF for many of
the pragmas, or else we would need a kludgy rule overriding the BNF.
(Well, it's not really BNF -- it's a sort of pseudo-BNF.)

And we would be in danger of allowing:

    pragma Suppress(Mumble, Range_Check);

which seems like trouble.  Or:

    type Range_Check is range 1..10;
    pragma Suppress(Range_Check, Range_Check);

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

From: Robert Dewar
Date: Friday, April 15, 2005  9:04 AM

>>chuckle chuckle, this is EXACTLY why I don't like 2.8(4). No,
>>this section does not follow from the BNF rules.

> I don't understand why.  For example, 11.5 says:

An example cannot disprove what I say, but an example can
confirm it:

7     pragma Convention([Convention =>] convention_identifier,[Entity =>] local\
_name);


14   pragma Import( [Convention =>] convention_identifier, [Entity =>] local_
name [, [External_Name =>] string_expression] [, [Link_Name =>]
string_expression]); -- See B.1.

13   pragma Export( [Convention =>] convention_identifier, [Entity =>] local_
name [, [External_Name =>] string_expression] [, [Link_Name =>]
string_expression]); -- See B.1.


Interestingly, these are the only three cases in the RM where the issue
arises (though in a real compiler, there are
of course dozens of other examples :-)

So indeed 2.8(4) is a real additional constraint. It is quite a nuisance
to try to get this rule into the BNF for a pragma.

> And all the other pragmas have similar syntax.

clearly a false claim :-)

> which does *not* allow:
>
>     pragma Suppress(On => Mumble, Range_Check);
>
> And all the other pragmas have similar syntax.  It seems to me that if
> we wanted to allow that, we would need more complicated BNF for many of
> the pragmas, or else we would need a kludgy rule overriding the BNF.
> (Well, it's not really BNF -- it's a sort of pseudo-BNF.)

2.8(4) has nothing to do with reordering, but certainly we would not want
to allow the above Suppress example, reordering only makes sense for
named parameters, as in the case of subprograms. But it would make
perfect sense to allow:

pragma Convention (Entity => Myfunc, Convention => C);

> And we would be in danger of allowing:
>
>     pragma Suppress(Mumble, Range_Check);
>
> which seems like trouble.  Or:
>
>     type Range_Check is range 1..10;
>     pragma Suppress(Range_Check, Range_Check);

Gosh this is a *bright red* herring.

Obviously reordering would only be allowed in the case of named parameters,
as for subprograms.

A prototype rule would be

2.8(?) Pragma arguments for which pragma identifiers are given may appear
in any order.

I think that would be 100% clear (you still keep 2.8(4), thus forbidding
obviously wrong examples such as Bob quotes above).

My choice would still be simply to eliminate 2.8(4). The fact that Bob Duff
did not even realize that this rule had an impact is indicative of its
obscurity, and a good argument for eliminating it.

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

From: Bob Duff
Date: Friday, April 15, 2005  9:47 AM

...
> 14   pragma Import( [Convention =>] convention_identifier, [Entity =>] local_
> name [, [External_Name =>] string_expression] [, [Link_Name =>]
> string_expression]); -- See B.1.
>
> 13   pragma Export( [Convention =>] convention_identifier, [Entity =>] local_
> name [, [External_Name =>] string_expression] [, [Link_Name =>]
> string_expression]); -- See B.1.

OK, now I get it.  I didn't realize those pragmas were written that way.

> Interestingly, these are the only three cases in the RM where the issue
> arises (though in a real compiler, there are
> of course dozens of other examples :-)

Well, the syntax of the implementation-defined ones is of course
implementation defined, so you can do what you like.  I admit that it's
annoying to have two different paths in the compiler, one for the
language-defined pragmas, and one for the others.

> So indeed 2.8(4) is a real additional constraint. It is quite a nuisance
> to try to get this rule into the BNF for a pragma.
>
> > And all the other pragmas have similar syntax.
>
> clearly a false claim :-)

Apparently.  ;-)

...
> A prototype rule would be
>
> 2.8(?) Pragma arguments for which pragma identifiers are given may appear
> in any order.
>
> I think that would be 100% clear (you still keep 2.8(4), thus forbidding
> obviously wrong examples such as Bob quotes above).

Yes, that seems like fine wording.  I still don't think it's worth the
trouble to fix, but I don't have any strong objection.

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


Questions? Ask the ACAA Technical Agent