BRITISH COMPUTER SOCIETY FORTRAN SPECIALIST GROUP
Minutes of a Meeting held
on Thursday, 7th December
1972 at Barnard's Inn,
Holborn Bars, London EC1
at 10.30 am.
Present: Mr J.S. Gatehouse (Chairman) G.E.C
Mr E.O. Bodger IBM Information Services
Mr P.D. Bond Philips Industries
Mr H.W. Bradly C.A.D. Centre, Cambridge
Mr R.L. Butchart D.T.I.
Mr J.C. Cullen B.P.
Dr A.C. Day University College London
Mr I.D. Hill M.R.C.
Mr K. St. Pier G.E.C.
Mr B.H. Shearing Alcock Shearing & Partners
Mr D. Winstanley University of Birmingham
Mr D.T. Muxworthy (Secretary) Edinburgh R.C.C.
for Mr P.J. Hammond B.P.
Absence: Mr D.J. Maisey I.C.L.
Mr D.H. Marwick Heriot-Watt University
l. APPROVAL OF MINUTES The minutes of the meeting of the 21st September
1972 were approved.
2. MATTERS ARISING FROM a. Members of the Diagnostic Working Party had each
THE MINUTES been asked whether they were prepared to revive
the activities of this group. No response having
been received, the Diagnostics Working Party was
formally wound up.
b. There had so far been a disappointing response to
the invitation to contribute information on
deviations of compilers from the ANSI Standard.
It was thought that SPL were working in this area
and it was decided to forward the four contribu-
tions to Mr Kelly and to ask him to decide further IDKK
action, possibly in association with SPL. Any new
offerings are welcome and should be sent to
Mr Kelly at 96 Kings Road, Walton, Surrey.
The Editor of the Computer Bulletin had been cont-
acted about early replies to letters and had
answered that if any letter was concerned with the
activities of a specialist group he would contact
the Chairman of the Group before printing it.
However as the Bulletin was suspending publication
the question was now hypothetical.
A copy of the Chairman's letter had been sent to the
Editor of the Computer Journal, who had replied that
it was not current practice to send letters to
interested parties before publication, although this
policy may be changed. The Group was invited to
use the Journal to report the conclusions of its
investigations. The Secretary was to invite DTM
Mr Hall, whose letter in the Journal of August
1972 was of this type, to join the Group.
d. It was decided to submit reports of each Group
meeting to "Computing", the successor to the
Bulletin. As a trial, the Secretary would send
a note of topics covered to Mr Shearing, who DTM/BHS/
would write an article in a suitable style JSG
and submit this to the editor of "Computing",
after showing it to the Chairman.
e. No further members of the Group had expressed
interest in the proposed Language Contractions
Working Party. Mr Gatehouse was to contact those JSG
who had put forward their names at the last
f. There had been no reply to the Group's views on
the Computer Journal Algorithms Supplement policy
3. BSI REPRESENT- The British Standards Institute had invited the
ATION Specialist Group to nominate a member of the BSI
DPE/13 (Programming Languages) committee.
Mr Gatehouse had accepted the invitation on the
understanding that he could ask other members of
the Group to attend meetings in his place.
4. HIGH LEVEL Mr Shearing reported that the principal languages
LANGUAGE CONFERENCE discussed at the conference were Algol 68, Cobol,
Fortran and PL/I but it appeared that there would
be no universal language in the foreseeable future.
The conference had helped to alter the impression
that Fortran was a dying language and the audience
had been impressed by the fact that the new Fortran
standard would be compatible with the old.
Arising out of this conference the Chairman had
become aware of "Shell Standard Fortran" and
"Shell Standard Basic Fortran", the former being
the common subset of IBM 360, XDS Sigma 7,
Univac llO8 and Univac 9400 dialects expressed in
the style of the ANSI Standard.
5. DATAFAIR 73 The Group was to organize a discussion session,
"Fortran - the way ahead", at Datafair 73 on April
11th from 3.00 pm to 4.45 pm. It was decided that
Mr Gatehouse should chair the session and that
members of the extensions working party should give
short presentations of the more interesting of the
proposed extensions to the ANSI Standard. An
audience of between 25 and 150 was expected. DTM
6. ISO TC 97 METING The BSI had invited the Specialist Group to nominate
a delegate to the ISO TC97/SC5 (Programming
Languages) meeting in Washington D.C., held on
November 28 to December 1st 1972. Dr Day had
attended the meeting as the Fortran delegate and
Mr Hill as chairman of the Algol subcommittee.
Seven countries, France, Japan, UK, USA, Germany,
the Netherlands and Switzerland were represented at
the meeting and of these the first four attended the
Fortran working sessions. Seven members of X3J3
Dr Day reported that X3J3 were completing work on
their revision of the Standard and were now
courting international opinion with a view to the
new standard being accepted by ISO as well as by
ANSI. It was probably too late to add significant
new features but it was possible to remove or amend
extensions which had been approved but which were
disliked. A formal resolution that the new standard
be "totally compatible" with the old had been defeated
2-4 but one to the effect that the greatest care be
taken to avoid incompatibility and that any incompat-
ibilities be documented was approved. Members of
X3J3 wanted the current ISO recommendation, R1539,
to lapse so as to enable different subsetting of the
new standard. ANSI are to forward copies of the
draft proposed American National Standard (dpANS)
as soon as it is available; the question of BSI or
BCS reproducing this was raised but not pursued.
Dr Day distributed a note on proposals to be sent
from the Group to X3J3. This had been revised
following a meeting of the Extensions Working Party
the previous day and there followed a detailed
discussion of the paper. The version ultimately
sent to the Chairman of X3J3 appears as Appendix A
to these minutes.
The Group wishes formally to record its thanks to
Dr Day for all the work he has done in connection
with the meeting, and its thanks to the National
Computing Centre Ltd. and to University College
London for making the visit possible.
It was made clear that X3J3 welcome comments from
individuals on their proposals. Comments may be sent
to the Chairman:
Mr F. Engel Jr,
179 Lewis Road,
Belmont, Mass. 02178.
and/or to the X3J3 member with special responsibility
for international liaison:
Mr J.C. Noll,
Holmdel, N.J. 07733.
Mr Noll is also on the editorial subcommittee of
X3J3 and any editorial comments may be addressed
to him. Constructive criticism on editorial matters
is always welcome.
7. DATE OF NEXT The next meeting will be held on Friday, March 2,
MEETING 1973 at 10.30 am. The place of the meeting has been
provisionally arranged to be the Tearoom of Barnard's
December 8th 1972
TO: ANSI X3J3
FROM: BCS Fortran Specialist Group
SUBJECT: Proposals concerning the new Fortran standard.
PROPOSAL l. That the SUBARRAY statement be removed from the new
Rationale: (a) Subarrays are irregular (compared with arrays) in
terms of the places where they may appear. They cannot be
used as arguments to subprograms. It is not certain whether
they may appear in I/O lists. They may not be used for a
FORMAT specification, as the storage may be non-contiguous.
They cannot occur in DATA lists, as they may be controlled
dynamically by means of variable subscripts.
(b) The subscript expressions permitted by the new
standard in DIMENSION and type statements cannot be allowed
for the subscripts in SUBARRAY statements, as this would imply
deferred evaluation of expressions, causing very great
inefficiencies for each subarray reference. Redefinition of
adjustable dimensions will not have any effect in a DIMENSION
or type statement, but the reverse is true for SUBARRAY.
(c) Ad hoc restrictions must be imposed to prevent
recursive definitions. Although the X3J3 proposal does not
say so, presumably array element references are not allowed in
the subscripts, as otherwise the following statement would be
SUBARRAY JIM(34) AT A(JIM(2))
Even without this problem, recursion can occur, as shown by:
SUBARRAY JIM(34) AT A(25), A(45) AT JIM(32)
(d) If the proposal for subarrays is to be compatible
with the new rules for DIMENSION and type statements, then
lower bounds should be included, introducing further complications.
(e) The syntax for the statement is peculiar. It has
keywords in the middle of the statement, a situation matched
only by the ASSIGN statement.
(f) The 'principle of least astonishment' is violated
in such examples as:
DO 13 I = 1, 15
13 A(4) = B(4)
Here the loop can only be redeemed from the realm of nonsense
(or from being optimised out of existence) by being preceded
by statements such as:
DIMENSION C(55), D(55)
SUBARRAY A(6) AT C(I), B(6) AT B(I)
(g) The SUBARRAY statement is not likely to be of help
PROPOSAL 2. That reverse cross-sections of arrays be removed from
the new standard.
PROPOSAL 3. That array cross-sections be removed from the new
Rationale: (a) As with the SUBARRAY proposal, the problem of non-
contiguous storage is introduced. Cross-sections may therefore
not be passed as arguments to a subprogram, and may not be used
for a FORMAT specification.
(b) If cross-sections are nevertheless passed as arguments,
the irregular situation arises whereby correct results may be
obtained only if the cross-section is forward and is based on
the first subscript.
(c) Ad hoc rules need to be added so that an array
assignment statement using cross sections does not cause
overlapping to occur.
(d) For reasons of regularity, many repercussions of
this proposal must be considered. Are cross-sections to be
permitted in I/O lists? Or block transfer list items in an
assignment statement? These are apparently two proposals to
do very similar things, but have quite different limitations
(one cannot step backwards, and the other cannot refer to less
than a complete cross-section). Are cross-sections to be
permitted in DATA statements? Or implied DO loops in
assignments? Have cross-sections of subarrays been considered?
This whole area seems rather ill thought out, with partial
extensions criss-crossing one another.
PROPOSAL 4. That the order of specification statements must not
be more restrictive than in the present standard.
Rationale: (a) As the meeting of ISO/TC 97/SC 5 showed, there is
very great pressure for the new standard to be compatible with
the old. To restrict the order of specification statements
would be an incompatibility of the first magnitude, which
would invalidate a considerable proportion of the programs
which currently conform to the standard.
(b) If the justification for this restriction is in
order to make things simpler for a one-pass compiler, then
the restriction could well be made a feature of one of the
lower subsets of the new standard. However, as far as we
can see, this should not present problems even to a one-pass
compiler. We are not sure whether the proposed restriction
would involve DATA statements, and we would appreciate
further information on this point.
PROPOSAL 5. That the length of variables defined in a CHARACTER
statement should be given in parentheses instead of
following an asterisk and preceding a comma. The length should
only occur following the keyword CHARACTER, and then applies to
every variable defined in that statement.
A comparison is made here of Boswell's 'Compromise
Syntax' and 'BCS Syntax' to show how they correspond.
Compromise Syntax BCS Syntax
CHARACTER*5, A(l0),B(2,2),C CHARACTER(5) A(l0),B(2,2),C
CHARACTER*(N), D CHARACTER(N) D
CHARACTER*(*), E(11) CHARACTER(*) E(11)
CHARACTER*(N*M), F(13) CHARACTER(N*M) F(l3)
CHARACTER*3, G, H*5 J CHARACTER(3) G, J and
Rationale: (a) According to the X3J3 proposal, parentheses would
be necessary only if the length was not a constant. The
asterisk and comma are always needed. If parentheses are
always obligatory the rule is perfectly simple and regular,
and both the comma and the asterisk may be dispensed with.
(b) The X3J3 proposal is unsatisfactory in such cases
as the declaration for G, H and J above. The inexperienced
user is liable to wonder Whether the length of J is 3 or 5,
as he will have learnt from the P factor in a FORMAT statement
and from the COMMON statement that a change made in the
middle of a statement may apply to succeeding items.
(c) It seems very probable that future Fortran standards
will include precision of numeric variables. This should be
declared in terms of decimal digits, and for economy of syntax
should parallel the length feature of character variables.
However, the asterisk notation is used by IBM for precision
in terms of bytes. We should therefore avoid this notation
for representing the length of character variables.
PROPOSAL 6. That the new standard should allow programmer-defined
functions of CHARACTER type, returning a fixed length
character value whose length has been declared in both the calling
program and the function itself.
Rationale: (a) If CHARACTER type is introduced, it should be a
fully regular type, matching in every way possible the types
(b) Although a variable length function may well be
preferable, this seems out of the question at the present time.
It is nevertheless better to be able to write fixed length
character functions rather than none at all.
(c) It should be easy to implement such functions,
seeing that the amount of storage required for the value is
known to both calling and called segments, just as for words
requiring one or two words for the result. If character
arguments may be transferred, then character functions can be
implemented, as the value returned can be treated as an
PROPOSAL 7. That the implied DO in an I/O list should be extended
in the same way as the DO statement, allowing
expressions as the parameters, and real or double precision
variables as the control variables. Function references in the
expressions must not cause I/O operations to be performed.
Rationale: (a) The two types of loop-controlling features should
be kept in step for reasons of regularity.
(b) A real or double precision control variable could
in certain circumstances be very useful. The I/O list may
contain a function reference for which one argument should be
the control variable, or it may be necessary to write out a
regular series of real values. The same extensions cannot,
of course, be applied to the DATA statement, as any implied
DO there must be interpreted at compilation time.
PROPOSAL 8. That an alternative keyword should be found for the
We agreed in our dislike for "PARAMETER", but we were not
able to reach full agreement on any other term. "CONSTANT" won
most approval. Other keywords suggested were "HOLD", "SYNONYM",
"EQUALITY" and "IDENTITY".
Rationale: (a) The term PARAMETER is used widely to describe an
argument. This will cause much confusion, as the items
defined by the statement are certainly not arguments.
(b) Although ill-phrased references to CONSTANT variables
may be confusing, it is true that the items declared by means
of this statement are symbolic representations for constants,
and some term should be chosen which reflects this fact.
(c) It may well be true that the only implementation
of this feature uses the term PARAMETER, but the fact that the
first implementor got the term wrong should not be used as a
reason to foist this unfortunate error on the whole Fortran
PROPOSAL 9. That the BACKSPACE, REWIND, ENDFILE, SKIPFILE,
BACKFILE and any other statement referring to I/O
operations should permit the unit reference to be:
Rationale: This is in order to maintain and increase the regularity
between these statements and the READ, WRITE, OPEN and CLOSE
statements (see Proposal 13).
PROPOSAL 10. That the INQUIRE statement not be added to the new
PROPOSAL 11. That direct access READ and WRITE statements be
permitted in Fortran, differing from the corresponding
sequential READ and WRITE statements by the addition of the
within the parentheses enclosing the unit designation.
PROPOSAL 12. That wherever the new standard includes as keywords
abbreviations of English words (e.g. ERR, REC), the
full word also be permitted as an alternative (e.g. ERROR, RECORD).
PROPOSAL 13. That OPEN and CLOSE statements be permitted of the
OPEN (UNIT=value, NAME=charvalue, ERR=label)
In the OPEN statement, the specification of NAME and EPR
are both optional. If the unit designation comes first within the
parentheses, then "UNIT=" may be omitted. If the unit is specified
by an integer constant or an integer variable, and no other
information is given by the OPEN statement, the parentheses may be
omitted, and the statement takes the form:
The OPEN statement is executable, causing the program to become
associated with the file. The charvalue above is a character
value which provides a way of referring to the file in terms
external to the Fortran program. If it is not possible to
associate the program with the file, execution continues at the
statement specified by the label. All other attributes of the
file (old or new, device type, record length, label type, protection,
direct or sequential, keyed or unkeyed, space, disposition on
closing, blocking factor etc.) will (if they are necessary) be
given outside the Fortran program. If an OPEN statement for a
particular unit has not been executed, the first READ or WRITE
statement for that unit will implicitly open the file.
The CLOSE statement is also an executable statement,
causing the program to become disassociated with the file. In
this statement "UNIT=" may be omitted, in which case, if the unit
designation is an integer constant or an integer variable, the
parentheses may also be omitted, and the statement takes the form:
Rationale: (The X3J3 proposals referred to here are those which
were described at the Washington meeting of ISO/TC 97/SC 5.)
(a) As "keyword parameters" have already been included
in the proposed new standard through "END=" and "ERR=" it
seems good to use this syntactic technique elsewhere.
However, the X3J3 proposals have parameters which are in a
sense "keyword" and yet have no equals sign (e.g. VARYING).
These have no parallel in Fortran. If OPEN is to be made
regular with READ and WRITE, so that "UNIT=" may be omitted if
the unit is given first, then ambiguity results, since a
keyword such as NEW cannot be distinguished from a variable
unit number if it is in the first position.
(b) Some of the proposed features of the OPEN statement
are incompatible with the present Fortran standard. For
instance, specifying whether a file is formatted or unformatted
contradicts the present possibility of writing on one unit
with a mixture of formatted and unformatted WRITE statements.
The VARYING option does not do anything, as at the moment one
can read records of different lengths provided that the I/O
list plus the format tally; with the new option one must still
provide an I/O list (and format) of the correct length. The
new standard should allow a mixture of direct access and
sequential I/O statements to be used with the same file.
(c) The proposed INQUIRE statement uses keyword
parameters to specify variables which are to be given values.
The result is similar to an assignment statement in which the
assignment is from left to right, and is highly undesirable.
(d) It appears that the aim of the X3J3 proposals has
been to include all features of the file, so that non-Fortran
control statements may be eliminated, a state of affairs which
may be especially helpful to users of terminals. This has
not been successful. Some features which will be of vital
necessity have not been included, e.g. the number of records
for a new direct access file. Some features place an
intolerable burden on the operating system, e.g. using INQUIRE
to find the maximum record length of an unlabelled magnetic
tape file, which involves reading every record. It is
impossible to specify the device type required for the file
without including in the Fortran language a list of obsolescent
devices which will rapidly become incomplete, and yet it may
be necessary for the user to inform the system of the device,
even for scratch purposes. For these reasons it seems clear
that Fortran should not be used to give information about the
file which is not needed by the Fortran program.
(e) The BCS proposals given above are both simple and
effective in providing new I/O facilities for Fortran. By
means of the "ERR=" parameter in the OPEN statement an enquiry
can be made as to whether an old file exists, or whether there
is sufficient space available for a scratch file. Ry the use
of OPEN and CLOSE statements different files may become
associated with the same unit number at different times during
execution. External names can be read in from the data and
used in the NAME parameter of the OPEN statement. By means
of CLOSE, devices may be unloaded and freed, or scratch space
may be released.