From jls@liverpool.ac.uk Tue Sep 14 16:32:33 1993 Received: from mail.liv.ac.uk by dkuug.dk with SMTP id AA12745 (5.65c8/IDA-1.4.4j for ); Tue, 14 Sep 1993 16:32:33 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <26407-0@mailhub.liverpool.ac.uk>; Tue, 14 Sep 1993 15:30:57 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9309141430.AA04338@uxg.liv.ac.uk> Subject: Varying String DIS To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Tue, 14 Sep 93 15:30:46 BST X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 I have done my best to process as many of the straightforward (one word!) editorial comments as I could and which I thought were uncontentious. (I agreed with them (;-) and they did not make any significant change to the structure of the document or its technical content.) I was as careful as I could be in the time available but I am sure there are some things I missed and others that in doing I have introduced new typos, but fixing this sort of thing is what DIS processing is about. I had particular difficulty in checking that all the global edits that were requested without detailed references have all been done. Others that caused some problems were edits specified as references to other edits which had to be applied mutatis mutandis. However, I have done my best. You can judge how good that was if you want by collecting the resulting version 1 of the DIS from our ftp server, ftp@liv.ac.uk the files are in the directory pub/wg5 and are as follows is1539-2.dis (wordperfect file - collect in binary) is1539-2.dis.asc (plain ascii) is1539-2.dis.ps.Z (compressed postscript) A number of you made comments that were essentially technical. In particular, a number pointed out features that are associated in general with intrinsic types which are not possible given the self imposed restriction that an example implementation should be possible in Fortran 90. That this is the case has never been disputed. However, this is not to my mind a sound prima facie argument for rejecting the approach to providing facilities and to defining semantic extension standards. What is being highlighted are the deficiencies with the base language. We should not solve these general problems by bypassing them in this specific case by constructing yet another intrinsic type. WE should solve the general problems which preclude the construction of derived types with all the capabilities of intrinsic types. This standard and module demonstrates how close we are already; close enough to allow a useful semantic extension standard to be defined within the current constraints. It also demonstrates that we need to deal with the restrictions that preclude a complete job. We need proper facilities for defining literal constant denotation (existing derived type constructors are not adequate). We need user definable elemental procedures. User defined procedures, at least of some possibly restricted sort allowed in initialisation expressions and specification expressions. WE need the parameterisation of derived data types and a better means of abstracting I/O. All these things would allow a better varying string module to be written, and this is what would be standardised as a revision of is1539-2 following the revision of is1539-1. There are a couple of genuine technical issues that were raised which I think merit consideration as per this standard. By far the most significant is the need for a separator argument in the versions of GET containing the set argument. Without this the user has no way of determining which of a possible multi-character set actually terminated the data-transfer. Without this a program would not be able to read a string piecemeal and write it back out exactly as was. Len pointed this out and I am sure this will appear in someones national body vote on the formal DIS ballot. I believe therefore it will be possible to correct this defect during DIS ballot processing (we made changes of this order in resolving DIS ballot comments for F90). There were also comments which suggest that it would be desirable for there be identity versions of the conversion procedures, e.g. CHAR(char) and VAR_STR(string) overloads. It is debatable whether the former should be defined in this standard or whether this should be added to the generic properties of the intrinsic definitions, but if the latter is required it should be defined in this standard. Finally, a number of you noted that IMPLICIT none was not used and should have been. Guilty! My personal style is to declare all variables except DO indexes which I allow to be declared implicitly. I tend to use single letter i,j,k exclusively for such indices. The final IS code should revert to IMPLICIT NONE. It was also pointed out that the PUT procedures writing to the default unit have the defect of possibly detecting an error on unit=* and then attempting to write an error message to the same unit. Again. guilty! But as Fortran is deficient in defining only default units corresponding to stdin and stdout with no default for stderr, what alternative is there? In spite of these problems I think we now have a fairly adequate DIS. Once this has been subjected to the proper scrutiny of the 6mths national body DIS ballot and the document given its final polish to resolve the inevitable comments I think we will have a pretty reasonable IS. (yes I am biased (:-) -- 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