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.


D.T. Muxworthy (Acting Chairman)        Edinburgh R.C.C.

P.A. Clark                              Rothamsted Experimental


J. Roberts-Jones                        Liverpool City Council

P. Loftus                               Marconi-Elliot Avionic

                                        Systems Ltd. (GEC)

B. Meek                                 Queen Elizabeth College,


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


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.


P.G. Barker (NUMAC) gave a talk on "PL/I a successor to Fortran".

PL/I as a successor to FORTRAN

P.G. Barker


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


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


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.


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.


  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


 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


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.


  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


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


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


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


 83   J.L.Peterson, University of Texas at Austin: On the formatting of Pascal


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.



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


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


  19  DO 22 K=1,KU


        DO 20 J=JU,NZ


          IF (ZJ.EQ.0) GO TO 21


  20      CONTINUE

        CALL ERROR(20)

  21    JU=J+1


  22    CONTINUE





      IF (1..LE.CU .AND. CU.LT.100.) GO TO 23


      PRINT 9023,CF


 23   DO 24 I=1,IU


 24     F(I)=F(I)*C(I)



      PRINT 9024,(C(I),I=1,IU)

9024  FORMAT ('0 C:',(' ',T6,1OF8.4))