British Computer Society - Fortran Specialist Group

     Minutes of a Meeting held at Edinburgh University on Monday 4th February 1980


Present:    G. L. Harding (Chairman)        ECMWF

P. Carr                         Scottish Widows

P. A. Clarke                    Rothamsted Experimental Station

R. J. Collins                   UMRCC

P. C. Jamieson                  Scottish Widows

P. Kraven                       British National Oil Corporation

D. H. Marwick                   Heriot-Watt University

G. E. Millard                   Edinburgh University

D. T. Muxworthy                 Edinburgh University

D. E. Oldfield                  ICL

T. L. van Raalte                Ministry of Defence

D. M. Vallance                  Salford University

J. D. Wilson (Secretary)        Leicester University


1. Minutes of Previous Meeting [5 November 1979]


      The minutes were approved: there were no matters arising.


2. X3J3 Reports


      No reports had been received by the members present.


3. Report from ISO meeting, Turin


      Mr. D. Muxworthy reported on the ISO Ad Hoc Fortran Experts Meeting

which took place in Turin, Italy on 12th and 13th November 1979. Programming

languages are discussed formally in the ISO committee TC97 SC5 which meets

every two years, the next meeting being in London in 1981. The corresponding

group in Britain is BSI DPS13 which is currently very active in this area.

The ad hoc meeting of Fortran experts in Turin was the second of its type,

the first being in November 1978 in London.


      The following countries were represented: Austria (1), Canada (1),

France (2), W. Germany (1), Japan (2), Netherlands (2), Sweden (1), UK (3),

USA (11).


Overview


      The meeting was held in the same cordial atmosphere as that which

characterised the meeting in London in November 1978. Misgivings were expressed

by Marty Greenfield about the large size of the U.S. delegation but these

were dispelled by Brian Meek who said that the size was taken by other countries

as an expression of interest in their views. However the breadth and depth of

the discussion of the London meeting was not possible in Turin. Only two days

were allocated to the meeting; some of this time was taken up with procedural

and administrative matters and not all of the technical papers had new or

worthwhile content.


Administrative


      The principal matter discussed was whether the ad hoc Fortran group

should become a formal ISO working group. The main arguments, for and against,

concerned financial support for arranging and attending meetings. The UK

proposed the motion to SC5. A straw vote of individuals was 8-7 in favour of

a working group but a formal vote by delegation gave a tie 3-3-2. (In favour:

Canada, Sweden, UK; against: Japan, Netherlands, USA; abstain: Austria, Germany)

The group therefore made no recommendation to SC5. The matter was discussed by

SC5 and passed to TC97.


Technical


      The current thoughts of X3J3 subgroup 10 on core and modules were put

succinctly by Winfried Burke. Essentially these are that the core language

should be self-contained, have minimal functional duplication and be "generally

accepted", and that there should be two other principal modules, one for

compatibility and one for new extensions. Around these there could be an

arbitrary number of applications modules. The core was intended to be stable

from revision to revision whereas experimental features such as dynamic storage

would go into the extensions module.


      The first applications module to be considered would be the Codasyl

Fortran Data Base Facility (Codasyl Journal of Development January 1980) at

the X3J3 January meeting. There was considerable discussion at Turin about

the fear of the applications tail wagging the Fortran dog.


      Jeanne Martin presented a comprehensive case for adding macro capabilities

to Fortran but did not stress what must be the outstanding advantage from X3J3's

