From dtm@castle.ed.ac.uk Tue Feb 1 18:24:14 1994 Received: from sun2.nsfnet-relay.ac.uk by dkuug.dk with SMTP id AA08758 (5.65c8/IDA-1.4.4j for ); Tue, 1 Feb 1994 21:06:19 +0100 Via: uk.ac.edinburgh.castle; Tue, 1 Feb 1994 18:24:25 +0000 Date: 01 Feb 94 18:24:14 GMT From: D Muxworthy Subject: Comp.lang.fortran comments on evolution To: sc22wg5@dkuug.dk Message-Id: <9402011824.aa15758@uk.ac.ed.castle> X-Charset: ASCII X-Char-Esc: 29 To: X3J3 From: David Muxworthy cc: WG5 Subject: Summary of Comments on comp.lang.fortran on Language Evolution Proposals of October 4, 1993 Date: February 1, 1994 1. Introduction The paper on Language Evolution of October 4, 1993, submitted to X3J3 meeting 127 was, after the meeting, put on usenet newsgroup comp.lang.fortran to allow the Fortran-using community to comment. This note is an attempt to summarize the response. I gathered some 68 articles, ca 4100 lines of text, in response but news- servers are notoriously flakey and it is possible that some articles were missed. Also, some issues generated side-discussions where it was difficult to decide a cut-off point. A statement below that "no-one raised this point" should be read with that caveat. Further, there were seven replies direct by e-mail only, that is, not to the newsgroup as a whole. Most of the replies were, as was to be expected, of the "what is good for me" type; relatively few took a wide or a long view. 2. General Points Several people specifically mentioned that they were grateful that standards committee members had taken the time to ask what ordinary users wanted; there seemed to be an impression that standards makers were not of this world. It was explicitly stated (and is demonstrated daily in this newsgroup) that the average Fortran programmer does not know what is in the standard. One point made was that "it costs time and money to change", not so much old programs but the minds of the type of people who say, "I learned Fortran in 1975, I don't want to have to learn again". So far as dusty decks were concerned there was a suggestion that provision of portable, reliable, translation tools might substantially change opinions about possible deletions. One contribution pointed out that some move on evolution was necessary now to allow desirable changes in the future; this elicited only responses of the type, "Why should I bother about the year 2001?". Another expressed the fear that arguing about new obsolescent features could delay the revised standard. 3. Deletion candidates 3.1 Arithmetic IF An early response said that arithmetic IF could go if SELECT CASE would allow a real expression and this seemed to be generally accepted. A few people were willing to see arithmetic IF deleted unconditionally. There followed a long side-discussion on the run-time efficiency of SELECT CASE and block IF. 3.2 Real and double precision DO variables This produced probably the most response. There was no meeting of minds between those who objected to real control variables on grounds of unpredictability across systems and those who could not see that there was a problem. The compromise position (write something like x=0, 0.95, 0.1 to ensure what happens on the last iteration) was put forward but was trashed. 3.3 Shared DO termination Apart from the gentleman who provided a vote for each item (which was yes, delete it), to my surprise this item generated no comment. [This is different from our experience of asking users in the UK.] 3.4 Branching to an END IF from outside its block. This generated no comment (and a yes, delete vote). 3.5 Alternate RETURN This attracted only two supporters, but they both argued very strongly that the alternate RETURN is useful for dealing with exceptions and disputed the alleged superiority of the alternative method given in the F90 appendix. 3.6 PAUSE statement Not a single mention, other than a delete it vote. 3.7 ASSIGN and assigned GO TO This attracted the support of one person, on the grounds of efficiency in heavily used DO loops. The only other mention is so curious it is quoted in full: "I actually liked also COMMON /MYCOMMON/ERROR ... ASSIGN 999 to ERROR ... CALL SUB1(....) SUBROUTINE SUB1 (...) COMMON /MYCOMMON/ERROR ... IF(error occurred) GOTO ERROR as an elegant way of branching to a label in main program from many different subroutines (this worked on HP1000 RTE, but I do not know of any other system where it did work like that). I've never used it except for that ... because I've used alternate return otherwise." 3.8 Assigned FORMAT specifiers No mention at all, other than a delete it vote. 3.9 cH edit descriptor Somewhat surprisingly, no mention other than a delete vote. Perhaps people were thinking of 24HHAVE I COUNTED IT RIGHT? and not of 1H , in formats. 4. Proposed obsolescent features 4.1 Computed GO TO It was pointed out by three people that this feature is good for table-driven operations and there seemed to be some concern that a SELECT CASE to do the same thing would be less readable and less efficient at run-time. [Why should it be less efficient?] 4.2 ENTRY statement Only one person mentioned this and he was strongly against. He uses, a great deal, the technique of having a single procedure with N ENTRY statements in order to share code amongst the entries, instead of having N+1 or more separate procedures. 4.3 Statement functions Mentioned by only one person who said he didn't really care if they went. 4.4 DATA statements among executables Mentioned by only one person who said "zap it without mercy". 4.5 Assumed length character functions This was mentioned by two people. One said that they could be replaced by subroutines, but function references were more readable; the other said, paraphrasing, do nothing on this until there is an intrinsic varying length character type. 4.6 Fixed form source Perhaps surprisingly this was mentioned in only two replies, or maybe people really have got hold of the idea that obsolescence means marking something for possible deletion when it is no longer needed. One response said that fixed form source enforced more readability than free form (!); the other just said "NO, NO, NO, PLEASE NO" (without any supporting arguments). 4.7 Assumed-size arrays There were a number of responses opposed to this. Clearly the various possible replacements in F90 were not generally understood, but there was gloom at the suggestion of having to re-write code. 4.8 Pointers in storage associated contexts This point was put ambiguously in the first BSI paper and generated a great deal of flak, probably mostly deserved. This point was withdrawn from the evolution paper for X3J3 meeting 128 (January 31 version). 4.9 .EQ. etc operators Two people commented on this. One pointed out the anomaly of the .EQV. etc operators; the other simply said that these operators will stay for ever. The BSI panel agreed and deleted this from the paper for meeting 128. 5 New items There was a disappointing collection of totally new items for possible obsolescence. Some of the ideas put forward displayed a lack of knowledge of what was in F90 (or even F77). The list I collected was: make carriage control characters obsolescent make BACKSPACE obsolescent (since all its uses have been superseded) require ASCII as underlying character set On the other hand, there are some forward looking users, as evidenced by this quote: > And, a Common statement should allow Character variables to reside > with any other variable types. Once again, VS Fortran allows this -- > as an extension. And an extension it should remain, in my opinion. Programmers should not be encouraged to do this sort of thing. Besides, there is already a workaround in the form of internal I/O (with the A format descriptor). And of course COMMON itself should be on the way out. As soon as I get a Fortran 90 compiler, I'll convert all my common blocks to modules. ---------------------------------------------------------------------------