British Computer Society - Fortran Specialist Group
Minutes of the meeting held on Monday 6 February 1978, in Room 503,
Electrical Engineering, Imperial College Computer Centre,
Exhibition Road, London SW7.
Present:
D.T. Muxworthy (Acting Chairman) Edinburgh R.C.C.
P.A. Clark Rothamsted Experimental
Station
J. Roberts-Jones Liverpool City Council
P. Loftus Marconi-Elliot Avionic
Systems Ltd. (GEC)
B. Meek Queen Elizabeth College,
London
K. Normington Lanchester Polytechnic
M. Nunn CCA
B.D. Pyne Atkins R & D
M. Smith Rolls Royce Ltd.
A.J.H. Walter Rutherford Labs.
J.D. Wilson Leicester University
Computer Lab.
G.L. Harding (Secretary) ICCC
Apologies for absence from:
M.R. Lewis Cray Research
J.D. Murchland University College,London
1. Approval of minutes from previous meeting
The minutes of the meeting of 14 November 1977 were approved.
2. Matters arising from the minutes
No matters arising.
3. Activities of other Fortran groups
3.1 X3J3 Activities
In November X3J3 presented Fortran 77 to ISO TC97/SC5 (see
below). On the agenda for the January meeting was the
CODASYL Fortran Data Base facility. A copy of the
Journal of Development is available for inspection from
the Secretary.
3.2 Purdue Group
Purdue and I.S.A. had a joint meeting in October 1977.
It was proposed that ISA S6l.l be sent to ISO for
standardisation. Some time was spent developing S61.3.
Copies of this draft are available from P.A. Clark.
3.3 ISO TC97/SC5
Brian Meek reported about this meeting.
This group covers all programming languages for ISO and
had to discuss more than Fortran. An ad hoc committee
was set up to discuss Fortran. This consisted of 15
members, including 6 from X3J3.
N397 (X3J3/90) as amended by N410(X3J3/97) was considered
as Fortran 77 for standardisation, and a recommendation
was made to the main committee that this be put to a
letter ballot for acceptance as an International
Standard.
Discussion on Fortran 82 plans followed and the following
'rough'schedule was given:
1978 - discussion of philosophy of new revision
1979 - discussion of particular proposals
1980 - 1982 writing of the new standard, draft publication,
and comment period.
None of these divisions are fixed and the first two items
could overlap. Comment from outside the U.S.A. would
be welcome at any time.
There was some discussion on the form of the new standard,
one idea was to have a base language (perhaps Fortran 77)
with add on modules to cover such items as real time
applications, DBMS facilities, etc.
4. Working Party Reports
There were no working party reports.
5. Other Recent Fortran Events
5.1 Implementation Developments
K. Normington reported that Lanchester's Fortran compiler
now had write list expressions as per Fortran 77.
5.2 Fortran Publications
J.D. Murchland has produced a set of abstracts from
SIGPLAN and a paper on Fortran naming conventions
(see Appendix).
6. BCS Business
It was reported that the BCS were planning a conference to
take place in early 1979 which would consist of probably 3
hour sessions presented by each specialist group.
7. Any Other Business
It was pointed out that the Calcomp plotting routines could
not be used in standard Fortran as they had a requirement to
have a variable number of arguments. Some discussion also
went on to consider the problem of passing some variable
dimension arrays.
8. Date of Next Meeting
The next meeting will be on Monday 10 April, at a venue yet
to be fixed.
Afternoon
P.G. Barker (NUMAC) gave a talk on "PL/I a successor to Fortran".
PL/I as a successor to FORTRAN
P.G. Barker
SYNOPSIS
This presentation commenced with a short overview of the role of programming
languages within problem solving; namely, to map people (problem solvers)
and problems onto available computing machinery. In an ideal world the
choice of language for problem solution would depend upon the nature of the
problem to be solved and the facilities offered by candidate programming
languages. To choose a language, twenty-five or more factors need to be
considered. Five of these were selected in order to compare the two
languages and to provide a basis to describe the author's motivation for
changing from Fortran to PL/I.
The factors that were considered were (1) facilities, (2) availability,
(3) cost considerations, (4) productivity, and (5) ease of learning. On the
first topic ten items were listed as being of value to the programmer and
designer: the availability of a preprocessor, block structure, the variety
of data types and structures, a variety of I/O modes, storage classes,
recursion, useful control structures, multi-tasking, built-in functions and
ON-conditions.
Regarding the availability of the language, the speaker mentioned that over
the past ten years (since the BCS one-day seminar on PL/I in 1967, when only
an IBM implementation existed), most manufacturers have undertaken the
development of PL/I compilers. Implementations now exist on large and small
computers.
On the theme of cost, three topics were mentioned: cost of compilation, cost
of programming and cost of code execution. Figures were presented to show
how optimised PL/I code performed almost as well as optimised FORTRAN.
Productivity of programers was discussed in terms of structured programming,
ease of debugging, documentation capabilities and the availability of
interactive programming facilities. At this point listings of two case
studies of well documented, well structured, GOTOless programs were
distributed to the audience.
In the final section of~the talk some studies on the ease of learning of the
PL/I language were described. The difficult features were in general
associated with the default facilities, rules for conversion between data
types and a lack of understanding of data types other than numeric.
In conclusion, it was suggested that PL/I was an important language for the
future, particularly in application areas such as database implementation
where complex relationships between data needed to be represented. However,
despite this, it was thought that it would be some time before the world
really found out about PL/I. In the meantime, FORTRAN (77 and 82) will
continue to grow more and more like PL/I.
REFERENCES TO FORTRAN IN RECENT SIGPLAN NOTICES
Abstracted, with some personal selection, by J.D.Murch1and, University College
London Transport Studies Group (Gower Street, London WCIE 6BT, 01-387 7050).
Comments on the usefulness of these abstracts, and on whether the amount of
detail is right, would be appreciated.
SIGPLAN NOTICES 12 (1977 May)
1 A.van Wijngaarden et al: Revised Report on the algorithmic language Algol 68
Only for cognoscenti. (For a splendid introduction to the language,
assuming a knowledge of Fortran, see A.S.Tanenbaum: A tutorial on Algol 68,
Computing Surveys 8 (1976 June, 155-190.)
This article is followed by one defining a sublanguage of Algol 68.
Another, on the Algol 68 standard hardware representation, is highly
relevant to possible developments in Fortran, but does it need to be so
desperately complicated?
SIGPLAN NOTICES 12 (1977 June)
Proceedings of the Strathclyde Algol 68 Conference
138 A.Prudom and M.A.Hennell, University of Liverpool: Some problems concerning
the automatic translation of Portran to Algol 68.
Much of the software one might wish to transfer to another computer is
written in Fortran. The paper describes an attempt to transfer the NAG
library (a large set of mathematical routines very carefully written in
sub-standard (more restrictive than the standard) (Fortran 66) into Algol 68.
Difficulties occur for input/output (but the NAG library has none), Common
statements which are not identical in different routines, and Equivalences
of other than simple kinds. Two-thirds of the NAG routines ran correctly
first time; the others needed some hand fixing. On the ICL 1900 machines
the Algol 68 routines executed at about the same speed (68R compiler) as
the original Fortran version, but Algol 68 input/output is slower. The
GLIM statistical package has also been translated.
SIGPLAN NOTICES 12 (1977 July)
4 ASCII is being augmented, mainly for two-dimensional character imaging
input/output devices.
12 Letters by W.D.Maurer and W.J.Hansen commenting on a previous letter by
Frank Pagan on eliminating semi-colons (in between, or following, program
statements).
51 Richard J. and Martha J.Cichelli, Pennsylvania: Goal directed programming.
Refers to precompilers SCOBOL and SFORTRAN, apparently due to Volvo
Flygmotor, Sweden.
112 John D.Woo11ey, Boeing: Fortran - a comparison of the new proposed language
(1976) to the old standard (1966).
Unfortunately out of date, but very detailed and using an interesting
type of diagram to exhibit the possible forms of each statement type.
SIGPLAN NOTICES 12 (1977 August)
Devoted to papers from the ACM Symposium on Artificial Intelligence and
Programming Languages, Rochester 1977. No mention of Fortran, but the
following is interesting, as well as the two papers preceding it.
85 Jerry R.Hobbs, City College, CUNY: What the nature of natural language
tells us about how to make natural-language-like programming languages
more natural.
SIGPLAN NOTICES 12 (1977 September)
2 ACM Conference on the 'History of Programming Languages' at Los Angeles,
1978 June 1-3. John Backus will cover Fortran. 13 other languages (up
to 1967).
14 Letter by John R.Maskey, Bell Laboratories, pleading for attention to
the human readability of programs, especially by the use of lower case
and mixed case (typically 10 to 20 percent more readable than upper case
only).
45 Menachem Nalkosh, GOLEM project, Weizman Institute: Internal procedure
parameters in structured Fortran precompilers.
PERFORM PROCA(J=2,K=3.), for instance.
85 David N.Smith, Tymshare: Proposals for Fortran data structures.
Records, Hoare records, structures (as in PL/1).
130 B.A.Fraley, University of British Columbia: On replacing Fortran.
Plea to recognize the simplicity of Fortran, and its ability to change,
and that it should be changed by evolution, not revolution.
SIGPLAN NOTICES 12 (1977 October)
1 Sigplan, which has 7000 members, has one Technical Committee, on APL,
and is willing Lo form others. Fortran is being considered, under Loren P.
Meissner.
5 The 1977 Annual Conference of the ACM continued a report on the Fortran
database language.
6 'CODASYL FORTRAN Data Manipulation Language J.O.D.' (1977 January) from
the CODASYL FORTRAN DML Committee, in the form of a companion volume to
the CODASYL COBOL J.O.D. 1976, from Material Data Management Branch,
Department of Supply and Services, Metcalfe Building (5th floor), Ottawa,
Ontario, Canada K1A OS5, for $4.00 (post included) prepaid in Canadian
or US dollars.
8 A SIGn of the times: ACM has just started SIGPC, a new special interest
group on personal computing.
65 Michael D.Shapiro: Fortran 77 input-output seems out of touch.
The standard Cobol Mass Storage Control System will be implemented by
manufacturers for all but the smallest machines. The new Fortran facilities
are similar, but inferior, to MSCS, and pointlessly different.
SIGPLAN NOTICES 12 (1977 November)
9 C.W.Wetherall recommends the IF-THEN-ELSEIF-ENDIF statements as added
to the Livermore Fortran compiler LRLTRAN.
36 C.H.Lindsey, University of Manchester: Structure charts, a structured
alternative to flowcharts.
55 Suggestions for what compound statements should be introduced into Fortran,
by A.Sedgwick, University of Toronto (which the abstracter finds
incomprehensible).
SIGPLAN NOTICES 12 (1977 December)
3 'ANSI Fortran Checker' checks programs for compliance with the 1966
standard, Softool Corporation, California.
4 ACM 'History of programming languages conference' Los Angeles, 1978
June 1-3, will include Fortran amongst many others.
7 Computer software standards: a bibliography with abstracts, National
Technical Information Service (referred to as NTIS subsequently),
Springfield VA 22151, NTIS,PS-77 0423/2WC, $25 pc / $25 mf.
8 Federal COBOL Compiler Testing Service Washington DC, Compiler Validation
Summary Report.
1. Honeywell Level 66 Fortran Compiler Version 31 (GCOS Version 31),
20 pp, NTIS, AD-A040 083/8WC, $3.50 pc / $3.00 mf.
2. IBM 360/370 'Code and go' Fortran compiler version 3.0 (OS Version
21.8), 18 pp, NTIS, AD-A040 128/INC, $3.50 pc / $3.00 mf.
3. Univac 1100 Series ASCII Fortran Compiler Version 6R6 (EXEC 8
Level 33R1), 18 pp, NTIS, AD-AO40 355/OWC, $3.50 pc / $3.00 mf.
4. IBM 360/370 'G'Fortran Compiler Version 21.0 (OS Version 21.8),
18 pp, NTIS, AD-A040 3 92/3WC, $3.50 pc / $3.00 mf.
5. IBM 360/370 Fortran IVH Compiler version 21.8 (OS Version 21.8),
22 pp, NTIS, AD-A040 385/7WC, $3.50 pc / $3.00 mf.
9 R.A.Magnusen, National Institute of Health, Maryland: RMAG22 User's Guide,
1977, 64 pp, NTIS, PB-268 214/4WC, $4.50 pc / $3.00 mf.
The 'recursive macro actuated generator' is used for the generation of
source language coding, data, text and arbitrary strings. It will generate
any language whose statements can be formed from EDCDIC characters, and
uses range from a synthesizing editor to that of a complete-system generator
(including routines in different languages, JCL and documentation).
10 P.Oliver, Federal Cobol Compiler Testing Service, Washington DC:
Transferability of Fortran benchmarks, 13 pp, 1977, NTIS, AD-A039 741/4WC,
$3.50 pc / $3.00 mf.
12 R.S.Scowen, National Physical Laboratory, Teddington, Middlesex TW11 OLW:
The diagnostic facilities in Algol and Fortran compilers, report.
12 H.J.Boom and E.Jong, Mathematisch Centrum: A critical comparison of several
implementations ... , 103 pp, 1976, from Mathematisch Centrum Abstract
Service, 2e Boerhavestraat 49, Amsterdam-1005.
The implementations of Algol 60, Fortran, Pascal and Algol 68 on the
Stichting CDC Cyber 73 are compared.
23 J.G.Noel,Naval Oceans Systems Center, San Diego, points out that the
Fortran input/output list and associated format provide a simple and
familiar example of a pair of co-routines.
39 'Revised Ironman': the technical requirements for the 'Department of
Defense requirements for high order computer programming languages', 1977
July.
This closely-packed specification will be of the greatest interest to those
who want to see what a current state-of-the-art design for a comprehensive
computer language is like. The abstracter feels that most.practising
programmers would be happy to use this language, provided its final
form retains the power with simplicity intended in this document, when
the language is standardized and accompanied by editors, interpreters,
diagnostic aids, program analyzers, documentation aids, testing aids,
software maintenance tools, optimizers and application libraries. Among
much discussed Fortran issues, Ironman Revised curtly specifies that the
language shall use the ASCII 64-character subset, that a 'break' character
shall be reserved for use in identifiers, that there be no restriction
on the length of identifiers or the number of dimensions in an array,
that Comments, enclosed within reserved parenthetic symbols, be permitted
anywhere, and that the language will have no subsets and no supersets.
An earlier document 'A common programming language for DOD ... ' (NTIS,
AD-A028 297/OWC, $6.75 pc / $6.00 mf) gives further background.
60 W.Brainerd, Burroughs Corporation, Paoli, Pa: A proposal for a Fortran loop
construct.
This would provide intermediate exits from the loop or loops (called
Leave's), with the feature that subsequent testing of a flag variable
would show which exit had been taken. These flag variables are listed in
an Until clause in the Do statement, and initialized to false when the
loop is started. Ingenious, or horrible?
73 F.Richard and H.F.Ledgard, University of Massachusetts: A reminder for
language designers.
A long account of what the authors consider good and bad features of
current programming languages. (Note that page 77 should be 79, 78 77 and
79 78.) It would be interesting to hear the authors' views on Revised
Ironman.
83 J.L.Peterson, University of Texas at Austin: On the formatting of Pascal
programs.
These quite specific indenting suggestions would also apply to Fortran.
87 M.G.Richardson, NAG Central Office: The use of names to indicate the scope
of structured language constructs.
The readability of the Fortran Do loop in the sense of the labelled matching
ending statement - compared with the difficulty of matching parentheses
over pages of code - should be retained in more fashionably structured
languages, by a facility for naming these parentheses. (Surely this is
just a call for a comment convention in the manner of Algol-58 - or
for the compiler to make a better job of listing the program?)
SIGPLAN NOTICES 13 (1978 January)
8 P.E.Schilling, New Kensington, Pa, agrees with Shapiro's letter (October,
cited above) on the poorer input/output facilities of Fortran 77 compared
with Cobol. He feels that separate input/output standards should be
prepared, each language adopting them in its own style.
14 D.M.Smith et al, NASA, Greenbelt: Optimization guide for programs compiled
under IBM Fortran H (Opt=2), 174 pp, 1977, NTIS, NIT-26827/4WC, $8.00 pc /
$3.00 mf.
16 O.Benediktsson, University of Iceland: Notes on argument-parameter
association in Fortran.
The Fortran 77 draft in Sigplan Notices 11 (1976 March) and various Fortran
texts and manuals are uncertain whether scalar arguments are passed 'by
reference' (receipt by location) or 'by value result' (receipt by value,
and copying back). Compilers differ too, as tests show.
70 D.B.Wortman, University of Toronto: A roster of XPL implementations.
XPL is a language for writing compilers in.
75 S.M.Bellovin, University of North Carolina: Alphabetical list of
authors, and KWIC index to Sigplan Notices volume 12.
FORTRAN NAMING AND STATEMENT NUMBER CONVENTIONS
J.D.Murchland
University College London Transport Studies Group
Gower Street, London WC1E 6BT, 01-387 7050
I would be interested to hear of any reports on conventions for choosing
variable names and statement numbers in Fortran programs - or, indeed, of
personal rules and preferences in these matters. The major report by
D.T.Muxworthy, 'A review of program portability and Fortran conventions',
European Computer Program Institute, Ispra, Technical Paper Series number 1
(1976), has a number of asides and references on this.
Obviously it is not easy to find conventions of real benefit. It appears
to be substantially a personal and psychological matter. However, two
conventions which to me seem well worth adopting are given below.
A convention sometimes used is to extend the implicit Fortran type
convention for names, using, say, an initial A to denote alphameric (text),
B Boolean, C complex and D double precision. This seems to me unnecessary
when (in IBM Fortran) dimension information can be given in type statements,
when the lists of variables in type and Common statements are kept in strictly
alphabetical order, when most variables are declared, and when the program
is not part of a very large system (with numerous subroutine calls with many
diverse arguments).
Qualified names
The aim is to have a systematic way of constructing names for related
quantities - so that the coder can invent the names without effort, and a
reader of the program can anticipate what the names will be.
Prefixes: J integer form of a real quantity
N number of, or dimension of
R real form of an integer quantity
Suffixes: L lower value or lower limit
P past or previous value, or prime (i.e. ' )
U upper value or upper limit
An associated convention is that the name for a variable equal to W(J)
should be WJ .
As examples, the dimension of a vector ALPHA will be NALPHA , the
number of cases would be NC or NCASE , over an iteration the change in a
quantity X would be X-XP (current minus previous value), or XK - XKP if
it is the Kth element of a vector, and the real value of NC would be JNC .
The lower and upper suffices are used both for index limits and for minimum
and maximum values of variables. Thus for a DO loop
JU=NX-1
DO 10 J=1,JU
..
while for a range check on a data field F52
IF (F52.LT.FS2L .OR. F52.GT.F52U)
1 CALL MSG('OUT OF RANGE@',2,F52,F52L,F52U,...)
(where MSG is a suitable error handling routine).
Other suffices could be added to the list - the question is which ones
would be worth standardizing on? Two candidates are S , for sum or sub-total,
and T , sum of sums or total. I should mention that two upper limits are
sometimes needed: an ultimate maximum dictated by storage or other size
limitations, and the smaller actual maximum. In this case I use H (for high)
for the smaller one.
Statement numbers
The following avoids the risk of duplicate statement numbers, provides
plenty of numbers, keeps the numbers in order,helps structure the program,
and makes Formats readily distinguishable. (I should say that my preference
is to keep Formats next to the input or output statement that uses them, and
not all together in a separate block. Opinions are strongly divided on this.)
1. Regard statement numbers as fractions, not integers. Thus 235 comes between
23 and 24.
2. Punch statement numbers left justified to column 2, increasing readability
by avoiding column 1 and the continuation column 6.
3. Divide the program into a convenient number of sections - less than ten.
Guess the likely number of statement numbers that will be needed and
number the sections 10, 20, 30, .. or 100, 200, 300, ... accordingly.
The former provides about three numbers per section, the latter about
a score.
4. Avoid numbers below 10 or 100.
5. Use numbers sequentially in each section at a suitable interval of 2 or 4,
roughly anticipating where extra numbers may be needed later.
6. Obtain Format numbers by adding 9000 to a nearby statement number. For
example, 9042 near a statement 42. (This preserves the sequence by
providing, in effect, a distinct duplicate sequence.)
7. Format numbers are left-justified to column 1.
This system is primarily for hand use ~ obviously if it is easy to
renumber mechanically (as in Basic) a strict equal interval sequential system
can be used. However, I do find in a program that I prefer to maintain the
original sections, and the numbers that have become familiar, and that the
need or wish to renumber is small.
The following (genuine) fragment of code illustrates these conventions.
(The variable I is normally to be avoided because of the difficulty in
distinguishing it from 1 on listings, but here it agreed with the mathematical
notation. This fragment does not show sections,or statement numbers increasing
at a more usual spacing of 2 or 4. The first part of the code is finding JU ,
not using it.)
JU=1
19 DO 22 K=1,KU
P(K)=JU
DO 20 J=JU,NZ
ZJ=Z(J)
IF (ZJ.EQ.0) GO TO 21
F(ZJ)=A(K)*F(ZJ)
20 CONTINUE
CALL ERROR(20)
21 JU=J+1
S(K)=SF*S(K)
22 CONTINUE
P(KU+1)=JU
C
C SCALE C IF NECESSARY
CF=1.
IF (1..LE.CU .AND. CU.LT.100.) GO TO 23
CF=10.**(99-INT(98.+ALOG10(CU)))
PRINT 9023,CF
9023 FORMAT (' C VALUES SCALED BY',F14.6/)
23 DO 24 I=1,IU
C(I)=CF*C(I)
24 F(I)=F(I)*C(I)
C
C LIST REST OF DATA
PRINT 9024,(C(I),I=1,IU)
9024 FORMAT ('0 C:',(' ',T6,1OF8.4))