!standard 02.08 (04) 96-02-06 AI95-00036/03 !class binding interpretation 95-06-25 !status WG9 approved 95-06-14 !status ARG approved (subject to editorial review) 4-0-5 95-11-01 !status received 95-06-25 !subject What are the rules for named notation in pragmas? !summary 95-06-25 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 95-06-25 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 95-06-25 (See summary.) !wording 95-06-25 !discussion 95-06-25 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. !appendix 95-10-21 !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. ****************************************************************