From J.Reid@letterbox.rl.ac.uk Wed Aug 11 21:31:12 1993 Received: from danpost4.uni-c.dk by dkuug.dk with SMTP id AA10981 (5.65c8/IDA-1.4.4j for ); Wed, 11 Aug 1993 19:34:39 +0200 X400-Received: by mta danpost4.uni-c.dk in /PRMD=minerva/ADMD=dk400/C=dk/; Relayed; Wed, 11 Aug 1993 19:33:22 +0200 X400-Received: by /PRMD=uk.ac/ADMD= /C=gb/; Relayed; Wed, 11 Aug 1993 19:31:13 +0200 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Wed, 11 Aug 1993 19:31:50 +0200 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Wed, 11 Aug 1993 19:31:12 +0200 X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Wed, 11 Aug 1993 19:31:12 +0200 Date: Wed, 11 Aug 1993 19:31:12 +0200 X400-Originator: J.Reid@letterbox.rutherford.ac.uk X400-Recipients: SC22WG5@dkuug.dk X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9308111731.AA08272@numerical.cc] X400-Content-Type: P2-1984 (2) Content-Identifier: Vote on Varyi... From: " (John Reid)" Sender: J.Reid@letterbox.rl.ac.uk Message-Id: <9308111731.AA08272@numerical.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Vote on Varying Strings X-Charset: ASCII X-Char-Esc: 29 I am voting publicly because I want to draw your attention to what I see as deficiencies in the present draft. I do not think that the descriptions conform sufficiently well with those in 1539 nor are they of the same quality. Let me express my sympathy with Lawrie, who may be dismayed at this reaction from me. I voted against making the change because it took X3J3 at least a year to hone 13 into shape and I felt that it could not be done in a single meeting. Lawrie voted against it too. But now that we have decided to go this way, let's do it well. Already, the new decription has drawn my attention to effects that I had not noticed earlier. David has drawn my attention to the rules that essentially imply that if we vote yes now, we will not be able to fix it later. He says: JTC1 Procedures say: "A CD shall be advanced to DIS only if the text has been stabilized, consensus has been demonstrated (see ISO/IEC Guide 2 [not to hand] for definition of consensus), and the substantial support of the P-members of the SC has been obtained. The SC Secretariat shall submit the CD within a maximum of three months to the ITTF for registration and distribution as a DIS to NBs for approval. If the substantial support of the P-members is obtained in a SC the CD shall be submitted by the SC secretariat within a maximum of three months to the ITTF for registration and distribution as a DIS." Given that all the P-members of SC22 who are not active in Fortran are likely to vote "yes" on registration as a DIS, what this amounts to in effect is that after WG5 has forwarded the document to SC22 this time, assuming the WG5 letter ballot is positive, only minor editorial changes can be made. In other words, WG5 is likely shortly to lose editorial freedom over the document so now (before September 8) is the time to make known any misgivings. Please join me in voting no. Best wishes, John. .............................. Letter Ballot to move Varying Strings to DIS The question is: Do you approve WG5-N939 for submission to the SC22 Secretariat for registration as a draft international standard (DIS)? yes____ no___x_ If your vote is no, supply revisions to N939 that would change your vote to yes. The reason for my no vote is that many editorial changes are needed for the descriptions to conform with those in section 13 of ISO 1539 and to be of the same quality. I give my suggestions below. Global A. All procedure descriptions should conclude with one or more examples. This will be particularly helpful to the reader for the more complicated new procedures. Global B. The procedure descriptions should be in alphabetical order in a single section. The present grouping into sections 2.4, 2.5, 2.6, 2.7 should be replaced by short summaries as on page 184 and onwards of 1539. The texts already present at the heads of sections 2.3, 2.4, etc could be used as the basis for these summaries. Global C. Optional arguments should be flagged as in 1539, with a line titled 'Optional argument.' or 'Optional arguments.' at the front and each one should have '(optional)' when its name is used as a title. Global D. It is most misleading to describe all the procedures as transformational. This was done in 1539 for a small number of character procedures in order to restrict them to scalars. Actually, only REPEAT and TRIM are so categorized, and both of these could perfectly well be elemental in the new standard. I would like to see the 'Class' line removed from all the descriptions and a statement made in a new paragraph somewhere near the front to the effect that all the procedures and operators are defined for scalar arguments and have a scalar result. An alternative would be a new 'Class': Function with scalar arguments and scalar result. Global E. All functions in 1539 are 'pure' in the sense that they do not alter their arguments and this is continued in 1539-2. This should be stated early on and not repeated for every instance, which is not the style of 1539. It gives the reader the impression that this is a property of the new procedures that does not hold for the old ones, a very undesirable impression to give. Note however, that what happens to the arguments of subroutines must be specified for every argument. This is not done for the new subroutines. In particular, several arguments are unchanged without this being stated. Global F. Every bold title such as 'Result type', 'Result Value, etc should be followed by a full stop rather than a colon. Global G. Following every title 'Result type.' there should follow a capital letter. Global H. Requirements should be worded with 'must'. An example is to change 'is' to 'must be' on 5/25. Global I. The names of the arguments should be in upper case to increase compatibility with 1539. Global J. The 'Description' paragraphs should be copied exactly from 1539 where appropriate; otherwise they should, as in 1539, be in the form of a sentence with the procedure as implicit subject describing the function of the procedure (just look at the grammatical variation in the four descriptions on p 5!). vi/13. 'Straightforward' should be one word. 1/10. Remove second 'to'. 3/11. Change 'which' to 'that'. CHAR. The function should be renamed CHARACTER. It is very different from the CHAR of 1539 and is not the inverse of ICHAR. It should also be defined for string of type CHARACTER (technical comment). 5/11-19. The title on line 11 should be 'Result Type and Type Parameter.' and the descriptions should be rewritten to correspond. 4/8. Add full stop. 5/28-29. The description is insufficiently precise and loses the property of being the inverse of the present CHAR. I suggest (assuming that the new CHAR is renamed CHARACTER): The result value is ICHAR(CHARACTER(c)). 5/39-41. I suggest (same reason as for 5/28-29): The result value is IACHAR(CHARACTER(c)). An additional reason here is that I think we should be requiring consistency with the present function, including characters outside the standard (technical comment). 6/2-4. The description should be copied from 1539 (as is done for SCAN and VERIFY). This description suggests that the argument is altered. 6/24-27. The description should be copied from 1539. This description is less clear and longer. It is not immediately apparent to the reader that the meanings are the same. 6/37-40. The description should be copied from 1539. This description is less clear and longer. It is not immediately apparent to the reader that the meanings are the same. 7/8. INTEGER is in the wrong font. 7/12-14. I would prefer the description to be copied from 1539. At least the sentence 'A negative ...' must be removed (already said on line 9). 7/15-36. Separate descriptions of the four functions should be given, as in 1539. 7/31-36. I think we should be requiring consistency with the present functions for characters outside the standard, and therefore dislike the last sentence (technical comment). I suggest extending the new CHAR, renamed CHARACTER, to include the CHARACTER case and for LLT: The result value is LLT(CHARACTER(string_a),CHARACTER(string_b)) and similarly for the others. 8 and 9. The format of 1539 is for each argument to have a separate description. This is not done for INDEX, SCAN, or VERIFY. 8/14-25. The present wording is acceptable to me, but I prefer: The result value is INDEX(CHARACTER(string),CHARACTER(substring),back). 8/35. LOGICAL is in the wrong font. 8/39-46. The present wording is acceptable to me, but I prefer: The result value is SCAN(CHARACTER(string),CHARACTER(set),back). 9/11. LOGICAL is in the wrong font. 9/15-22. The present wording is acceptable to me, but I prefer: The result value is VERIFY(CHARACTER(string),CHARACTER(set),back). 9/34. VARYING_STRING is in the wrong font. 10 and 11. The text has not been converted to the format of 1539. For each argument, there should be a description of the data it must hold on input (if any) and how it is changed (or that it is unchanged). 12/22-23. Delete the sentence 'The remainder ...'. The description is much clearer without it. 12/45. Delete the sentence 'In all cases ...' (already said on line 44), if my suggestion of global deletions of this is not accepted. REPLACE. The description would be much clearer if cases (i) and (ii) were combined by making finish optional. This would allow the deletion of 13/3-12, which is a poor description since we are doing a replacement rather than an insertion. We need only add to 8/13-22 that the case with finish absent is treated as if it were present with the value start+LEN(substring)-1. 13/27. Change 'but' to 'and'. 13/45. After 'between' add 'positions'. 14/13. After 'between' add 'positions'. SPLIT. The text has not been converted to the format of 1539. For each argument, there should be a description of the data it must hold on input (if any) and how it is changed (or that it is unchanged).