MINUTES of a Meeting held on 21st August 1978 at Imperial College, London.


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


The minutes of the meeting of 5th June 1978 were approved.


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


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.

3.4. ANSI/X3J3

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



the following two statements would be equivalent:



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


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.


The Group will not be able to make a presentation at BCS'79 as all sessions

are now filled.


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.


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


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



. . .


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


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.