From jwagener@trc.amoco.com Wed Dec 9 08:14:54 1992 Received: from noc.msc.edu by dkuug.dk with SMTP id AA22633 (5.65c8/IDA-1.4.4j for ); Wed, 9 Dec 1992 21:15:15 +0100 Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA04614; Wed, 9 Dec 92 14:15:12 -0600 Received: from [149.180.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA16369; Wed, 9 Dec 92 14:15:05 -0600 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA28600; Wed, 9 Dec 92 14:14:59 CST Received: from crmac1 by trc.amoco.com (4.1/SMI-4.1) id AA18697; Wed, 9 Dec 92 14:14:54 CST Date: Wed, 9 Dec 92 14:14:54 CST Message-Id: <9212092014.AA18697@trc.amoco.com> From: Jerrold L. Wagener To: SC22WG5@dkuug.dk Subject: S20.123, items 91-121 X-Charset: ASCII X-Char-Esc: 29 NUMBER: 000091 TITLE: Constraint diagnosis for SEQUENCE attributes KEYWORDS: SEQUENCE, modules, constraints DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Must the following constraints be diagnosed when the criteria for the constraint is violated or confirmed across module definitions? More specifically should the following two constraints: The third constraint following R522: (p. 49/l. 26-28): A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility... The third constraint following R424: (p. 33/l. 10-11): If a component of a derived type is of a type declared to be private, either the derived type definition must contain the PRIVATE statement or the derived type must be private. be diagnosed in the following program?: MODULE a TYPE x INTEGER :: i END TYPE x TYPE y TYPE (x) :: r ! note component of type x END TYPE y CONTAINS FUNCTION f() ! module function of type x TYPE(x) :: f END FUNCTION f END MODULE a MODULE b USE a PRIVATE :: x ! note component of type y now has ! a private sequence attribute ! note also that module function f now ! has private attribute END MODULE b ANSWER: Discussion: REFERENCES: ISO/IEC 1539:1991 (E) sections 4.4.1, 5.2.3 and 1.4. EDIT: SUBMITTED BY: Maureen Hoffert HISTORY: Submitted at 123 in X3J3/92-225 -------------------------------------------------------------------------- NUMBER: 000092 TITLE: Pointer and Storage Association KEYWORDS: pointer association, Storage association, ASSOCIATED DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Consider the following example program: PROGRAM PROG INTEGER :: VAR COMMON /COM/ VAR VAR = 5 CALL SUB END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT PTR => TGT ... END SUBROUTINE SUB Is the pointer assignment legal? Although the entity named TGT was declared with the TARGET attribute, a storage associated entity, VAR, was not. ANSWER: ... Discussion: ... REFERENCES: ISO/IEC 1539:1991 (E) sections ... EDIT: None. SUBMITTED BY: Len Moss LAST SIGNIFICANT CHANGE: HISTORY: Issue arose during Victoria (1992) WG5 meeting, while reviewing various questions concerning 120.121(27) Separate request submitted following meeting 121 Submitted as X3J3/92-226 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000093 TITLE: Scalar Pointer Function Results KEYWORDS: function results, pointer attribute DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: May a scalar function result have the pointer attribute? ANSWER: ... Discussion: ... REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1.2.4.3 and ... EDIT: ... SUBMITTED BY: Len Moss HISTORY: Submitted as X3J3/92-227 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000094 TITLE: Varying length function result, implied-DO loop KEYWORDS: implied-DO, WRITE, function DEFECT TYPE: Interpretation STATUS: X3J3 draft response An example of an array-result function is: FUNCTION F(I) DIMENSION F(I) ... END Question 1: If this function is used in an output list with an implied-DO: WRITE(6,100) (F(I), I=1,N) Does the output list consist of N arrays of the array-result of function F(I) or does the output list consist of N array element references of F(I)? Question 2: A more complicated example is the use of a multidimensional array: FUNCTION F(I,J) DIMENSION F(I,J) ... END The function is used in an output list with an implied-DO: WRITE(6,100) ((f(I,J), I=1,N), J=1,K) Does the output list consist of N*K arrays of the array-result of function F(I)? Question 3: An example of a character variable-length array-result function is: FUNCTION F(I,J) DIMENSION F(I) CHARACTER(LEN=J) F ... END The function is used in an output list with an implied-DO: WRITE(6,100) ( ( F ( I, J ), I=1,N ), J=1,K ) Does the output list consist of N*K different sized arrays of varying character length function results? Question 4: Should an implied-DO loop in an output statement be restricted to a scalar function result? The DATA statement is limited to an array element, a , or a . See R536 in section 5.2.9. ANSWER: 1) The output list consists of N arrays of the array-result of function F(I). 2) Yes. 3) Yes. 4) No. REFERENCES: ISO/IEC 1539:1991 (E) sections 12.4, 12.4.2, and rule R1209. EDIT: None. SUBMITTED BY: Joanne Brixius X3J3/92-230 HISTORY: Submitted as X3J3/92-230 Approved as X3J3/92-292 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000095 TITLE: Varying length function result, implied-DO loop KEYWORDS: implied-DO, INQUIRE, IOLENGTH, function DEFECT TYPE: Interpretation STATUS: X3J3 draft response In section, 9.6.3, page 134, the INQUIRE with IOLENGTH specifier is described. The use of implied-DO and function references in an output list impacts the INQUIRE statement that used the IOLENGTH specifier with an output list. An example of a array-result function is: FUNCTION F(I) DIMENSION F(I) INTEGER I REAL F(I) ... END QUESTION 1: If the function is used in an output list with an implied-DO: INTEGER ISIZE INQUIRE(IOLENGTH=ISIZE) (F(I), I=1,N) Does the output list consist of N arrays of the array-result of function F(I) or does the output list consist of N array element references of F(I)? See Question 3. The function F(I) must be referenced N times to be able to determine the size of the result. The size of the function result cannot be determined by a declaration of the function in the caller. The function must be executed to determine the size of the result. QUESTION 2: An example of a character variable-length array-result function is: FUNCTION F(I,J) DIMENSION F(I) INTEGER I,J CHARACTER(LEN=J) F ... END The function is used in an output list with an implied-DO: INQUIRE(IOLENGTH=ISIZE) ( ( F ( I, J ), I=1,N ), J=1,K ) Does the output list consist of N*K different sized arrays of varying character length function results? The actual size of the result can only be determined by executing the function. QUESTION 3: Should an implied-DO loop in an INQUIRE statement with an IOLENGTH specifier be restricted to a scalar function result? The DATA statement is limited to an array element, a , or a . See R536 in section 5.2.9. This would allow the determination of the size of a function reference without actual execution of the function. ANSWERS: 1) The output list in the INQUIRE statement "references" the function "F" N times. Each reference returns an array valued result. This is not necessarily a reference in the sense of an actual function call. Your statement about referencing the function is not correct. An implementation is allowed to call the function if it so wishes, but is not required to do so. In the presence of an explicit interface it is possible some implementations will not call the function, or may call it fewer than N times. 2) The output list consists of N*K different sized arrays of varying length character function results. The implementation is not required to actually call the function. 3) No. REFERENCES: ISO/IEC 1539:1991 (E) sections 9.6.3, 7.1.7.1 EDIT(S): None. SUBMITTED BY: Joanne Brixius X3J3/92-231 LAST SIGNIFICANT CHANGE: HISTORY: Submitted as X3J3/92-231 Approved as X3J3/92-311 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000096 TITLE: Definition of "Declaration" KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: "Declaration" is a significant concept of Fortran 90. Section 5 is titled "Data object declarations and specifications" and what were in Fortran 77 "type statements" are now "type declaration statements". 5.1.1 says "A type specifier specifies the type of all entities declared in an entity declaration list." Nowhere, though, can I find a definition of "declaration". What does it mean, in Fortran 90, to "declare" something? ANSWER: We will add a definition of "declaration" to the glossary. For clarity, we will also add a definition of "specification". REFERENCES: ISO/IEC 1539:1991 (E) sections ..... EDIT: add to page 260 after "size" [260:14+] Specification: a specification assigns attributes and properties to named data objects. add to page 256 after "datum" [256:10+] Declaration: The process of specifying an attribute or a property of a named data object. SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-11 HISTORY: Submitted as X3J3/92-232 Draft response in X3J3/92232r, withdrawn for rconsideration -------------------------------------------------------------------------- NUMBER: 000097 TITLE: Specification Expression KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTIONS: In section 7.1.6.2 "Specification expression": 1. In item (9) should not the restriction "defined by an ALLOCATE statement" be "allocatable" instead? That is, the ALLOCATE statement does not have to exist, it is being allocatable -- even if never allocated -- that is restricted. [79:14-15] And the same comment re pointer assignment. [79:14-15] 2. Would Item (9) be clarified if "local" were inserted before "variable"? [79:14] 3. In the text beginning "and where any subscript ..." should not "is" be "must be"? As written it says that any subscript is a restricted expression. [79:17] 4. In the text beginning "A specification expression (R509, R514, R515)... should not the "(R509, R514, R515)" be deleted? ANSWER: 1. Yes, see edits below. Edits are provided for similar problems in other sections. 2. No. 3. No, this is part of a long and complex sentence which begins on the previous page. 'Is' is the correct form and parallels the rest of the sentence and describes what a restricted expression 'is', not what a subscript is. 4. There is redundancy, but not an error. REFERENCES: ISO/IEC 1539:1991 (E) sections ..... EDIT: Replace "defined by an ALLOCATE statement or pointer assignment" With "a variable that does not have the allocate or pointer attribute" in 7.1.6.1 (6), in the first list [77:27-28] 7.1.6.1 (6), in the second list [78: 9-10] 7.1.6.2 (9) [79:14-15] SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-11 HISTORY: Submitted as X3J3/92-233r at meeting 123 -------------------------------------------------------------------------- NUMBER: 000098 TITLE: KIND param and list directed I/O KEYWORDS: unit, data type DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: In an I/O record, can the kind-param of a constant be a named constant? ANSWER: No. Section 5.1.2.1 which describes where and when named constants are allowed does not discuss named constants in the context of an I/O record; therefore, named constants are not allowed in an I/O record. The edit below clarifies what the committee intended, by specifically addressing values in I/O records. REFERENCES: ISO/IEC 1539:1991 (E) section 5.1.2.1 EDITS: In section 5.1.2.1, after the sentence "A named constant must not appear within a format specification (10.1.1)." add the following sentence: "A named constant must not appear within an I/O record (9.1)." SUBMITTED BY: Joanne Brixius X3J3/92-234 HISTORY: Submitted as X3J3/92-234 Approved as X3J3/92-273r2 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000099 TITLE: Generic interfaces KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: 11.3.2, page 158, pp beginning "If two or more" says that: If two or more generic interfaces that are accessible in a scoping unit have the same name, ..., they are interpreted as a single generic interface. 14.1.2.4.1, page 244, says (1) If the reference ... of an interface block that has that name and either is contained in the scoping unit ... or is made accessible by a USE statement... (3) ... if the name is established to be generic in that host scoping unit ... Question 1: What section 11 seems to say will be treated as a single interface is, in Section 14, actually treated as individual interfaces. Which is correct? Question 2: If the text from 11.3.2 above applies to more than just USE association, should it be moved to 12.3.2.1 "Procedure Interface Block"? ANSWER: REFERENCES: ISO/IEC 1539:1991 (E) sections ..... EDIT: SUBMITTED BY: Dick Weaver HISTORY: Submitted as X3J3/92-236 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero sized objects KEYWORDS: Associated, Zero sized objects, Target, Pointer DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: S20.122 interpretation number 000027 states what conditions must be met for the two argument form of the ASSOCIATED intrinsic function to return a value of true. It does not state what the behavior of the intrinsic is for zero sized arguments. Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assigment statement. What is the output of this program? (Does a notion of "base address" come to play for zero sized objects as it does for nonzero sized?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWER: Discussion: REFERENCES: EDIT: SUBMITTED BY: Jon Steidel HISTORY: Submitted as X3J3/92-240 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress | rev 1. Replaced the list from Metcalf & Reid Ch 7 with the list derived from the syntax in 5.2 of Reid & Metcalf, per note from John & Mike. (listing it as Reid & Metcalf sometimes is a result of speaking from the end of many alphabetical listings myself!) | rev 2. Deleted FORMAT, ENTRY from Reid & Metcalf per e-mail suggestion. ----------------------------------------------------------------------------- QUESTION: The following list compares the specification statements from Fortran 77 (listed in chapter 8), those of Fortran 90 (R214, page8), | and those of Metcalf & Reid "Fortran 90 Explained" per e-mail. Fortran 77 Fortran 90 Metcalf&Reid access access ALLOCATABLE ALLOCATABLE | COMMON COMMON COMMON DATA DATA derived-type-def DIMENSION DIMENSION DIMENSION | EQUIVALENCE EQUIVALENCE EQUIVALENCE | EXTERNAL EXTERNAL EXTERNAL IMPLICIT IMPLICIT INTENT INTENT | interface-block | INTRINSIC INTRINSIC INTRINSIC NAMELIST NAMELIST OPTIONAL OPTIONAL PARAMETER PARAMETER POINTER POINTER SAVE SAVE SAVE | stmt-function TARGET TARGET type-stmt type-stmt USE I have in the past and I will in the future argue for changes in terminology -- where those changes better align Fortran with common usage in describing programming languages or facilitate the description of Fortran. However the changes above seem more accidental than intended and, I am convinced, will make a users transition to Fortran 90 more onerous than it need be. -- patterns learned in Fortran 77 will not carry forward, for no apparent reason -- complexity is increased. In describing Fortran 77 you could write "all specification statements must precede ..." (3-3, line 46). | | -- incompatible vendor documentation (some will follow the standard, some will pick up PARAMETER as M&R did, some will pick up EXTERNAL | as M&R did, ...) will make the writing of portable programs more difficult. Question 1: While reclassifying DATA as a specification statement seems an improvement, the deletions and not classifying some new statements (see M&R, above) as specifications seems unfortunate. Were these changes in terminology intended or an accidental result of incorporating statement sequencing rules into the BNF? Question 2: Do you want to reconsider? Question 3: In 11.3.3.1 page 159 should "A common block and all its associated specification statements be changed to: "................................................... and type-declaration ... Question 4: In 12.3.2 page 167 should "... and by specification statements for the dummy arguments ..." be changed to "........................ and type-declaration ....." Question 5: In 12.5.2.2 page 175, in the first constraint should "... any specification statement ..." be changed to "... any specification or type-declaration statement ..." Question 6: In 12.5.2.5 page 178, in the first constraint (same question as 5, above). ANSWER: 1) Yes. The changes in terminology were intended as a way to specify partially the statement ordering via the BNF. The effect of losing the easy way to specify "specification" statements was unintentional. 2) No. Reverting to the FORTRAN 77 style would not be a benefit at this time. This style will be reconsider in writing Fortran 9x, in particular the changes suggested in the question, items 3 through 6. EDITS: Section 11.3.3.1, [159:11] after "specification", add "and type-declaration" Section 12.3.2 [167:7] after "specification", add "and type-declaration" Section 12.5.2.2, first constraint, [175:36] after "specification" add "or type-declaration" Section 12.5.2.5, first constraint, [178:1] after "specification" add "or type-declaration" SUBMITTED BY: Dick Weaver HISTORY: 92-244r2 123 first submitted 92-325 123 initial response -------------------------------------------------------------------------- NUMBER: 000102 TITLE: Returned value for INQUIRE POSITION= on an empty file KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following two cases 1. Reading an empty sequential file OPEN ... POSITION='REWIND' !positioned at initial point READ ... END= !reads endfile record, positioned ! after endfile record BACKSPACE ... !positioned before endfile record ! which is also the initial point INQUIRE ... POSITION= 2. Writing an empty sequential file OPEN ... POSITION='REWIND' !positioned at initial point ENDFILE ... !write endfile record, positioned ! after endfile record BACKSPACE ... !positioned before endfile record ! which is also the initial point INQUIRE ... POSITION= In section 9.6.1.16, "POSITION= ..." appears to imply any of the following can be returned by the INQUIRE statement in these three cases: processor dependent - since the file has been repositioned REWIND - since the file is now at its initial point APPEND - since the file is now at its terminal point Thus even for implementations that are specified to use REWIND and APPEND, rather than a processor-dependent value, the standard would seem to be ambiguous. One implementation can return "REWIND" while another returns "APPEND". Is this ambiguity intended? ANSWER: Yes. If the file has been repositioned since the OPEN statement was executed, then the value returned by INQUIRE(POSITION=...) is processor-dependent. No particular value is required to be returned, but a few values are prohibited in certain cases. The processor is free to return any value that is not specifically prohibited by section 9.6.1.16. A standard-conforming program cannot depend on a particular value being returned in this case. If an implementation chooses to return "REWIND" or "APPEND" after a file has been repositioned, the file must currently be positioned at the same point as if it had just been opened with that same value for the POSITION specifier in the OPEN statement. An implementation must not return APPEND if the file is not positioned at its terminal point or endfile record. Similarly, it must not return REWIND if the file is not positioned at its initial point. This is not the same as saying that an implementation will return APPEND when the file is positioned at its terminal point. It need not. But if it does return APPEND, then the program can be assured that the file really is positioned at its terminal point or endfile record. REFERENCES: ISO/IEC 1539:1991 (E) Section 9.6.1.16 EDITS: None. SUBMITTED BY: Dick Weaver HISTORY: 92-245 rev2, 92-245 rev3 -------------------------------------------------------------------------- NUMBER: 000103 TITLE: Statement Function with unreferenced dummy argument KEYWORDS: DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Consider the following example F (A, B, C ) = A + B !statement function, dummy-arg C not used in expr INTEGER C Since "C" is implicitly typed, must any later type definition (the INTEGER C in the example) confirm that typing? ANSWER: Yes. This is covered in the second constraint in Section 12.5.4, page 182. While that constraint appears to be about the scalar-expr "A+B", the last sentence, beginning "If a scalar...", applies to the dummy arguments as well (the 2nd constraint combines what should have been two separate constraints). The constraint will be split and clarified. REFERENCES: ISO/IEC 1539:1991 (E) sections ..... EDIT: In section 12.5.4 split the second constraint at "If a scalar variable ..." [182:12] into a new constraint and add "dummy-arg," just before "scalar variable". SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-11 HISTORY: Submitted as X3J3/92-249 Approved as X3J3/92-249r at meeting 123 by a vote of 16-3 -------------------------------------------------------------------------- NUMBER: 000104 TITLE: Rounding formatted output KEYWORDS: rounding, formatted i/o DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION 1: The standard requires floating-point values to be rounded, on output (see 10.5.1.2.1 through 10.5.1.2.4). It does not, however, say how they are to be rounded. Always rounding up and always rounding down are allowed by the standard. Was that intended? QUESTION 2: The ISO/IEC 1539:1980 semantics for G edit descriptors assume that floating-point values are rounded down. The ISO/IEC 1539:1991 semantics for G edit descriptors assume that floating-point values are rounded to nearest. If those assumptions are violated, the implementation is sometimes required to print strings of asterisks for numbers that a user might think should be printed normally. If the interpretation is that implementations must always round to nearest, to which nearest value must they round in the case of a value exactly between two representable values? ANSWERS: 1) Yes. 2) No particular rounding method is required by the standard. The above analysis of the effect of this on output formatting using the G edit descriptor in a formatted write statement is correct. This change from FORTRAN 77's behavior was made in order to suggest a particular preferred implementation, namely, round to nearest. The committee believed that this change would promote portability of programs and consistency in implementations of I/O libraries, without actually requiring any particular rounding method. The standard's description for selecting between E and F editing, when the user specified a G edit descriptor, assumes that if a value to be printed is exactly between the two numbers obtained by rounding the original value up and down (to the appropriate number of decimal digits), then the magnitude of the value printed will be the absolute value of the original value rounded up. REFERENCES: ISO/IEC 1539:1991 (E) sections 10.5.4.1.2 EDITS: None SUBMITTED BY: Robert Corbett, X3J3/92-268 LAST SIGNIFICANT CHANGE: HISTORY: Submitted as X3J3/92-268 Approved as X3J3/92-299 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000105 TITLE: Parallel Evaluation of Operands and Arguments KEYWORDS: expression, operand, argument, function, parallel, concurrent DEFECT TYPE: Amendment STATUS: X3J3 consideration in progress QUESTION: Does Fortran permit concurrent evaluation of operands in expressions and of actual arguments of functions? ANSWER: Yes. Discussion: The evaluation of a subexpression is not allowed to "affect" the value of another part of the same statement (ISO/IEC 1539:1991 (E) section 7.1.7). Further, processors are permitted "considerable flexibility" to evaluate expressions "in the most efficient way possible" including flexibility in "the order of argument evaluation" (Section C.12.5). Part of the rationale is to provide "latitude for optimization (for example, for parallel processing)" (Section C.12.5). Opportunities for optimization in the form of parallel computation exist in expressions with more than one operand or actual argument. Fortran permits such optimizations, and the standard should make this as clear as possible. This will increase the likelihood that emerging implementations on parallel systems will take full advantage of their capabilities. The lack of restrictions on the order in which function arguments are evaluated is implicit in Sections 7.1.7 and 12.4.2 and explicit in Section C.12.5. All three sections imply that concurrent evaluation is also an option. The following edits will clarify the point. The edits to Section 12.4.2 will help avoid confusion on the option of delaying argument evaluation (currently elucidated in Section C.12.5), and the edits to Section C.12.5 will give the option of concurrent argument evaluation the same level of attention as options on order and timing. Taken together, the edits will make it clear that Fortran processors can overlap the evaluation of operands and function arguments when this enhances efficiency, such as, for example, when a processor has access to multiple arithmetic processing units or pipelines. REFERENCES: ISO/IEC 1539:1991 (E) Sections 7.1.7, 12.4.2, & C.12.5 EDIT(S): 1. In Section 12.4.2, replace the second sentence, by "When it is invoked, the arguments are associated, and then the function is evaluated." 2. In Section 12.4.2, third sentence: replace the term "executed" with "evaluated". 3. In Section C.12.5, paragraph 4, second sentence: replace the phrase "evaluating an operand" by "evaluating an actual argument or operand". 4. In Section C.12.5, paragraph 4, replace the third sentence by "The flexibility also includes the order of operand or argument evaluation and concurrent operand or argument evaluation." SUBMITTED BY: R. L. Page LAST SIGNIFICANT CHANGE: , requestor's original draft HISTORY: -------------------------------------------------------------------------- NUMBER: 000106 TITLE: Multiple USE of modules; renaming rules KEYWORDS: USE, modules, accessibility, renaming DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress - content challenged QUESTION: Section 11.3.2 states More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, all public entities in the module are accessible and the rename-lists and only-lists are interpreted as a single concatenated rename-list. If all the USE statements have ONLY qualifiers, only those entities named in one or more of the only-lists are accessible, that is, all the only- lists are interpreted as a single concatenated only-list. Assume the following module definition in considering the following questions. MODULE MOD INTEGER I, J, K END MODULE Question 1: If the following USE statements appear in a scoping unit, by what names are I and J accessible? USE MOD USE MOD, ONLY: X => I USE MOD, ONLY: Z => J The rules quoted above state in this case all public entities are accessible since one of the USE statements is without an ONLY qualifier. By concatenating the only-lists and rename-lists on a single rename list we have USE MOD, X => I, Z => J Is I accessible through both the name I and X, and is J accessible through both the name J and Z? Question 2: Same as question 1 without the ONLY clause. Here, all the USE statements are without ONLY clauses. USE MOD USE MOD, X => I USE MOD, Z => J Because MOD appears in a USE statement without a rename-list, are all public entities from MOD accessible by their declared name in MOD as well as any local names given in the rename-lists? That is, is I accessible by both I and X, and J accessible by both J and Z? ANSWER: In both examples, I is made accessible only as X, and J is made accessible only as Z. Discussion: As indicated by the text cited in 11.3.2, the USE statements in a scoping unit that reference a particular module are to be interpreted collectively, not individually. REFERENCES: ISO/IEC 1539:1991, sections 11.3.2 EDIT: none SUBMITTED BY: Jon Steidel HISTORY: Initially drafted as X3J3/92-246 Response proposed in X3J3/92-279 - meeting 123 vote (12-4) insufficient to approve -------------------------------------------------------------------------- NUMBER: 000107 TITLE: USE renaming of generic and specific interfaces KEYWORDS: USE, module, generic name, specific name, interfaces, renaming DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: A module contains a generic interface whose name matches the name of a specific interface defined in the interface block defining the generic interface. When the module is used, the name of the generic interface appears in a rename-list on the USE statement. Does the rename apply also to the specific interface? For example: MODULE MOD INTERFACE GEN SUBROUTINE GEN (A, B) REAL A, B END SUBROUTINE END INTERFACE END MODULE SUBROUTINE USER (X) USE MOD, RENAME => GEN ! Renames generic and specific GEN DIMENSION GEN (100) ! Legal to have local variable by name GEN? ... END SUBROUTINE ANSWER: Yes, the rename also applies to the specific name. Discussion: In the example, RENAME is the local name in USER which refers to the same entity that the name GEN refers to in MODULE. The name GEN is free to be used for other purposes in USER. REFERENCES: ISO/IEC 1539:1991, sections 11.3.2 EDIT: none SUBMITTED BY: Jon Steidel HISTORY: Initially drafted as X3J3/92-247 Response proposed in X3J3/92-282 - approved by unanimous consent at meeting 123 -------------------------------------------------------------------------- NUMBER: 000108 TITLE: Referencing disassociated pointers KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: There are several places in the standard that refer to whether a disassociated pointer can be referenced. The places seem to be inconsistent in the restrictions they place on such references. In section 5.1.2.4.3 "The size, bounds, and shape of the target of a disassociated array pointer are undefined. No part of such an array may be defined, nor may any part of it be referenced except as an argument to an intrinsic inquiry function that is inquiring about argument presence, a property of the type or type parameters, or association status." In section 5.2.7 "An object that has the POINTER attribute must not be referenced or defined unless, as a result of executing a pointer assignment (7.5.2) or an ALLOCATE statement (6.3.1), it becomes pointer associated with a target object that may be referenced or defined." In section 7.1.4.1 "If the pointer is not associated with a target, it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer." In section 7.5.2 "A pointer must not be referenced or defined unless it is associated with a target that may be referenced or defined." In section 13.7.2 "The inquiry functions RADIX, DIGITS, MINEXPONENT, MAXEXPONENT, PRECISION, RANGE, HUGE, TINY, and EPSILON return scalar values related to the parameters of the model associated with the types and kind type parameters of the arguments. The value of the arguments to these functions need not be defined, pointer arguments may be disassociated, and array arguments need not be allocated." (1) Where exactly can a pointer that is disassociated be referenced? (2) Can array pointers that are disassociated be referenced in more places than scalar pointers that are disassociated? (3) Can a pointer with an undefined association status ever be referenced? (eg as the argument to the KIND intrinsic in a PARAMETER statement). ANSWER: REFERENCES: EDIT: SUBMITTED BY: Janice C. Shepherd HISTORY: Submitted as X3J3/92-258 at meeting 123 -------------------------------------------------------------------------- NUMBER: 000109 TITLE: Intrinsic Function ASSOCIATED KEYWORDS: DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The description of ASSOCIATED (section 13.13.13) fails to specify that the result is scalar. Is this an oversight? Or is there some way in which an array-valued result can be returned? ANSWER: The result returned by ASSOCIATED is always scalar. The following edit makes this clear. EDIT: In 13.13.13 in the specification of the result type, add "scalar" after "default logical". REFERENCES: ISO/IEC 1539:1991(E) Section 13.13.13 SUBMITTED BY: Graham Barber LAST SIGNIFICANT CHANGE: 1992 11 11, new HISTORY: Originally submitted as X3J3/92-264 Response proposed in X3J3/92-317 - approve by (18-1) vote at meeting 123 -------------------------------------------------------------------------- NUMBER: 000110 TITLE: Named Constant Shape Specification KEYWORDS: statement ordering, type declaration statement, named constant, PARAMETER statement shape, DIMENSION statement, attribute specification DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: The standard seems inconsistent in that the following appears valid SUBROUTINE SUB ( ) REAL, PARAMETER :: R = 1 DIMENSION R (2) END while the following appears not to be SUBROUTINE SUB ( ) PARAMETER (R = 1) DIMENSION R(2) END Was this the intent? ANSWER: No, both are illegal. Discussion: Section 5.2 states,"All attributes (other than type) may be specified for entities, independently of type, by single attribute specification statements. The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification." Section 5.2.10 places the following restriction on objects named in a PARAMETER statement: "The named constant must have its type, shape, and any type parameters specified either by a previous type statement in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit." While the restriction is stated in the section titled, "The PARAMETER Statement", it applies to all objects with the parameter attribute. Objects with the parameter attribute may appear in subsequent specification expressions and initialization expressions. Because of this, the committee chose to require the shape of an object with the parameter attribute to be known before it is initialized and thus before it can appear in subsequent specification and initialization expressions. REFERENCES: ISO/IEC 1539:1991 sections 5.2 and 5.2.10. EDITS: none SUBMITTED BY: Peter Griffiths HISTORY: Initially drafted as X3J3/120-100 Submitted as X3J3/92-289 at meeting 123 Approved at meeting 123 (17-2) -------------------------------------------------------------------------- NUMBER: 000111 TITLE: Array constructors in masked assignment statements KEYWORDS: array constructors, masked assignment statements, WHERE DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: The description of masked array assignments (section 7.5.3.2, p 93) does not specify how an array constructor referenced in such an assignment is evaluated. The basic question to be answered is: "Is the evaluation of an array constructor controlled by the ?" I believe that the answer should be no since there are some array constructors where evaluation on an element by element basis is not possible; e.g., (/ MATMUL(A,B) + 1 /) There are also array constructors where it is hard for a compiler to select a particular element for evaluation; e.g., (/ (( A(1:J:I), I=1,J), J=M,N) /) Note that unmasked evaluation of array constructors, although in my mind the correct interpretation, will introduce some interesting semantics; e.g., consider the following two statements: where (A .NE. 0) B = 1/A (S1) where (A .NE. 0) B = (/ 1/A /) (S2) Execution of these two statements may lead to divide by zero overflow for (S2) but not for (S1)! ANSWER: Discussion: REFERENCES: ISO/IEC 1539:1991(E) section 7.5.3.2. EDIT(S): none SUBMITTED BY: Graham Barber LAST SIGNIFICANT CHANGE 92 11 13 HISTORY: Submitted as X3J3/92-264, part (2), at meeting 123 Response in 92-293 rejected at meeting 123 (10-10) -------------------------------------------------------------------------- NUMBER: 000112 TITLE: Sequence Derived Type External Functions KEYWORDS: DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress - content challenged QUESTION: Can an external function of sequence derived type be declared with a TYPE specification in the FUNCTION statement? For example, is the following a valid code fragment? TYPE (T) FUNCTION F () TYPE T SEQUENCE INTEGER I, J END TYPE T ... END ANSWER: Yes, the code fragment is valid, as an external function of sequence derived type can be declared with a TYPE specification in its FUNCTION statement. Discussion: The second paragraph of 12.5.2.2 indicates the only two conditions under which the attributes of a function result must be specified by specification statements within the function body. "If the function result is array-valued or a pointer, this must be specified by specifications of the name of the result variable within the function body." It was not intended that the syntax of allowing TYPE on a FUNCTION statement be limited to internal and module functions. The last sentence of the first paragraph of 5.1.1.7 should not be applied to function results. An edit is included for clarification. REFERENCES: 5.1.1.7, 12.5.2.2. EDIT(S): Add after the last sentence of the first paragraph of 5.1.1.7: "If the data entity is a function result, the derived type can be specified on the FUNCTION statement providing the derived type is defined within the body of the function or is accessible there by use or host association." SUBMITTED BY: Janice C. Shepherd, 92-130. HISTORY: Draft response proposed in 92-298 - (14-4) vote at meeting 123 insufficient for approval -------------------------------------------------------------------------- NUMBER: 000113 TITLE: Ordering of Array Specification and Initialization KEYWORDS: statement ordering, type declaration statement, initialization, shape, DIMENSION statement, attribute specification DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Fortran 90 requires that an array initialized via a DATA statement must have its array properties established by a previous specification expression (5.2.9). When an array is initialized via an =initialization-expr specification in a type declaration statement, however, there is no such requirement. For example, the code fragment, INTEGER :: I DATA I /2*1/ DIMENSION :: I(2) is prohibited by the standard, whereas the similar fragment, INTEGER :: I = (/1,1/) DIMENSION :: I(2) appears to be permitted. Is the lack of such a requirement when initializing an array in a type declaration statement an error in the standard? ANSWER: No, this difference between the DATA statement and an initialization-expr in a type declaration statement was intended. Discussion: The DATA statement does not provide complete information about the array properties of the objects it initializes; in particular, the size and shape of an array cannot be determined from DATA statements. The committee decided that permitting this information to be provided after the DATA statement would make certain implementation models very difficult. On the other hand, initialization of an array in a type declaration statement must obey a different set of requirements, namely, the intrinsic assignment conformance rules (5.1, 7.5, 7.5.1.4). There are two cases: 1) If the initialization-expr is an array, the object being initialized must be an array with identical shape. The subsequent explicit declaration of the shape of the array must confirm the shape deduced from that of the initialization-expr. 2) If the initialization-expr is a scalar, the shape of the object being initialized is not determined, but there is only a single value that must be preserved until the shape has been determined in a subsequent declaration statement. In the judgment of the committee, this did not constitute a serious obstacle to efficient implementation. The committee therefore chose instead to permit this construction in the interest of avoiding unnecessary restrictions on statement ordering. REFERENCES: ISO/IEC 1539:1991 sections 5.2.9, 5.1, 7.5 and 7.5.1.4. EDITS: none SUBMITTED BY: Peter Griffiths LAST SIGNIFICANT CHANGE: 13 Nov 92 Response rejected at meeting 123 (8-12) HISTORY: Initially drafted as X3J3/120-62 (120-LJM-2a) Resubmitted as X3J3/92-287 Response in X3J3/92-287r rejected at meeting 123 (8-12) -------------------------------------------------------------------------- NUMBER: 000114 TITLE: Named Constant Attribute Specification KEYWORDS: statement ordering, type declaration statement, named constant, PARAMETER statement, shape, DIMENSION statement, attribute specification statement DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The standard seems inconsistent in that the program unit SUBROUTINE SUB ( ) REAL, DIMENSION (2) :: R PARAMETER (R = 1) END appears to be valid while the program unit SUBROUTINE SUB ( ) DIMENSION R(2) PARAMETER (R = 1) END does not appear valid as section 5.2.10 states, "The named constant must have its type, shape, and any type parameters specified either by a previous occurrence in a type declaration statement in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit." Was it intended that one case be legal while the other is not? ANSWER: No, that was not the intent; both program units are legal. Discussion: Section 5.2 states,"The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification." Section C.5.1 also supports this intent. Thus there is evidence in the standard that the same restrictions should be applied to objects independent of whether their attributes were specified in a type declaration statement or an attribute specification statement. The edit below clarifies this intent by changing the statement in section 5.2.10 quoted above. REFERENCES: ISO/IEC 1539:1991 sections 5.2.10, 5.2, and C.5.1 EDITS: Section 5.2.10, replace the first sentence following the constraints with, "The named constant must have its type, shape, and any type parameters specified either by previous type declaration or attribute specification statements in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit." SUBMITTED BY: Peter Griffiths HISTORY: Initially drafted as X3J3/120-99 Submitted as X3J3/92-288 at meeting 123 Approved at meeting 123 (UC) -------------------------------------------------------------------------- NUMBER: 000115 TITLE: Multiple dummy arguments DEFECT TYPE: Interpretation KEYWORDS: STATUS: X3J3 draft response QUESTION: Section 12.5.2.5 implies that a dummy argument in an ENTRY statement can also appear in the subprogram's FUNCTION or SUBROUTINE statement. That is, the following is standard conforming: SUBROUTINE S(A,B,C) ... ENTRY SE(A,B) ... END SUBROUTINE Does this imply that an entity can occur multiple times in a single list? For example, FUNCTION F(A,B,A) ... END FUNCTION SUBROUTINE S( ) ... ENTRY SE(C,D,C) ... END SUBROUTINE ANSWER: Section 14.1.2 indicates that these program fragments are invalid. Discussion: Section 14.1.2 lists named variables as a class (1) entity. The section also indicates that a name that identifies a local entity of one class must not be used to identify another local entity of the same class. When a dummy argument appears in both an ENTRY statement and a subprogram FUNCTION or SUBROUTINE statement, the name denotes the same local entity and not two different entities of the same class. In the program fragments shown, the entity denoted by the first A is not the same entity as the second A. A similar statement can be made for the entities denoted by C. In both cases, the fragments are attempting to use the same name for two entities of the same class and are therefore invalid. REFERENCES: ISO/IEC 1539:1991 (E) section 14.1.2 EDIT(S): None SUBMITTED BY: LAST SIGNIFICANT CHANGE: 1992-11-11, new HISTORY: Discussed in e-mail 92-048 (pg 27-29,30-34) Response proposed in X3J3/92-295 - approved by unanimous consent at meeting 123 -------------------------------------------------------------------------- NUMBER:000116 TITLE: Scoping Units and statement labels KEYWORDS: Scoping units, statement labels, hosts DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Question 1: When does the scope change from the host to an inner scope? It makes a difference in determining when a label is a duplicate of another label in the same scope. Question 2: In the following example, are the labels considered duplicates thus making the program not standard conforming? PROGRAM EX1 10 INTEGER I 20 TYPE T 10 INTEGER T1 20 REAL T2 30 INTEGER T3 30 END TYPE Question 3: In the following example, are the labels not considered duplicates as the INTERFACE and END INTERFACE statements are in the host scope while the two interface bodies each have their own scope? PROGRAM EX2 10 INTEGER I 20 INTERFACE 10 SUBROUTINE S(A) 20 REAL A 30 END SUBROUTINE 10 FUNCTION F (AA) 20 REAL AA 30 END FUNCTION 30 END INTERFACE Question 4: In the following example, are the labels not considered duplicates since the internal subroutine and function are separate scoping units? MODULE 10 INTEGER I ... 20 CONTAINS 10 SUBROUTINE INNER1 ( ) 20 I = I + 1 30 END SUBROUTINE 10 FUNCTION F ( ) 20 F = 4.5 30 END FUNCTION 30 END MODULE ANSWER: Answer 1: In 2.2 a scoping unit is defined. The syntax rules for a derived type definition, a procedure interface body, and a program unit or subprogram define the extents of scoping units. Thus the TYPE, END TYPE, PROGRAM, END PROGRAM, MODULE, END MODULE, BLOCK DATA, END BLOCK DATA, SUBROUTINE, END SUBROUTINE, and FUNCTION, END FUNCTION define the beginning and end of such scoping units. Answer 2: The example is not standard conforming because there are duplicate labels in the scoping unit of the derived type since the TYPE statement is part of the derived type. Answer 3: The example is standard conforming and does not have duplicate labels. Answer 4: The labels for the internal subroutine and function are not considered duplicates since they are in separate scoping units. REFERENCES: ISO/IEC 1539:1991 (E) section 2.2 [9] EDITS(S): None SUBMITTED BY: Janice Shepherd LAST SIGNIFICANT CHANGE: 1992-11-13 HISTORY: 92-304 (Meeting 123) - approved by unanimous consent at meeting 123. -------------------------------------------------------------------------- NUMBER: 000117 TITLE: A clarification request on generic interfaces KEYWORDS: interface block, module procedure DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The second constraint in section 12.3.2.1 appears to indicate that the following program fragment is not standard conforming. Is the following code fragment standard conforming? MODULE MOD CONTAINS SUBROUTINE SUB1(I) ... END SUBROUTINE SUB1 END MODULE PROGRAM MAIN USE MOD CALL INNER CONTAINS SUBROUTINE INNER INTERFACE SUB MODULE PROCEDURE SUB1 END INTERFACE ... END SUBROUTINE END PROGRAM ANSWER: Yes. The program fragment is standard conforming. Discussion: There are several defects in the second constraint of section 12.3.2.1. First, the constraint should not restrict the program fragment that is shown nor similar ones involving generic interfaces in internal procedures within module subprograms. Second, the constraint implies that an is a scope, when it is not. An edit is included to correct these defects. REFERENCES: ISO/IEC 1539:1991 (E) Section 12.3.2.1. EDIT: Replace the second constraint in section 12.3.2.1 with "The MODULE PROCEDURE specification is allowed only if the has a and is contained in a scoping unit where each is accessible as a module procedure." SUBMITTED BY: Y. Yoshida LAST SIGNIFICANT CHANGE: 1992-11-12, new HISTORY: Question posed in X3J3/92-132 items 63,64. Response proposed in X3J3/92-318; not formally considered at meeting 123 due to a lead time problem -------------------------------------------------------------------------- NUMBER: 000118 TITLE: Named constructs and host association KEYWORDS: DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 12.1.2.2.1 defines when a name appearing in a scoping unit is the name of a local entity, making inaccessible any entity of the host that has the same name as its nongeneric name. Should the appearance of a name as a construct name be on the list? ANSWER: Yes. Discussion: Section 14.1.2 indicates that construct names are local entities. An edit is included to add construct names to the list in section 12.1.2.2.1. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.1.2.2.1 and 14.1.2. EDIT: Add new item to the list in section 12.1.2.2.1: "(16) The name of a named construct" and adjust the list punctuation accordingly. SUBMITTED BY: P. Griffiths LAST SIGNIFICANT CHANGE: 1992 11 12, new HISTORY: Submitted as a request in X3J3/92-132 item 68. Response proposed in X3J3/92-319 - approved by unanimous consent at meeting 123. -------------------------------------------------------------------------- NUMBER: 000119 TITLE: Rank of assumed-shape array KEYWORDS: Rank, assumed-shape, array, argument DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Must the rank of an assumed-shape dummy argument match that of the corresponding actual argument? Discussion: The fourth paragraph of section 12.4.1.1 indicates that if a dummy argument is a pointer, the actual argument must be a pointer and their ranks must agree. No similar statement appears to exist for assumed-shape arrays. ANSWER: Yes. The rank of an assumed-shape dummy argument must match that of the actual argument. This is implied by the statement in 5.1.2.4.2 that an assumed-shape array takes its shape from the associated actual argument array. An edit is included to clarify this restriction. REFERENCES: ISO/IEC 1539:1991 (E) sections 12.4.1.1 and 5.1.2.4.2 EDIT: At the end of the first paragraph of section 12.4.1.1 [172:41], add: "If the dummy argument is an assumed-shape array, the rank of the dummy argument must agree with the rank of the actual argument." SUBMITTED BY: A. Meyer LAST SIGNIFICANT CHANGE: 1992 11 12, new HISTORY: Submitted as a request in X3J3/92-132 item 69. Response proposed in X3J3/92-320 - approved by unanimous consent at meeting 123. -------------------------------------------------------------------------- NUMBER: 000120 TITLE: PRESENT intrinsic and host association KEYWORDS: PRESENT, host association, optional DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can the PRESENT intrinsic be called from an internal procedure with an argument that is an optional dummy argument of its host? For example SUBROUTINE HOST(OPT) REAL, OPTIONAL :: OPT ... CONTAINS SUBROUTINE INNER ( ) IF (PRESENT (OPT) ) THEN ... ANSWER: Yes. Discussion: As long as the optional dummy argument is accessible it can be used as an argument to the PRESENT intrinsic. An edit is provided for clarification. REFERENCE: ISO/IEC 1539:1991 (E) Section 13.13.80 EDIT: Replace the description of Argument in 13.13.80 with "A must be the name of an optional dummy argument that is accessible in the procedure in which the PRESENT function reference appears." SUBMITTED BY: J. C. Shepherd LAST SIGNIFICANT CHANGE: 1992 11 11, new HISTORY: Question and proposed response first appeared in X3J3/92-321 -------------------------------------------------------------------------- NUMBER: 000121 TITLE: ";" As a Statement Separator KEYWORDS: Separator, ";" DEFECT TYPE: Amendment STATUS: X3J3 consideration in progress Question: Are the following cases legal? 1) C = A ; + B 2) F = ; & G 3) ; P = Q ANSWER: SUBMITTED BY: Paul St. Pierre, 119-PSP-1 LAST SIGNIFICANT CHANGE: HISTORY: 119-PSP-1 (initial submission) X3J3/92-284 (considered at meeting 123) --------------------------------------------------------------------------