(and many others') viewpoint, viz that a rich set of macros would make it

infinitely easier to resist pressure for new minority features or even whole

new applications modules.


      The latest thoughts of X3J3 on data structures were put by Neldon Marshall.

These would allow nested structures and structure names in a variety of statements

to imply the content item by item. The syntax still needs some work as

e.g. A.EQ.B could be ambiguous. The subject of significant blanks was repeatedly

raised but sentiment in X3J3 seems to be against its adoption in the current

revision.


      Ingemar Dahlstrand reviewed current work on command language standards

(ANSI X3H1, CODASYL COSCL, BCS OSCL Specialist Group and IFIP WG27) and warned

that Fortran must be able to pass file names to and from the operating system.

The layout of a program in virtual memory was another relevant area for liaison

with OSCL groups.


      The Netherlands sought to have the draft real time Fortran standard

(DP 6705) withdrawn and replaced by a wider ranging document; subsequently SC5

confirmed its approval for work on DP 6705.


      The UK reiterated its points from the October X3J3 meeting about more

features for numerical analysis, more regularity and less permissiveness.


      Jeanne Adams' paper is a review of work done so far and a summary of

the current lines of thought. It was not discussed per se at the meeting.


Miscellanea


      Fortran 77 was expected to become the formal ISO standard in December l979,

AFNOR having agreed to waive its right to insist on a French translation. NBS

were working on a Fortran 77 test suite. IBM was thought to be waiting for a

FIPS publication before announcing a Fortran 77 compiler.


Next meeting


      It was agreed that the next meeting would be held in Amsterdam in

November 1980 on dates to be decided. Marty Greenfield informally offered to

take part in a Fortran Forum similar to that held in London in December 1978,

though whether a significant number of the X3J3 participants could arrange

to return via London was unclear. The subsequent meeting was tentatively

fixed for Vienna in the autumn of 1981.


Discussion


      D. Muxworthy said that the UK hoped to present a number of papers at

the Amsterdam meeting. One will probably be on Numerical Analysis aspects

by J. Reid, Harwell and another will be on "Less Permissiveness" by A. Clarke.

Any other people interested in presenting a paper are asked to get in touch

with D. Muxworthy as soon as possible.


      A. Clarke proposed a "completeness module" as an optional module to

give standard treatment of undefined occurrences, e.g. error handling.

He hopes to prepare a draft of his paper for discussion at the Fortran

Specialist Group prior to the Amsterdam meeting. Anyone interested in this

area should get in touch with the Secretary who will arrange for a copy of

the draft paper to be sent out when available. J. Wilson asked if there was

any intention of producing a sub-set of the next Fortran standard, and if so

whether it would be designed with micros in mind. D. Muxworthy said there

had been no mention of one.


      A. Clarke said there would probably be considerable interaction problems

between the different parts of the E+C+O system (E=extended features module;

C=core; O=obsolete features module) when used as a whole.


      P. Kraven was concerned that little was being done in the area of

interface to other languages including definition of precision of variables.


4. Other Fortran Groups


  (i) A short report has been received from the Netherlands Fortran Specialists

Group indicating their wish for the next ISO Experts meeting to be held

in Amsterdam (see above).


 (ii) Codasyl Data Base group has just finalised version 2.0 of the

Codasyl Fortran Data Base Facility. Version 1.0, produced in 1977

proved to be rather unstable.


(iii) The U.S. Department of Energy has defined its extensions to Fortran 77.


5. BCS Business


  (i) The Chairman attended a meeting of the Specialist Groups Committee in

December 1979. There was some debate over which Group should deal with

ADA: the Algorithmic Languages Association (formerly the Algol Association)

or the Real Time Specialist Group.


BCS 79 was considered a success in spite of making a financial loss.

A similar event, BCS 81, is planned for Easter l98l; all Specialist Groups

will be invited to contribute. Any suggestions from the FSG should be

given to G. Harding.


 (ii) The question of money for attendance at ANSI X3J3 meetings is still under

examination. D. Muxworthy stated, however, that the BSI do not approve

of direct involvement with X3J3, preferring to deal directly with ISO.


6. Any Other Business


  (i) Fortran 77 compilers: CDC have finally released their compiler, together

with a conversion package to convert programs from their current compiler

to the new one.


A compiler for ICL 2900s is at an advanced stage of development at

Edinburgh University, as is one for ICL l900s at Salford University.


SEL are also producing one.


(ii)  A video tape course entitled "Structured Fortran" covering the

complete Fortran 77 language has been produced by the University of

Sheffield. Details may be obtained from Mr. T.M.R. Ellis, Information

Officer, Computing Services, University of Sheffield, Sheffield S10 ZTN.


(iii) A. Clarke introduced some thoughts on "Modern Control Structures" within

Fortran. He compared multi-exit looping structures with nested subroutine

calls in an attempt to obtain a common approach to both structures.

Anyone interested in this subject should contact A. Clarke directly.


7. Next Meeting


      The next meeting will be the AGM and will take place at the BCS Headquarters

in London on Monday, 3lst March 1980.



------------------------


Afternoon Session


      Mr. D. Marwick of Heriot-Watt University gave a talk on his experiences

with Fortran 77 during the writing of the book "Programming in Standard

Fortran 77". A summary of the talk is given in Appendix A.


Discussion


      P. Kraven asked what is wrong with the ASSIGN statement. The general

feeling was that it does not fit in with the rest of the language; its main

advantage in the past had been greater run-time efficiency with certain old

compilers.


      There was considerable opposition to including Computed G0 TO in the

"Obsolete Features" chapter of the book.


      D. Marwick gave three reasons why Fortran 77 is not being taken up very

quickly by manufacturers.


  (i) Manufacturers think they already have compilers which are near enough

to the standard: the extra effort is not worth it.


 (ii) The arrival of ADA.


(iii) The next standard will change things too much; therefore wait and see.


T. van Raalte said there is also considerable user inertia and lack of interest

"what does it have in it for me?" There is confusion with all the reports of th

"new standard". Should the new language still be called Fortran? X3J3 appear

to be going in for language design rather than standardisation.


       D. Vallance reported that the three things he disliked most in Fortran 77,

as a result of writing a compiler for ICL l900s, were:


          INQUIRE


                   OPEN             (no interaction with file protection systems of the

                Operating System)


          Treatment of Direct Access files (should the size of the file

                have to be declared by the user?)





APPENDIX A


HERIOT-WATT UNIVERSITY


 DEPARTMENT OF COMPUTER SCIENCE


Talk to the B.C.S. Fortran Specialist Group  -  4th February, 1980.


Introduction


This talk is a personal recollection of some of the problems

Alex Balfour and I had in writing our book "Programming in

Standard Fortran 77" (published by Heinemann in paperback

£4.50, hardback £9.50).


