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.
------------------------
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?)
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.