From JKR@ib.rl.ac.uk Tue Jun 30 17:28:03 1992 Received: from danpost2.uni-c.dk by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA20283; Tue, 30 Jun 92 17:28:03 +0200 Received: from vm.uni-c.dk by danpost2.uni-c.dk (5.65/1.34) id AA26207; Tue, 30 Jun 92 17:26:23 +0200 Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R1) with BSMTP id 1627; Tue, 30 Jun 92 17:28:26 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 8877; Tue, 30 Jun 92 17:28:24 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 2981; Tue, 30 Jun 92 16:27:42 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 6965; Tue, 30 Jun 92 16:27:40 BST Via: UK.AC.RL.IB; 30 JUN 92 16:26:54 BST Message-Id: <30 Jun 92 16:26:23 BST JKR@UK.AC.RL.IB> Date: Tue, 30 Jun 92 16:26:23 BST From: "JKR" (JKR at UKACRL) To: SC22WG5@dkuug.dk Subject: N786a X-Charset: ASCII X-Char-Esc: 29 N786a To: WG5 From: John Reid Subject: Clarifications and corrections to ISO/IEC 1539 Date: 30 June 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. 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. 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 non-constant 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.] 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. 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 this edit 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. 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 further component selectors.' 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 non-constant 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.] 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 bounds, and corresponding array elements, in array element order, must be associated. 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. 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 array component selector> that is followed by further component selectors.' Discussion: array%scalar is both a structure component and an array section.