From jls@liverpool.ac.uk Wed Sep 1 18:12:59 1993 Received: from mail.liv.ac.uk by dkuug.dk with SMTP id AA28662 (5.65c8/IDA-1.4.4j for ); Wed, 1 Sep 1993 18:12:59 +0200 Received: from 138.253.31.200 by mailhub.liverpool.ac.uk with SMTP (PP) id <16556-0@mailhub.liverpool.ac.uk>; Wed, 1 Sep 1993 17:14:16 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9309011610.AA11327@uxb.liv.ac.uk> Subject: Re: (SC22WG5.408) Vote on Varying Strings To: jkr@letterbox.rl.ac.uk Date: Wed, 1 Sep 93 17:10:59 BST Cc: SC22WG5@dkuug.dk (SC22/WG5 members) In-Reply-To: <199308111832.AA12314@dkuug.dk>; from "@nsfnet-relay.ac.uk:daemon@newton.ncsa.uiuc.edu" at Aug 11, 93 7:31 pm X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 @nsfnet-relay.ac.uk:daemon@newton.ncsa.uiuc.edu wrote > > 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. I am not merely dismayed I am appalled. I have always maintained that slavish following of the format and text of section 13 was a BAD idea. And that to do so would take many months of work. I went along with what I thought was the intent of the vote in July, namely that a more structured approach to the format of the description modelled on 13 was required, and this is what I have done. What John is now asking for is a wholesale restructuring of the document, following the section 13 proformer to a degree which I think inappropriate and undesirable. (I personnaly have never been totally convinced that 13 is the only or best way of describing the intrinsic functions, but it is adequate, and as I was not prepared to do the work of changing it I did not raise my objections at the CD stage for 1539, and I certainly was not going to make an issue of stylistic editorial questions at the DIS stage). The changes John is asking for in many cases should have been requested at the previous ballots. They are mostly cosmetic and where they are not they can be dealt with as DIS level editorial changes. The few technical issues are ones that have been raised many times before and have been resolved. I object strongly to the continual reopenning of issues that have been discussed many times and resolved. I will try to comment on the individual points raised by John > > 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. My personal view is that in some cases an example could have been of tutorial significance, but in such cases the construction of a suitable example is nontrivial. My feeling about the trivial examples in section 13 is that generally these are too trivial to be useful and in the context of the string standard the simple reproduction of the existing section 13 examples could be more confusing than useful. This heading was not therefore transferred. Two the CD2 version. General examples of the use of the module and some of its facilities are provided in an informative annex as was requested in a previous WG5 vote. > > 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. This wholesale restructuring of the document is the sort of decision that should have and to my mind was in fact taken at the WD to CD ballot stage. No one requested this change previously, and it is debatable as to how much more readable it would make the standard and it would add not one jot to its precision of definition. > > 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. This part of the proformer of section 13 is one of its less satisfactory features. For some reason optionality is specified twice once in this heading and once on the argument. In the latter case it appears as a parenthetical qualifier of the name of the argument rather than as one of the attributes which are specified in the description of the argument. In the string standard some arguments are effectively optional because they are absent in some overloads rather than being declared with an OPTIONAL attribute. This distinction is significant because of the rules of positional and keyword arguments. I believe the format in the string standard is preferable. I debated for a long time whether to explicitly specify the INTENT for all arguments, which I believe would be actually better and more precise but chose not to at this stage because of the magnitude of the change. However, I think this would be a possibly desirable editorial improvement. > > 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. In principle, I agree but in the sence that all user written procedures are not-elemental they are transformational I think the classification should be included. If in Fxx the capability for user-written elementals is provided this standard could be very easily changed to allow this class change. (I do not think this a significant editorial or technical point and could be resolved in the DIS processing.) > > 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. PURE is not yet a concept in Fortran. The question of global statement of "purity" verses local statement was raised previously and it was resolved that it should be stated locally for each procedure. It is an editorial fault that it has been missed in a few cases. For example, in the description of the INDEX procedure, and for those arguments that are unchanged in the subroutines. Editorial comments from other WG5 members have already noted this and the correction is awaiting implementation following this ballot. (see also my comment on explicit specification of intent above) > > 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. These two are trivial. I believe : and no capitals is better but I would not consider this as a reson for NO votes. > > Global H. Requirements should be worded with 'must'. An example is to > change 'is' to 'must be' on 5/25. I was unhappy about "must be" in this context when the description applies to an argument of a generic procedure for which there may exist other overloads which are perfectly valid where the "must be" does not apply. The "is" seems more appropriate since it says describes the properties of this particular set of references. Again this is somewhat below my theshold of caring > > Global I. The names of the arguments should be in upper case to > increase compatibility with 1539. I strongly disagree and lowercase has been used in ALL previous drafts. The convention used is that generic procedure names and the module and type name are upper case all variables are lower, this includes dummy variables. F90 has both upper and lower case we should use F90 not F77. > > 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!). accepted, but 13 is not absolutely consistent in this regard either. Edits to fix this are essentially trivial. > > vi/13. 'Straightforward' should be one word. > > 1/10. Remove second 'to'. > > 3/11. Change 'which' to 'that'. essentially trivial DIS processing edits. > > 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). This is the most infuriating comment of all. This is an issue that has been discussed multiple times, including on recent letter ballots and at the WG5 meeting. All votes have been overwhelmingly in favour of retaining the CHAR spelling, providing an overload for the intrinsic INTEGER to CHARACTER conversion procedure for this VARYING_STRING to CHARACTER procedure. I would go along with John if the intrinsic function that converts to character type was also available with the name generic name CHARACTER. This is a regularisation I have argued for for years. All type conversion procedures should exist with the generic name that of the type, c.f. REAL! However, this is not the place to make that change to the language. If we as committees do not stop continually revisiting old issues we will continue to take too long to produce standards and we will become irrelevant. NO! NO! NO! to this change. > > 5/11-19. The title on line 11 should be 'Result Type and Type Parameter.' > and the descriptions should be rewritten to correspond. This could be done but would not in my opinion make the description much more precise or easy to understand. In no other case is there the possibility of a type parameter or more than one value (default) for the type parameter, so it seemed pointless to make a significant format change for this one case. > > 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)). I would have no objection to adding the sentance "The result value is ICHAR(CHAR(c))." But I would not be happy to see this as the only definition of the value. It should be possible to comprehend the meaning of these procedures without having to also refer to 1539-1. I believe the text as is is sufficiently precise. I see no likelyhood of aberrant interpretations of the meaning > > 5/39-41. I suggest (same reason as for 5/28-29): > The result value is IACHAR(CHARACTER(c)). comment as above. > An additional reason here is that I think we should be requiring > consistency with the present function, including characters outside the > standard (technical comment). This point has merit. For characters out side the standard the result is processor dependent, but we could by defining the result additionally in this manner require that the same dependency applies. > > 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. Both descriptions have the same property. I think this more consise definition is better than that in 13, but the differences are not substantive. > > 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. In both cases there is an additional "any" to deal with the possibility that there were no such blanks. This was inserted as an edit requested by some member of WG5 (I have forgotten who) who considered the text confusing without it. > > 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). An earlier version of this text was essentially the same as in 13 and it was changed to make it more precise. > > 7/15-36. Separate descriptions of the four functions should be given, > as in 1539. The question of separate descriptions for these and for the comparison operators was raised previously some years ago and the decision was to retain the concisness of the existing descriptions which also make the similarities very clear. This sort of major structural change is out of order at this stage unless there is some new overriding technical argument. > > 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. See comment above re this question. > > 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. Can John suggest a succinct way of expressing the combinatoric restrictions that apply. The intrinsic versions do not have this property and so the description technique is no longer appropriate. string and substring are not independently typed as far as this standard is concerned. > > 8/14-25. The present wording is acceptable to me, but I prefer: > The result value is INDEX(CHARACTER(string),CHARACTER(substring),back). As said before I would not object to this definition being added but I would object strongly to it being used as a replacement. > > 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). ditto > > 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). ditto > > 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). The comment re INTENT is apt here. There is a missing sentance re the arguments that are unchanged for each of the subroutines. I believe these subroutines are so different in character and function from say RANDOM that the format used in 13 is not very useful. Better descriptions are undoubtedly possible but the above comment is hardly helpful as a means of producing them. A further comment from me is that in converting back to the more complex form of GET, text has been lost which specifies the action when EoR terminates the transfer as to the value set for iostat and the effect if Iostat is absent. This is much more significant! > > 12/22-23. Delete the sentence 'The remainder ...'. The description is > much clearer without it. A matter of opinion. > > 12/45. Delete the sentence 'In all cases ...' (already said on line 44), > if my suggestion of global deletions of this is not accepted. Another commentor has suggested deleting the redundancy by deleting the "and...procdure" on 44. I prefer this. > > 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. I think this is possible but it has an impact on the way keywords have to be used. The case 1 version would always have to use the substring= keyword. > > 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). see above. Bert. It makes no sence to produce versions of split with string or word as character type. These objects are of inherently variable length. They are both INTENT(INOUT) and INTENT(OUT) respectively. If for some strange reason the results are wanted in fixed length variables it would be vastly safer to do the split in varying string variables and convert explicitly. The only possible interpretation I can think of of using CHARACTER arguments in these places would be essentially that. > > Even in the light of John's comments and Bert's which I think are all editorial, I strongly recommend a YES with comments vote. I am sorry not to have commented before but I have been on holiday, and I can say that this was not a welcome back present!!!!! -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk