From JKR@ib.rl.ac.uk Wed Jul 8 17:02:04 1992 Received: from danpost2.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA14445; Wed, 8 Jul 92 17:02:04 +0200 Received: from vm.uni-c.dk by danpost2.uni-c.dk (5.65/1.34) id AA19076; Wed, 8 Jul 92 17:00:23 +0200 Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with BSMTP id 1426; Wed, 08 Jul 92 17:02:31 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 4010; Wed, 08 Jul 92 17:02:30 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 9691; Wed, 08 Jul 92 16:01:49 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 1666; Wed, 08 Jul 92 16:01:37 BST Via: UK.AC.RL.IB; 8 JUL 92 16:01:06 BST Message-Id: <08 Jul 92 16:00:11 BST JKR@UK.AC.RL.IB> Date: Wed, 08 Jul 92 16:00:11 BST From: "JKR" (JKR at UKACRL) To: SC22WG5@dkuug.dk Subject: N786a (revised) X-Charset: ASCII X-Char-Esc: 29 N786a To: WG5 From: John Reid Subject: Clarifications and corrections to ISO/IEC 1539 Date: 8 July 1992 #Comment: Lines changed since the 30 June version start # 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. I have been working with a threshold of the present text being likely to lead to inconsistent implementations or serious user confusion. Some items are controversial, so I do not expect all to be approved. All the edits in S20.121 that have been approved by X3J3 are included. I propose that the final format be as here, except that the comments in square brackets are just for us and will be deleted. I hope that we can hone it by email ahead of the Victoria meeting. I would welcome comments on the format as well as the content. ............................................................... Corrigendum. Clarifications and corrections. #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.] 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). # 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. # [S20/15. 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.] 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. An example is (/ (CH(1:FUN(I)),K=1,L) /) where CH is a character variable, FUN is an integer function, and L has the value zero. 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. Discussion: It was intended that character declarations in type definitions be symmetrical with character object declarations. [S20/16.] 53/44. Change 'type declaration' to 'specification'. Discussion: The shape might be given in a DIMENSION statement. 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 Discussion: The intent of the committee was that implicit mappings are not accessible in an interface body through host association. # [S20.13. I am opposed to these two edits 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 ] 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. 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" 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). [S20/49.] 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.] 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," 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. [S20/45.] 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 ." Discussion: The intent of the committee was to disallow this situation. [S20/7. 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 has previously 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." ] 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: 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 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. 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. 248/41. In the last line on page 248 change "COMMON, EQUIVALENCE, or ENTRY statements" to "COMMON, or EQUIVALENCE statements". Discussion: There is no way that partial association for character entities may occur through the use of an ENTRY statement. [S20/51.] 254/25. Replace definition by 'A whose # contains a , a , or an that is followed by further component selectors.' Discussion: array%scalar is both a structure component and an array section.