J3/97-252 Date: November 6, 1997 To: J3 From: Larry Rolison Subject: Specification and syntax for allowing named constants in a complex constant Background: ---------- At meeting 136 (our first meeting in Las Vegas - at Arizona Charlie's, remember?) in February 1996, Loren Meissner presented paper 96-042 "Five Proposed JOR Items" since we were trying (even then) to finalize the requirements for Fortran 2000. The 5th proposal of this paper became WG5 JOR item 94 "Extend Initialization of COMPLEX Variables". The requirement was stated as follows: Permit initialization of COMPLEX constants with named constant in either part. Alternatively, permit the intrinsic function CMPLX in initialization expressions. At meeting 137 (Las Vegas, May 1996), this subject was continued in paper 96-095 and shows up as "enhanced complex initialization" in the Fortran 2000 Development Plan that Jerry assembled. Paper 96-095 was again a (modified) copy of WG5 JOR item 94. The requirement statement was modified to: Permit a complex constant with a named constant as either the real part or the imaginery part (or both) [in an Initialization Expression]. Meeting 138 (Las Vegas, August 1996 - boy, was it hot!) began with Loren still listed as the "champion" for what is now Minor Technical Enhancement M.6 according to 96-115r4/r5, the Fortran 2000 Development Plan. However, after some discussion, Loren decided that writing the syntax and semantics for this version of the requirement were not precisely his cup of tea, so the underlying requirement was split (as indicated in the original statement of the requirement). The title of the WG5 item was changed to "Permit Type Conversion Functions in Initialization Expressions" in paper 96-132/r1 and the statement of the requirement became: In an initialization expression, permit a reference to one of the intrinsic functions INT, REAL, DBLE, or CMPLX, where each argument is an initialization expression. Meeting 139 (Las Vegas, November 1996) has the Fortran 2000 Development Plan starting as 96-115r6 and Loren listed as "champion" for Minor Technical Enhancement M.6. However, after a bunch of straw votes and redecisions on MTE's, etc., 96-115r6 was updated to 96-115r7 and included the new MTE M.17 "enhanced complex constants". I (more or less) volunteered to be the "champion". And that was a year ago. Where or where does the time go? Let us not note that the workplan indicates the specs were to be presented at the May 1997 meeting. After yet more "refinements" to the Fortran 2000 Development Plan and its ascension to Standing Document 010, the work item of permitting named constants in a complex constant is now listed as MTE M.17 in SD 010 (currently 97-010r3). Specification: ------------- [ This specification is adapted from J3/96-095. ] Permit a complex constant with a named constant as either the real part or the imaginary part (or both). Justification: Applications in such fields as electrical engineering and optics often make extensive use of complex numbers. It frequently happens that a particular real value is required both as a real constant and as the real or imaginary part of a complex constant value. The standard requires that the same literal constant must be written twice, because a named constant is not permitted as a part of a complex constant: REAL, PARAMETER :: Omega = 1.23e6 COMPLEX, PARAMETER :: J_Omega = (0.0, 1.23e6) This can lead to programming errors. A constant expression of complex type can be constructed with the intrinsic function CMPLX where either or both of the arguments are named constants. However, such an expression would only be permitted for initialization if the standard was changed to allow such intrinsic functions in initialization expressions (subject of other papers). But allowing named constants as part of a complex constant is useful wherever complex constants are currently allowed so providing this capability is the subject of this paper (and MTE M.17). If a complex constant was allowed to have a named constant as its real or imaginary part (or both), the above example could more safely be written as: REAL, PARAMETER :: Omega = 1.23e6 COMPLEX, PARAMETER :: J_Omega = (0.0, Omega) Another, perhaps more pragmatic, justification for this feature is that many (most?) Fortran processors already allow this extension. Incorporating it in the Fortran 2000 standard would be another step in standardizing common practice. Syntax: -------- Although it may at first be hard to get used to, given most people's notions of "literal" constant vs. "named" constant, I believe the most natural way to incorporate this facility in the language is to enhance the definition of . I choose this route (as opposed to the much more complex method of inventing a new BNF term and then incorporating it numerous places) based on the following: Even though a complex literal constant could itself contain named constants, the complex literal constant itself does not have a name, and therefore is a complex literal constant (opposed to being a named constant). This is similar in some respects to partially violating our concepts of a "constant" by being able to have a subobject of a literal constant. Most people would tend to think of a literal constant as being "indivisible". And yet allowing the notion of a subobject of a literal constant is a part of the language. Calling a complex constant that contains named constants a "literal constant" does not violate any definitions of "constant" or "literal constant" that I could find. For example, 2.4.3.1.2 Constant states: A constant with a name is called a {named constant} and has the PARAMETER attribute (5.1.2.1). A constant without a name is called a {literal constant}. The complex constant (real_part, imag_part), where "real_part" and "imag_part" are named constants, has no name, thus is a literal constant and does not violate the above definition. Turning to other sections of the standard, the following sentence from the paragraph at the bottom of the first page of section 6 caused me some concern at first: A literal constant is a scalar denoted by a syntactic form, which indicates its type, type parameters, and value. The "syntactic form" of 1 indicates it is an integer, 1.0 indicates it is of type real, and (1, 3.2) indicates it is of type complex. But I concluded that since the "syntactic form" of a complex constant was really just the fact that two numbers are enclosed in parens and that one must look at both the numbers to determine the data type, etc. anyway that allowing named constants in place of the numbers did not violate the cited sentence because one can still determine the data types, etc. from the definitions of the named constants. So I conclude this sentence need not be changed. Another worrisome place may be 7.1.6 Scalar and array expressions, particularly in the definitions of "constant expression". But "constant expression" is defined as: A {constant expression} is an expression in which each operation is intrinsic and each primary is (1) A constant or a subobject of a constant, Note that (1) uses the term "constant", not specifically "literal constant" or any other restricted syntactic form. The term "constant" includes both "literal constant" and "named constant" as defined by R305: R305 is or So I conclude that the definitions of expressions, and in particular constant expressions, need not be changed. In short, I conclude that there is no more ambiguity to (name, name) representing a complex constant than there is to (constant, constant) and thus the choice of allowing named constants in the definition of complex literal constant is the appropriate method of incorporating this feature into Fortran 2000. Begin Aside Some vendors allow parens around the output list of a WRITE statement as an extension. These vendors have already had to solve the problem of the such a list containing two numeric constants. Some vendors allow both this paren extension and the complex constant extension and have already had to solve the problem. Thus, these extensions already exist in the real world and the problems have already been solved so adding this form of the complex constant to the language should not be a great burden on existing Fortran implementations, even those with seemingly conflicting extensions. End Aside I propose the following syntax changes (not as edits yet); R417 is unchanged, included for completeness: R417 is ( , ) R418 is or or R419 is or or Constraint: Each named constant in a complex literal constant shall be of type integer or real. Constraint: A named constant shall not appear in a complex literal constant unless the named constant has been defined previously in the same scoping unit or is accessible by host association or by use association. (Given the rules already existing in the standard disallowing reference before definition, I don't think the second constraint is strictly needed but I wanted to be careful to avoid questions of locations where the constant could appear in a context that is not a reference context and have someone think that in these cases the named constant did not actually have to be defined. That is why I chose the word "appear" in the second constraint.) Edits: ------ To be determined. ---------------------------------------------------------------------------- Larry Rolison lrr@cray.com Cray Research, A Silicon Graphics Company 655F Lone Oak Drive Eagan, MN 55121 ----------------------------------------------------------------------------