Version 1.3 of ais/ai-00036.txt

Unformatted version of ais/ai-00036.txt version 1.3
Other versions for file ais/ai-00036.txt

!standard 02.08 (04)          96-08-31 AI95-00036/04
!standard B.01 (09)
!class binding interpretation 95-06-25
!status Corrigendum 2000 99-07-28
!status WG9 approved 95-06-14
!status ARG approved (subject to editorial review) 4-0-5 95-11-01
!status received 95-06-25
!qualifier Omission
!subject What are the rules for named notation in pragmas?
!summary
A pragma must obey the syntax rules for that particular pragma. In particular, arguments written in named notation must not be given in a different order than is required by the syntax rules.
For pragma arguments written in positional notation, the first argument corresponds to the first argument shown in the syntax rule for the pragma, the second argument corresponds to the second, and so on. This is true even in the presence of optional arguments.
!question
The syntax given for pragma Import is
pragma Import (
[Convention => ] convention_identifier -- (1) , [Entity =>] local_name -- (2) [ , [External_Name => ] string_expression ] -- (3) [ , [Link_Name => ] string_expression ] ) ; -- (4)
(and similarly for pragma Export).
Does this imply that named notation cannot be used to reorder the arguments? For example, is the following pragma legal? (No.)
pragma Import(C, Raise_Signal,
Link_Name => "raise", External_Name => "._raise"); -- Illegal!
Secondly, is there a rule from which I can deduce that
pragma Import (C, Raise_Signal, "raise");
means
pragma Import (C, Raise_Signal, External_Name => "raise");
(by eliding the text in the outer brackets on line (4) and the text in the inner brackets on line (3)) rather than
pragma Import (C, Raise_Signal, Link_Name => "raise");
(by eliding the text in the outer brackets on line (3) and the text in the inner brackets on line(4))?
!recommendation
(See summary.)
!wording
(See corrigendum.)
!discussion
As mentioned in 2.8(11.i), it is not the intent to allow reordering, even when named notation is used.
For positional notation, the intent is that pragma arguments follow the same rules as subprograms -- if positional notation is used, the arguments are associated in order. Thus,
pragma Import (C, Raise_Signal, "raise");
means:
pragma Import (C, Raise_Signal, External_Name => "raise");
since External_Name is the third argument of pragma Import.
!corrigendum B.1(9)
Insert after the paragraph:
A pragma Linker_Options is allowed only at the place of a declarative_item.
the new paragraph:
For pragmas Import and Export, the argument for Link_Name shall not be given without the pragma_argument_identifier unless the argument for External_Name is given.
!ACATS test
Create a B-Test to insure that out of order arguments are not allowed in Import and Export.
!appendix

!section 2.8(4)
!section B.1(5)
!section B.1(6)
!subject What are the rules for named notation in pragmas?
!reference RM95-2.8(4)
!reference RM95-B.1(5)
!reference RM95-B.1(6)
!reference as: 95-5119.a Norman H. Cohen 95-4-7>>

The syntax given for pragma Import is

   pragma Import (
      [Convention => ] convention_identifier        -- (1)
      , [Entity =>] local_name                      -- (2)
      [ , [External_Name => ] string_expression ]   -- (3)
      [ , [Link_Name => ] string_expression ] ) ;   -- (4)

(and similarly for pragma Export).

Is there a rule from which I can deduce that

   pragma Import (C, Raise_Signal, "raise");

means

   pragma Import (C, Raise_Signal, External_Name => "raise");

(by eliding the text in the outer brackets on line (4) and the text in
the inner brackets on line (3)) rather than

   pragma Import (C, Raise_Signal, Link_Name => "raise");

(by eliding the text in the outer brackets on line (3) and the text in
the inner brackets on line(4))?  2.8(4) says that one may not supply
an argument name for one pragma argument and elide it for a later one,
but this does not resolve the syntactic ambiguity.  In fact, the rule in
2.8(4) would only be necessary if named pragma argument associations
could be reordered in the same way as named parameter and generic
parameter associations:

  pragma Import
    (C, Raise_Signal, Link_Name => "raise", External_Name => "._raise");