As can be seen from the first chapter of our book Alex and

I are no great lovers of Fortran as a programming language,

but being pragmatists by nature, we accept its position in

the computing world. Thus an important aim in writing the

book is to try to encourage the use of good programming

techniques in Fortran 77.



History


In April, 1977, on Alex s suggestion, we approached Heinemann

with the idea of writing a book on Fortran 77 since the new

standard was imminent (yet again). Heinemann were very

wary of the idea since they had been advised that the language

was unlikely to be generally adopted; we persuaded them

otherwise (though subsequently we have been surprised that it

has not been adopted more quickly).


The book was completed by April, 1978 (when Alex left for a

year's sabbatical in Pasadena). All that remained was to

check that our text was consistent with the final standard and

for me to check the examples and exercises. These tasks were

hampered by the lack of both the standard and a compiler.

The former was eventually obtained one year later after a

chapter of accidents both self-induced and BSI-obtaining-

copies-from-ANSI-using-surface-mail induced. The lack of the

standard was less embarrassing than the lack of a compiler

since we had the X3J3 minutes, copies of FORWARD, and friends

to reassure us that no significant last minute changes had

taken place.


We also sought clarification on several points from X3J3 itself.

We were very impressed at the speedy response (about 6 weeks

in total) which not only included the postal system but also

discussion at an X3J3 meeting. The clarifications (see

X3J3/104 Minutes of 63rd Meeting Appendix L, May, 1978) brought

home to us in a humbling way the care with which the standard

must be read. For example, one point was answered by 4

references from 3 different sections; we had noted only 3

of the references. While not excusing our oversight, I

would criticise the standard itself in that so often to

learn all about a topic requires reading several refer-

ences from different parts of the standard.


Compiler


Having approached the three regional computing centres in

vain, I heard (via Alex in Pasadena) that the Honeywell/GE

(now GEISCO) Mark III network had a Fortran 77 compiler.

It turned out to be a super superset of Fortran 77 and the

manual had the encouraging phrase


        "provides an opportunity for users to develop programs
         which are standard conforming".


However, very quickly I discovered the following standard

facilities which were not accepted on the Mark III F77.


(a)  * as a unit identifier in an I/O statement;


(b)  if the field width in an edit descriptor is

too small, the field is filled with asterisks

(Mark III lopped off the most significant

digits - a feature I described as the "unacceptable

face of computing"!)


(c)  PRINT * which we use to output a blank line

(PRINT *, was accepted!)


(d)  the intrinsic function CMPLX may have two arguments

(only one was acceptable).


The Mark III U.K. Fortran man on hearing I was using their

compiler to test material in a book, but before I had

explained my difficulties, promptly challenged me to find

any standard features not accepted by their compiler! Even

the telephone seemed to capture the subtle sound qualities

of jaw hitting floor when I explained that that was precisely

why I was talking to him. Within three weeks I had found

15 such points and 7 compiler errors. Having overcome his

initial shock, he was very helpful to me in the problems

that I had.


This experience shows, I think, how easy it is for a company

to make claims about a language on the assumption that the

average user will read their documentation and not the

standard itself. In such ways, very few people learn what

the standard actually contains. In our book, we are careful

to stress standard Fortran 77. I was, of course, not an

average user and was testing things that only specialist

compiler breakers and authors of books on programming languages

would ever wish to test.


However, in spite of these difficulties which lengthened

the testing period, the compiler enabled me to find a

number of errors (and two bloomers!) and also helped to

clarify some points in the standard.


Conclusion


Not having access to a (free) compiler, I have not used

Fortran 77 for some time so my memory of it is not as clear

as it might be (despite having an excellent reference book!)

However, as I remember, it is an easy language to use. Its

main drawback is the lack of a general looping structure

(especially as we try to adopt a structured approach in our

book). I wonder if this omission was not X3J3's major error

in the production of the standard. While their subsequent

work on looping structures is valuable, I fear vendors will

produce their own structures and make standardisation more

difficult next time.


On the standard itself, it is too long and verbose. It was

a mistake not to use BNF or the syntax charts in the text.

While we found Appendix B (Section Notes) invaluable as

clarification of the text, I feel this in itself is a criticism

of the standard.


In general then, Fortran 77 is a distinct improvement over

Fortran 66, though it is by no means perfect. Some areas we

consider to be less than perfect are:


(a)  the multiple uses of *, highlighted by the following

valid Fortran 77 example supplied by Geoff Millard (ERCC):

SUBROUTINE SUB(C)

CHARACTER C(4,*) * (*)

:

END


(b)  the lack of a specific collating sequence, almost

remedied by the eleventh hour inclusion of the

lexical comparison intrinsics.


(c)  the INQUIRE statement - an old warhorse of the

Fortran Specialist Group.


(d)        the ordering rules for IMPLICIT and PARAMETER,

which needed the clarification we sought from X3J3.


(e)  features like the non-zero iteration count in a DATA

implied DO, whereas in a DO statement and I/O implied

DO the iteration count may be zero. I feel the

context dependent nature of facilities must confuse

the non-specialist user.


There are features in FORTRAN 77 that we condemn outright

in the book. The most important of these are


(a)  Alternative entry points and the alternate return

in external procedures - anathema to any structured

programmer as it leads to "spaghetti code".


(b)  The IMPLICIT statement - can lead to slovenly code.

It would be much better to have to declare all

names.


(c)  The assigned GOTO and the ASSIGN statements for which

we can see no use and which require an effective type

change to the variable from integer to label.




DAVID H. MARWICK

4th February, 1980.