BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP
MINUTES of a Meeting held on 21st August 1978 at Imperial College, London.
Present:
P.A.Clarke (Chairman) Rothamsted Experimental Station
L.F.Bennett Civil Aviation Authority
G.L.Harding ECMRWF
D.Hill Central Computer Agency
I.D.Hill Medical Research Council
D.J.Holmes Rolls Royce Ltd., Bristol
P.Loftus Marconi-Avionics (CFC)
D.T.Muxworthy Edinburgh R.C.C.
T.L.van Raalte Ministry of Defence
L.Rice NIBSC
G.A.Ruscoe Honeywell I S Ltd. - NISD
J.D.Wilson University of Leicester
J.M.Roberts-Jones (Secretary) Liverpool City Council
Apologies for Absence:
B.Meek Queen Elizabeth College
J.D.Murchland University College, London
1. APPROVAL OF MINUTES.
The minutes of the meeting of 5th June 1978 were approved.
2. MATTERS ARISING FROM THE MINUTES.
Mr.Ruscoe asked that it be made clear that the compiler mentioned by Mr.
Stewart as being a complete Fortran 77 implementation is that available to users
of the (U.S.) General Electric Company MARK III Service. (Honeywell's Network
Information Services Division has responsibility for providing access to the
network from the United Kingdom, Italy and Australia.)
3. ACTIVITIES OF OTHER FORTRAN GROUPS.
3.1. ISO/TC97/SC5.
Fortran 77 has now been approved by SC5 letter ballot and passed to TC97 for
final approval. The proposed ISO standard consists of the text Of ANSI X3.9-
1978, together with an explanation of its relation to former ISO standards.
3.2. BSI/DPS13/WG2. (real-time languages).
Dr.Rutherford of UMIST has resigned from the Working Group; Anton Walter of
Rutherford has offered to act as FSG Representative.
3.3. BSI/DPS13/WG6.
Mr.D.T.Muxworthy, the Convener of the working Group, is collating U.K.
comments on Fortran 82 in preparation for the November ad-hoc meeting of ISO/
TC97/SC5, the function of which subcommittee is to advise ANSI of other countries'
requirements.
Invitations to submit comments have been publicised by means of articles in
various publications and by distribution of three hundred copies of a question-
naire. (A copy was included with the last FSG mailing; if you have not yet
replied, please return it as quickly as possible.)
David Muxworthy presented a summary of the organisation adopted by X3J3 in
developing the next Fortran standard. he described the progress made by the
several subgroups, summarising the proposals under consideration by each sub-
group and leading a discussion as to their merits.
It is hoped that WG6 will in due course make a summary of collected U.K.
responses available to FSG.
The minutes of the May and August meetings of X3J3 were reviewed; significant
technical discussions of the committee included:
a) Clarifications in response to Fortran 77 Issues up to #10 were confirmed.
A summary is given in Appendix A; a copy of X3J3/101 giving the full
text is available from the Secretary.
b) Following an earlier decision that future Fortran revisions should be
structured as a core language supplemented by optional modules, it was
noted that a distinction appeared to exist as between "features modules"
and "applications nodules". Features modules would provide language
extensions such as additional data types or control structures, and
would normally be developed directly by X3J3; applications modules would
address particular user areas such as data base, real time or graphics
and might be developed elsewhere to an agreed interface.
c) A difficulty with extensions for some applications arises in determining
which capabilities can adequately be implemented using normal CALL state-
ments without introduction of new keyword statements. In some areas,
such as data base access, there is a requirement for compile-time check-
ing of arguments, more stringent than is possible under the traditional
Fortran approach of independent compilation.
Proposals were discussed for allowing a program unit to contain specific-
ations of procedures that it referenced and for an INCLUDE statement
providing a capability for incorporation of source text at compile-time.
The specification of a procedure could be enhanced so that as well as
indicating the number and types of arguments, positional arguments could
be mapped onto keyword arguments and default values could be supplied.
For example, given the specification
PROCEDURE SUBR (REAL RESULT, REAL XCOORD = 0.0, REAL YCOORD = 0.0,
CHARACTER*(*) NAME = 'NONE')
the following two statements would be equivalent:
CALL SUBR (NAME = 'FIRST-RUN', YCOORD = 5.4, RESULT = RESULT)
CALL SUBR (RESULT, 0.0, 5.4, 'FIRST-RUN')
Instead of using PROCEDURE, the EXTERNAL statement could be extended.
If statements such as INVOKE implied inclusion of appropriate
specifications, a more flexible and robust interface mechanism might
be achieved.
(D.Hill: Much prefers EXTERNAL to PROCEDURE; the latter keyword could be
needed for internal procedures. INCLUDE would have other advantages,
such as in setting up declarations of labelled common.)
(G.A.Ruscoe: Would prefer not to write CALL; if omitted, the flavour of
a new keyword would be obtained. For labelled common, would advocate a
compiler option to allow any declaration in one program unit to be used
automatically in succeeding units.)
d) An editorial change which had been made to the syntax charts in an
Appendix was approved. The chart now indicates that the comma may be
omitted between a P edit descriptor and an immediately following repeat
specification and F, E, D or G edit descriptor. '1P2E10.2' would be
valid as well as '1P,2E10.2'.
(J.M.Roberts-Jones: This does not accord with the wording of X3J3/90;
the standard explicitly prevails over Appendix F in event of conflict.)
e) A first draft of the core language was agreed. The core is intended as
a viable general-purpose language of no less power than Fortran 77, but
with many of the more troublesome features of Fortran 77 removed to a
separate module for eventual deletion from the full language on a very
long time scale.
Add free form source, a larger character set and longer names; withdraw
column 6 continuation and column 1 C for comment conventions.
Add simple data structures, some array processing statements and global
data definition; withdraw EQUIVALENCE, COMMON, BLOCK DATA and passing an
array element or array element substring to a dummy array. (To provide
equivalent capability but without notions of storage association that
can lead to bad programming practices).
Add looping and case control structures, and internal procedures;
withdraw arithmetic lF, computed GO TO, alternate return, ASSIGN and
assigned GO TO, statement functions.
Add precision specification for REAL; withdraw DOUBLE PRECISION.
Withdraw redundant features: ERR= and END= (use IOSTAT), H, X, D edit
descriptors (use apostrophe, TR, E), specific names of intrinsics (use
generic names).
Withdraw entry association.
Enhance subprogram linkages.
Add bit data type.
(J.D.Wilson= As well as global data definition we need global constant
definition: otherwise problems arise with PARAMETER as with COMMON.)
f) Requirements for internal procedures (IP's) were agreed.
i) IP's for functions and for subroutines, with arguments;
ii) Any declarations relating to an IP to appear within it;
iii) No definitional nesting of IP's;
iv) IP definitions to be located at the end of the program unit, before
the END statement;
v) IP definitions to be explicitly terminated by some keyword;
vi) IP's to be invoked by CALL or function reference.
g) It was agreed to try to specify a variant program form for use with on-
line terminals on a shorter time scale than that anticipated for the next
full revision of Fortran.
h) The committee was unable to reach agreement on Fortran 77 Issue 11 which
is concerned with whether the prescribed order of evaluation must be
followed strictly even if a different sequence can be guaranteed to be
computationally equivalent; in particular, may a standard-conforming
processor transform .NOT.(X.GE.10.) into X.LT.10. ?
4. WORKING PARTY REPORTS.
4.1 Fortran DML.
Further progress has been made in drafting a working paper. Mr.S.Knowles has
retired due to pressure of work.
4.2 Group Information.
A revised contact list is being prepared.
4.3 Fortran 77 Summary.
This working party is believed to be extinct.
5. OTHER FORTRAN EVENTS.
It was noted that a paper by Brainerd based on Fortran Forum presentations by
members of X3J3 is scheduled for publication in the Communications of the A.C.M.
in October.
6. OTHER BCS BUSINESS.
The Group will not be able to make a presentation at BCS'79 as all sessions
are now filled.
7. ANY OTHER BUSINESS.
Ann Rogers of SWURCC has made available two documents defining the common
subsets of ICL 2900 Fortran with System 4 and with CDC FTN implementations.
8. DATE OF NEXT MEETING.
The next meeting will he held on Monday 2nd October 1978 in Room 4-34, Royal
School of Mines, Imperial College, Prince Consort Road, London SW7, from 11 a.m.
to 4 p.m. A major topic for the morning session will be continued discussion of
BSI/DPS13/WG6 activity. In the afternoon, starting at 2 p.m., Mr.W.D.Manville
of GEC Computers Ltd. will describe the Fortran system for the GEC 4080.
It is hoped that it will be possible to take advantage of the presence in
this country of many distinguished overseas visitors at a meeting, possibly on
Monday 4th December 1978. The venue and format have not yet been determined.
APPENDIX A - Clarifications of Fortran 77 Issues 1 to 10.
1. A type statement has no effect on intrinsic functions; in particular, it does
not cause a generic function to lose its generic properties.
2. After an OPEN statement is executed on a file that was not connected, the
position of the file is processor-dependent.
3. After an occurrence of an input error, any IOSTAT specifier will be defined,
but no assumptions are possible about the definition status of any item in the
input list.
4. If C is an entity of character data type, the statement
READ (C)
contains a character format expression, (C); unformatted I/O is not permitted
with an internal file.
5. A standard-conforming processor may impose limitations on the size or
complexity of programs it will accept. In particular, it may decline to handle
57 sets of nested parentheses.
6. In the program unit
SUBROUTINE JOAN (C,N)
CHARACTER C(N)*(*)
. . .
END
the length of each element of the dummy array C is:
If the actual argument is an array, the length of an element of the actual array.
If the actual argument is an array element, the length of that element.
If the actual argument is an array element substring, the length of that
substring.
In all cases, successive elements of the dummy array appear contiguously in
the storage sequence of the actual array.
7. A standard-conforming processor may impose restrictions on the set of allowed
access methods forms or record lengths for certain units or files.
S. An IMPLICIT statement determining the data type of the symbolic name of a
constant must precede the PARAMETER statement defining that constant.
9. The effect of attempting to read beyond the end of an external file that
contains no endfile record is processor-dependent. A processor may have
conventions for creation of endfile records on detecting certain hardware
conditions such as card reader hopper empty.
10. The processor-dependent field widths, etc., used in list-directed output may
vary depending on the data as well as on the processor.
To FSG Members.
The holiday season is not usually the best time to distribute a
questionnaire expecting a fast response. But over half of those sent out
with the last mailing were returned within two weeks.
I hope to complete an initial analysis in time for the next meeting.
It would be much better if I could include everyone's views, hut there are
still a few dozen outstanding. Please let me have them as soon as you can.
I will assume that anyone who doesn't reply by the end of October no
longer wishes to remain on the mailing list.
John Roberts-Jones.