From jls@uxb.liv.ac.uk Mon Jan 18 12:17:24 1993 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA20968 (5.65c8/IDA-1.4.4j for ); Mon, 18 Jan 1993 13:22:21 +0100 Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 1099; Mon, 18 Jan 93 13:24:08 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 6332; Mon, 18 Jan 93 13:24:07 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 5681; Mon, 18 Jan 93 12:21:38 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 8923; Mon, 18 Jan 93 12:21:37 GMT Via: UK.AC.LIV.UXB; 18 JAN 93 12:16:57 GMT From: "Dr.J.L.Schonfelder " Via: uxb.liv.ac.uk (uxg.liv.ac.uk); Mon, 18 Jan 93 12:17:26 GMT Message-Id: <10490.9301181217@uxb.liv.ac.uk > Subject: Ballot on Varying String Standard To: UKFORTRAN@ed.ac.uk(UK Fortran Panel), UKPROGLANG@ed.ac.uk(IST/5 Members), SC22WG5@dkuug.dk(SC22/WG5 members) Date: Mon, 18 Jan 93 12:17:24 GMT X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 On behalf of the UK Fortran panel and its convenor (David Muxworthy) I have mailed a printed copy of the following document to BSI secretariate as the recommended UK vote. To : IST/5 From: IST/5/-/5 ISO VARYING STRING STANDARD Suggested UK ballot Comments on CD 1 Ballot The UK votes NO on the grounds that there appears to be procedural confusion regarding the status of the standard. The UK, in common with most member bodies on WG5, view this as an optional standard, auxiliary to ISO/IEC 1539:1991 "Fortran 90", not as a compulsory amendment. The UK believes that this was always the intent of WG5 and that recent changes in JTC1 procedures may have inadvertently fostered this confusion. The relationship of this standard to Fortran 90 is intended to be a one way dependency. Conformance to Fortran 90 does not imply or require conformance to this standard, but in general any processor conforming to this standard would also be a conformant Fortran 90 processor. The recommendation is that any Fortran processor providing facilities for support of varying length strings should do so in a manner that conforms to this standard. This position is clearly stated in the standard itself. The UK will change its vote to YES, provided this question of status is satisfactorily addressed. 2 Technical Comments The UK would also like to see the following technical issues discussed, but does not in general consider that these are of sufficient weight to warrant a NO vote. The one exception to this is the proposal to introduce INIT and FREE procedures (see below). If this were done the UK would wish to re-ballot the standard at the CD level and would almost certainly vote NO on technical grounds to such a CD. 2.1 A question has been raised as to the need for greater symmetry in the definitions for VAR_STR and CHAR, in particular should VAR_STR have a version which includes a length parameter. The UK view is that this is neither necessary nor desirable. The length of the result is explicitly controllable by the use of substringing and/or concatenation to restrict or pad the length of the argument. The addition of extra arguments to control the length internally in the procedure is unnecessary and is essentially a fixed length string functionality not a varying length facility. Symmetry should be obtained if this is considered essential by removing the length argument from CHAR. The UK view is that there does not appear to be any very compelling reason for requiring such symmetry. The two target types differ in precisely the attribute that one has a defined fixed target length and the other does not. It would therefore appear appropriate for the possibility of explicit length specification to apply in the one case but not in the other. 2.2 The UK considers that the inclusion of the maxlen option on the READ_STRING procedure to be unnecessary and undesirable and that it should be removed. This is again a fixed length character string functionality, and as such is already adequately and simply provided using standard Fortran 90 character I/O facilities. However, the UK recommends that the action of the read procedure should be more precisely defined to return a positive value for iostat whenever the resulting string cannot be properly allocated and stored. The code of the illustrative module should also be modified accordingly. 2.3 The essentially non-generic choice of names for the I/O procedures is undesirable. Users and possibly other standards groups might wish to create similar modules for different types and could well want to have generic I/O procedures with a broadly similar role. They would logically wish to overload the existing standardised generic names. This would not be likely however, since the current names, READ_STRING, WRITE_STRING, WRITE_LINE indicate the type of their main argument in their name. These names are specific not generic in character. The original names for these procedures of PUT, GET, and PUT_LINE were more generic in character. The UK would prefer that the standard be modified to use these names or some other suitable generic names that identify the (I/O) function but not the type of the object involved. 2.4 Because of the feature of Fortran 90 which means that pointers are always created in an undefined state, it is difficult if not impossible for the example module to be written to minimise memory leakage. It was therefore suggested in the comments on the previous ballot that because of this efficiency problem with the VARYING_STRING illustrative module, the standard and module should include INIT and FREE subroutines along with a requirement on the user that no string variable be used for any purpose until it had appeared first in a call to the INIT procedure. The UK is strongly opposed to any such change for the following reasons. a) The standard is intended to define the interface and functional semantics only. The expectation is that high quality implementations of Fortran 90 will implement the module interface as an integral part of their processor. They can therefore avoid the inefficiencies inherent in the example module. The module was not anyway written to be of optimal efficiency but merely as an illustrative existence proof that a portable implementation was possible. b) The standard and illustrative module define only facilities considered to be useful and functionally necessary for a user of varying strings. The technical details relating to particulars of the specific, indeed any, implementation are deliberately hidden. Routines such as INIT and FREE do not fall into such a category. They would not be seen by the average user as having any obvious connection with the job of manipulating strings of characters. For this reason users would not naturally use such routines and would very likely omit to do so in spite of documentation indicating that they must. A module that therefore depended on the assumption that they had would be very unsafe in practice. Garbage collecting an undefined pointer is not likely to improve the reliability of the program. With the standard as now defined it is relatively easy and natural to use and it makes no specialised assumptions about a user's program. It is safe, if possibly inefficient on some implementations. With a required INIT procedure it would become potentially more efficient but at the expense of assuming unnatural coding practices likely to make it highly unsafe. c) It is not a sensible approach overall to try to build unnatural temporary workrounds in supplementary auxiliary standards for inefficiencies caused by general defects in the main language. The general defect should be fixed and then the user of the supplementary standard obtains the benefit in increased efficiency without a change to either programs or the auxiliary standard. 3 Editorial Comments There is a general issue of how best to make available the source text of the example module. It is suggested that it would be highly desirable for this to be published in machine readable form. In fact it would probably be better to publish a descriptive annexe which explained the module structure and included some samples of the code but not the whole text; this is really too voluminous to be very useful as a paper publication. This change would be an improvement to the document. However, it is not a change that is necessary at this late stage as it would be essentially cosmetic and would cause a serious delay in processing the standard. There is a serious question raised by this however, as to the ownership of the copyright of any machine readable versions of both the standard and any software contained in such a standard. The reformattable machine versions of the document are almost certainly not the same representation for copyright purposes as the printed document the copyright for which is passed to ISO with the publication of the standard. -- 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