!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) @dinsa @xindent Linker_Options is allowed only at the place of a @fa.> @dinst @xindent !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. ****************************************************************