From JKR@ib.rl.ac.uk Thu Jul 16 13:05:48 1992 Received: from danpost2.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA19747; Thu, 16 Jul 92 13:05:48 +0200 Received: from vm.uni-c.dk by danpost2.uni-c.dk (5.65/1.34) id AA06186; Thu, 16 Jul 92 13:04:08 +0200 Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with BSMTP id 0539; Thu, 16 Jul 92 13:06:21 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 8029; Thu, 16 Jul 92 13:06:19 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 4460; Thu, 16 Jul 92 12:06:59 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 1905; Thu, 16 Jul 92 11:14:49 BST Via: UK.AC.RL.IB; 16 JUL 92 11:10:40 BST Message-Id: <16 Jul 92 11:09:04 BST JKR@UK.AC.RL.IB> Date: Thu, 16 Jul 92 11:09:04 BST From: "JKR" (JKR at UKACRL) To: SC22WG5@dkuug.dk Subject: Final N786a X-Charset: ASCII X-Char-Esc: 29 N786a To: WG5 From: John Reid Subject: Clarifications and corrections to ISO/IEC 1539 Date: 16 July 1992 Introduction It is inevitable that a document such as ISO/IEC 1539 will contain errors and ambiguities. Anyone who has written a book will understand that if you want to get it out of the door in a timely fashion, some are inevitable. Remarkably few have come to light in this case. Nevertheless, WG5 has a responsibility to the community of compiler writers to 'maintain' the standard, so that they know exactly what is required of them. The BSI group therefore proposes that a document of 'clarifications and corrections' be officially adopted at Victoria and have asked for agenda time. The intention is that it be issued by ISO as a corrigendum to the standard. Attached is a draft. All the edits in S20.121 that have been approved by X3J3 are included. I have lifted the text mechanically so it should be identical. I propose that the final format be as here, except that the comments in square brackets are just for us and will be deleted. Another possibility would be to include the whole of each S20 item. ............................................................... Corrigendum. Clarifications and corrections. The following edits have been copied mechanically from the X3J3 document S20. This document also contains an explanation of the reasons for the changes. The item numbers are given in parentheses. 33/36. The fourth constraint after R429 should be: The character length specified by the in a or the in a (5.1, 5.1.1.5) must be a constant specification expression (7.1.6.2). (S20/15) [Discussion: A nonconstant specification expression specifies an automatic character object that may be declared only in a procedure or procedure interface. It was never the intention to permit the specification of automatic objects in type definitions. The fifth constraint for R429 prohibits the only other automatic object, an automatic array. By extrapolation, it could be assumed that the length specified in a character would be similarly restricted. The discussion is copied from S20. Larry Rolison wishes to delete the last sentence. He says I don't think we should be encouraging people to make assumptions based on extrapolations from the text of the standard. The standard should be specific and state what it means. I agree with him.] 42/29-33. The text following the constraints for R508 should be: The in a CHARACTER and the * in an or in a of a type definition specify character length. The * in an or specifies an individual length and overrides the length specified in the , if any. If a * is not specified in an or , the or specified in the is the character length. If the length is not specified in a or a * , the length is 1. (S20/16) [Discussion: It was intended that character declarations in type definitions be symmetrical with character object declarations.] 54/30. In section 5.3 change "A program unit" in the last sentence of paragraph 3 (preceding: "IMPLICIT INTEGER (I-N)...") to "A scoping unit that is not host associated (12.1.2.2.1)" 55/2-3. In the example in section 5.3 for FUNCTION FUN in the interface block the comment should be changed FROM: ! All data entities must ! be declared explicitly TO ! All data entities need not ! be declared explicitly (S20/13) [Discussion: The intent of the committee was that implicit mappings are not accessible in an interface body through host association. Janice Shepherd tells me that X3J3 at Terre Haute changed the first edit to 54/30. In section 5.3 after "a program unit" in the last sentence of paragraph 3 insert "or a procedure interface body" and the discussion to Discussion: It is anticipated that typically an interface body will be created from the text of an existing external procedure definition. To ensure that identical text describes an identical interface it is necessary that the same default implicit mapping be used, in addition to excluding the interface body from the effects of host association. I am opposed to these two edits (in either form) and set out my argument in 121-33, JKR-1. This is a copy of what I said there: The statement that 'The intent of the committee was that implicit mappings are not accessible in an interface body through host association.' is not correct in my view. The rules for IMPLICIT typing in nested scoping units were discussed at length in Albuquerque in March 1987 and resolved by the adoption (15-0) of 103-117, a joint paper by myself and Larry Rolison. The introduction says "Straw votes yesterday were strongly in favour of simplifying the default IMPLICIT rules so that a scoping unit in a host always has the host's IMPLICIT rules as its default. This proposal implements the change." The text that S20/13 proposes to change was adopted then and has remained unchanged ever since. Rather than using historical arguments, it should be demonstated that the standard is in error. It is my opinion that the current rules work. An interface body is a scoping unit (see 9/-4) and the scoping unit that immediately surrounds it is its host (see 10/1). There is no conflict with the first line of 12.1.2.2.1, which is talking about accessing named entities by host association, since an implicit mapping is neither named nor is it an entity. The default IMPLICIT rules are given on page 54 and illustrated on page 55. Larry Rolison wishes to replace the wording of the answer by: The intent of the commitee was that an interface body does not inherit the implicit mappings of its host. He says: I don't think the implicit environment has anything to do with host association and section 5.3 does not use the mechanism of host association to describe how the implicit environment of an inner scoping unit is inherited from its host. It simply says If a mapping is not specified for a letter, the default is the mapping in the host scoping unit. I think the answer should be rewritten to eliminate the reference to host association. Mike Metcalf says that if the send edit is accepted, the first line should be ! Not all entities need to ] 77/27. Section 7.1.6.1, page 77, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not a constant expression, and are not" 78/9. Section 7.1.6.1, page 78, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not a constant expression, and are not" (S20/49) [Discussion: It was the intent of the committee to include objects with nonconstant lengths in the restrictions on the LEN function in section 7.1.6.1 (pages 77 and 78).] 149/12. The following changes should be made to section 10.8.1: Add " and" to the end of item (4), and Add an additional item to the list after item (4): "(5) The character constant contains at least one character," (S20/45) [Discussion: The ambiguity between undelimited zero-length character values and the null value should be resolved by requiring that zero-length character values always be delimited in list-directed input.] 167/36+. Section 12.3.2.1 add a new constraint after other constraints: "Constraint: A can appear only once in a and can appear in only one ." (S20/7) [Discussion: The intent of the committee was to disallow this situation. I am opposed to this edit and set out my argument in 121-39, JKR-7. This is an unnecessary change to the standard. Repetitions of this kind are harmless. If the edit is to be retained, it should be reworded to use 'must': "Constraint: A must not appear more than once in a and must not appear in more than one in an ." or replaced to exclude other repeated inclusions of the same procedure name (see X3J3/90-095): "Constraint: A in a must not be one which previously had been established to be associated with the of the in which it appears, either by a previous appearance in an or by use or host association." ] 248/41. In the last line on page 248 change "COMMON, EQUIVALENCE, or ENTRY statements" to "COMMON, or EQUIVALENCE statements". (S20/51) [Discussion: There is no way that partial association for character entities may occur through the use of an ENTRY statement.] ..................................................................... To: WG5 From: John Reid Subject: Further clarifications and corrections to ISO/IEC 1539 Date: 16 July 1992 Introduction This is an independent effort to seek further clarifications and corrections. If they find favour with WG5, I hope that they will be sumbitted to X3J3 so that they can become S20 items. I have been working with a threshold of the present text being likely to lead to inconsistent implementations or serious user confusion. 22/6. After 'context' add 'or in a format specification'. Discussion: The format specification FORMAT(B N) is valid in free format source because section 10.1.1 states: Additional blank characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor... [S20/4. No edit is proposed by X3J3, but it is my opinion that the standard contradicts itself and that a correction is needed.] 38/14. After 'expressions.' add 'If the type is character and the sequence is empty, the character length of every expression must be constant.' Discussion: In this case, no expression is evaluated so there is no way to find the character length at run time. It needs to be known at compile time. For example, we need to exclude the case (/ (CH(1:FUN(I)),K=1,L) /) where CH is a character variable, FUN is an integer function, and L has the value zero. 53/44. Change 'type declaration' to 'specification'. Discussion: The shape might be given in a DIMENSION statement. 65/31. Replace line by 'An array section is an array subobject whose designator contains a , a , or an array component selector that is followed by at least one component selector.' Discussion: s%array is an array subobject that we do not call an array section, see 64/2-3. 135/20. After 'edit descriptor' add 'with or without a repeat specification'. Discussion: It was not intended to disallow 1P2E12.4. [S20/52. No edit is proposed by X3J3, but it is my opinion that a clarification is needed.] 178/20-21. Delete 'all be scalars ... length or'. Discussion: This was meant to catch the f77 character storage association case, but f77 requires either that they all be of assumed character length or all be of the same constant length, both caught as characteristics that agree (see lines 17-19). The text is causing confusion. 179/38+. Add: (5) If it is an array, it must not be supplied as an actual argument to an elemental procedure unless an actual argument that is present is an array of the same rank. Discussion: It was intended that the rank of an expression should never vary. 199/3+. Add the new paragraph, not indented because it applies to cases (ii) and (iii): For POINTER and TARGET to be currently associated, they must have the same type, type parameters, and rank. In the array case, they must have the same shape; and, when the size is nonzero, corresponding array elements, in array element order, must be associated. 199/7. After 'UBOUND(A,DIM=1)' add 'and the lower bound of A is 1'. Discussion. The definition of this intrinsic needs clarification. [S20/27. No edit is proposed by X3J3, but it is my opinion that a clarification is needed.] 203/23. Change '1,sh' to 'sh,1'. Discussion: Typographical error. 220/25. Delete comma before '[, MASK ='. Discussion: Typographical error. [See N785.] 234/7. After 'range' add 'and the value of X is nonzero'. Discussion: The definition for X=0 is missing. This change means that the case is covered by the 'otherwise' clause. 242/40. After 'with a different type,' add 'present as a subroutine instead of a function,'. 242/43. After 'with a different type,' add 'present as a subroutine instead of a function,'. Discussion: The present wording can be interpreted with the view that the type of a subroutine is 'none', but it is clearer to say this explicitly. 245/24. Add 'It must not be the name of a global or local constant in the same scoping unit.' Discussion: Fortran 77 does not permit the name to be that of a named constant and this was the intention for Fortran 90, too. 254/25. Replace definition by 'A whose contains a , a , or an that is followed by one or more further component selectors.' Discussion: array%scalar is both a structure component and an array section.