Is the intent to allow this pragma?  It is inconsistent with the syntax
in B.1(5).

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

!section 2.8(4)
!section B.1(5)
!section B.1(6)
!subject What are the rules for named notation in pragmas?
!reference RM95-2.8(4)
!reference RM95-B.1(5)
!reference RM95-B.1(6)
!reference 95-5119.a Norman H. Cohen 95-4-7
!from Tucker Taft 95-04-12
!reference as: 95-5127.a Tucker Taft 95-4-12>>
!discussion

> The syntax given for pragma Import is
>
>    pragma Import (
>       [Convention => ] convention_identifier        -- (1)
>       , [Entity =>] local_name                      -- (2)
>       [ , [External_Name => ] string_expression ]   -- (3)
>       [ , [Link_Name => ] string_expression ] ) ;   -- (4)
>
> (and similarly for pragma Export).
>
> Is there a rule from which I can deduce that
>
>    pragma Import (C, Raise_Signal, "raise");
>
> means
>
>    pragma Import (C, Raise_Signal, External_Name => "raise");

No.  But you guessed right anyway ;-).

> (by eliding the text in the outer brackets on line (4) and the text in
> the inner brackets on line (3)) rather than
>
>    pragma Import (C, Raise_Signal, Link_Name => "raise");
>
> (by eliding the text in the outer brackets on line (3) and the text in
> the inner brackets on line(4))?  2.8(4) says that one may not supply
> an argument name for one pragma argument and elide it for a later one,
> but this does not resolve the syntactic ambiguity.

Agreed.  There should be a more explicit statement somewhere that
resolves this ambiguity in the "usual" way.

> ... In fact, the rule in
> 2.8(4) would only be necessary if named pragma argument associations
> could be reordered in the same way as named parameter and generic
> parameter associations:
>
>   pragma Import
>     (C, Raise_Signal, Link_Name => "raise", External_Name => "._raise");
>
> Is the intent to allow this pragma?  It is inconsistent with the syntax
> in B.1(5).

No, as mentioned in 2.8(11.i), it is not the intent to allow reordering.

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

!section 02.08(04)
!subject What are the rules for named notation in pragmas?
!reference RM95-02.08 (04)
!reference AI95-00036
!from Pascal Leroy 95-10-20
!reference 95-5359.a Pascal Leroy 95-10-20>>
!discussion

The text of this AI should mention something that only appears in the
appendix: "No, as mentioned in 2.8(11.i), it is not the intent to allow
reordering."

This is because the original question asked if:

pragma Import
(C, Raise_Signal, Link_Name => "raise", External_Name => "._raise");

is legal, and the current text of the AI doesn't answer this question.


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

!from Kiyoshi Ishihata 99-06-28

Rationale for corrigendum wording.

Although this AI is discussing the syntax of pragmas in general,
I believe that the wording change should be limited to Import and
Export.  Answers to the questions about general syntax of pragmas
merely confirm the RM.  There are no similar problems in the syntax
of pragmas other than Import or Export.

Only binding part in this AI is that a single string_expression in
Import and Export should be interpreted as External_Name rather than
Link_Name.  The other point of the AI, namely the fact that Link_Name
cannot be given before External_Name does not need any wording.  It
can be easily derived from the syntax rule.

Possible combinations of External_Name and Link_Name can be summarized
as follows.

       External      Link
(1)      omit        omit
(2)      omit     positional     inhibited by this AI
(3)      omit        named
(4)   positional     omit
(5)   positional  positional
(6)   positional     named
(7)      named       omit
(8)      named    positional     inhibited by 2.8(4)
(9)      named       named

My wording inhibits the case (2) only.  The case (8) is already
inhibited by 2.8(4).  If inhibiting both cases is preferable,
we can add "without the pragma_argument_identifier" at the end
of the sentence.

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


Questions? Ask the ACAA Technical Agent