Extending language defined pragmas DRAFT 87-08-06 AI-00317/06 1 | !standard 02.08 (08) 87-08-06 AI-00317/06 | !class binding interpretation 84-12-26 (provisional classification) | !status work-item 87-07-30 !status panel/committee-approved 87-01-19 (reviewed) !status panel/committee-approved (6-0-0) 86-11-14 (pending editorial review) !status work-item 86-10-09 !status received 84-12-26 | !topic Extending language defined pragmas | | !summary 86-10-13 (DRAFT) | | An implementation is not allowed to extend language-defined pragmas. | | !question 86-12-15 (DRAFT) Consider the following pragmas: pragma INTERFACE (FORTRAN, PROCEDURE_1); -- (1) pragma INTERFACE (LANGUAGE => FORTRAN, SUBPROGRAM => PROCEDURE_2); -- (2) ignored pragma INTERFACE (FORTRAN, PROCEDURE_3, "LINK_NAME"); -- (3) ignored The pragma in (1) is the language-defined INTERFACE pragma and is legal, the pragma in (2) is an implementation-defined extension of (1) that allows argument identifiers, and the pragma in (3) is a further extension in which another parameter is accepted. Does Ada permit such extensions of language-defined pragmas? | !recommendation 86-10-13 (DRAFT) | | An implementation is not allowed to extend language-defined pragmas. | | !wording 84-12-26 (DRAFT) | | !discussion 86-12-15 (DRAFT) 2.8(8) states: The pragmas defined by the language are described in Annex B: ... In addition, an implementation may provide implementation-defined pragmas, which must then be described in Appendix F. Use of the phrase "In addition" together with the fact that implementation-defined pragmas are described in a separate Appendix shows that implementation-defined pragmas are intended to have new names, i.e., the language-defined pragmas cannot be extended. Note that, in the above example, the pragmas at (2) and (3) are not allowed; the implementation should provide a warning message since the pragmas will therefore have no effect (2.8(9)). | Extending language defined pragmas DRAFT 87-08-06 AI-00317/06 2 !appendix 87-01-20 ***************************************************************************** | !section 02.08 (08) Peter Belmont 84-12-26 83-00485 | !version 1983 | !topic Overloading Pragmas | | 2.8(8) requires every implementation to support the pragmas | defined in Annex B. An implementation, whilst allowing all | forms of language defined pragmas, may also wish to allow | other (implementation defined) pragmas, perhaps even with | the same names as those of Annex B. | | Question(1): Does Ada permit overloading of user- or language- | defined pragma names? | | Recommendation(1): Since the RM seems silent on the subject, | let it be the interpretation of the RM that overloading | of pragmas is allowed, always as specified in an implementation's | Appendix F. | | Thus a program might, in the presence of a suitable Appendix F, | contain the following, none of which would be of "no effect" | (RM 2.8(9)): | | pragma INTERFACE(fortran, funny_proc); | pragma INTERFACE(language=>fortran, subp=>other_funny_proc); | pragma INTERFACE(fortran,third_funny_proc,"LINK_NAME"); | | Please notice that the predefined pragma INTERFACE is supported, | for the first line in the example corresponds to 13.9. | | The second form represents an implementation-defined overloading | of the predefined form, offering parameter names. | | The third form represents a further overloading in which another | parameter is accepted. | | Question (2): Assuming that overloading of pragma names is OK, | can an implementation-defined pragma whose name is the same | as that of a language-defined pragma enjoy the latter's | special properties? For example, the INTERFACE pragma | specifies a subprogram declaration for which, because of | the pragma, the supplying of a body in the Ada program is forbidden. | Can the various overloadings of the INTERFACE pragma | likewise specify and forbid? | | Recommendation(2): 2.8(8)/3 governs: An implementation-defined pragma | (whether or not overloading another pragma name) cannot be such | that its presence or absence influences the legality of the text outside | the pragma. Extending language defined pragmas DRAFT 87-08-06 AI-00317/06 3 | Question(3): Can an implementation, while supporting the language defined | pragmas as required, also offer other forms of the language-defined | pragmas, including names for parameters or extra parameters or both, | and offer them AS alternate forms of language-defined pragmas, thus | securing to them the special properties of the language-defined | pragmas? | | Discussion(3): In some implementations, a language-defined pragma | may not quite hit the mark. Thus, if the INTERFACE pragma requires | provision of extra information about the external subprogram body, | it is more convenient for the programmer to write: | | pragma INTERFACE(fortran,name, "LINK_NAME"); | | than to have to write: | | pragma INTERFACE(fortran,name); | pragma LINKNAME(name,"LINK_NAME"); | | It seems reasonable to allow implementation-defined variations | to the parameter-structure of language-defined pragmas which are | compatible with the purposes of the language-defined pragma, especially | if the language-defined forms are also allowed. | | Recommendation(3): Reasonable extensions and variations should be allowed. | | ***************************************************************************** | | !section 02.08 (09) M. Lott/M. Woodger Alsys 85-01-03 83-00490 | !version 1983 | !topic Re: Extending language defined pragmas | !reference 83-00485 | | We disagree with the recommendations made by Peter Belmont in his | comment. | | We interpret 2.8(1) as saying that the name of one pragma, in | particular the name of a language-defined pragma, cannot at the same | time be the name of another pragma, even if what follows the identifier | is different from what is allowed for the language-defined pragma. | | It follows from this that so-called overloading of the pragma identifier | is not allowed. | | Furthermore, 8.7(1) specifies explicitly when overloading is defined: | "for subprograms, enumeration literals, operators, and single entries, | and also for operations that are inherent in several basic operations | such as assignment, membership tests, allocators, the literal null, | aggregates, and string literals." | | So one cannot say that the RM is silent on the subject. Extending language defined pragmas DRAFT 87-08-06 AI-00317/06 4 | The examples given in this comment are illegal (8.3(4)). | | Michael, Mike | | ***************************************************************************** | | !section 13.09 (07) P. Hilfinger 85-07-30 83-00596 | !version 1983 | !topic Pragma INTERFACE with generic subprograms | | 13.9(7) notes that the INTERFACE pragm is not defined for generic | subprograms. Does this mean that it may not be defined? Suppose that | an implementor has a reasonable scheme for passing the generic formals to | a foreign subprogram (at least in some cases). How can he then declare | sugeneric subprograms? | | The issue here is to avoid the need for a body in these cases. | | ***************************************************************************** | | !section 02.08 (08) J.M.Orost [87-01-20] 86-12-12 83-00874 !version 1983 !topic Re: Extending language defined pragmas !reference AI-00317/02 We disagree with the draft recommendation that states: "An implementation is not allowed to extend language-defined pragmas." Our ANSI validated compiler (C3-Ada R00) supports the following pragma: pragma INTERFACE(FORTRAN, Name, IS_FUNCTION); We consider this as an overloading of the pre-defined pragma INTERFACE, and can be recognized as such by the fact that it has 3 arguments, while the pre-defined pragma INTERFACE has only 2. The notation above is more convenient for the programmer than requiring 2 pragmas, and it is also less error prone (e.g., both pragmas must be in the same declarative part). A compiler that doesn't support the overloaded pragma will reject it in the same fashion that it rejects unsupported pragmas. We strongly recommend that the implementation not be restricted unneccessarily. Ada supports overloading of procedure names, so why not pragma names? Extending language defined pragmas DRAFT 87-08-06 AI-00317/06 5 | ***************************************************************************** | | !section 2.8(8) | !version 1983 | !topic Commentary returned by Ada Board to LMP | | Version 05 was returned to the LMP by the Ada Board after it was argued that | providing extended INTERFACE pragmas is a great convenience to users and is | not clearly forbidden by the Standard.