MINUTES of a Meeting held at British Computer Society, London, Monday

4th June 1979.


G L Harding (Chairman)                 ECMWF

D Bailey                                       University of Salford

M Bereovici                                  University College London

P D Bond                                     Philips Industries

R Chapman                                  Marconi Avionics

I D Hill                                         Medical Research Council

W D Manville                                GEC Computers Ltd

J D Murchland                              University of Leeds

R Putra                                        Marconi Avionics

T L van Raalte                              Ministry of Defence

J D Wilson                                    University of Leicester

J M Roberts-Jones (Secretary)       Liverpool City Council


P A Clarke, D Hill, D Muxworthy, A Wilson


The minutes of the Annual General Meeting were approved.


Final accounts for the financial year 1978/79 were presented. (See

Appendix A). Negotiations with the Secretary-General as to the disposal of the

surplus resulting from Fortran Forum were still proceeding.

[Appendix A was not distributed with the minutes.]


The Secretary presented a summary of the minutes of the October to May

meetings of X3J3. (See Appendix B).

Various comments were made on the proposals for enhanced mechanisms for

argument passing. Several members stressed a requirement that compatibility

checking must be capable of being performed at compile-time. Bailey reported

that the Fortran 77 compiler for the ICL 1900 series being developed at the

University of Salford would in most cases check argument compatibility at load

time; the only run time checks would be on arguments of dummy procedures.

Murchland regretted that X3J3 appeared to be designing a new language

that would have little in common with traditional Fortran implementations; he

felt that many of the changes could he handled by prior use of a macro processor.

On the other hand, Bailey and Wilson thought that Fortran should be taught

strictly in accordance with accepted standards; in a university environment, i1

was not realistic to require use of preprocessors.

Bailey drew attention to the problems of parsing DO statements caused by

the trailing keyword TIMES.

There was discussion as to whether X3J3 were being too ambitious. Hill

pointed out that usually many of the features proposed for inclusion in a

language were eventually excluded. It was felt that at the present stage,

it was right to attempt to evaluate all suggestions. Most members present

thought that the next standard should specify a replacement language rather

than an allegedly evolutionary development of Fortran 77.

Bailey initiated a discussion of an apparently undesirable feature of the

proposals for BIT data type. Consider the effect of:

BIT * 11, A(100)

DO (100 TIMES)

A(8:9) = B'00'


This loop should be capable of efficient implementation, but in practice it

could be grossly inefficient. Because it would be possible to match an actual

bit array with a dummy array having elements of a different length, a compiler

would be obliged to realise A as an array of 1100 consecutive bits if it was

used as an actual argument. Roberts-Jones regretted that this aspect of the

concept of storage sequence association was apparently being retained; what was

required was the flexibility of Pascal, to write:

TYPE bit11 = PACKED ARRAY [1..11] OF [0..1];

VAR        a: PACKED ARRAY [1..100] OF bit11;

        b: ARRAY [1..100] OF bit11;


FOR i:= 1 TO 100 DO BEGIN a[i,8]:=0; a[i,9J:=0 END;

FOR i:= 1 TO 100 DO BEGIN b[i,8]:=0; b[i,9]:=0 END

The first loop economises on storage at the expense of execution time, and the

second allows the compiler to use additional storage to minimise the time.

Murchland was still convinced of the effectiveness of macro processing and

undertook to produce a paper.

[The next meeting was held on 3 September 1979]


Mr W D Manville described the Fortran system implemented on the GEC 4030

series. The system had been developed whilst Fortran 77 was still changing.

He explained the reasons underlying the choice of features for inclusion in the

first release, and described in some detail the method used to evade an

apparent difficulty caused by an idiosyncrasy of the hardware addressing


GEC header

language description

GEC compilers



Various clarifications to Fortran 77 have been formulated - see X3J3/101.


In October there had been considerable debate. It was noted that ECMA/TC8

fully supported the core-plus-modules approach, provided that the core included

the totality of Fortran 77, that all combinations of modules were compatible

and that any functionality common as between modules was defined identically;

they had also suggested that for database interfacing, intrinsic subroutines

should be implemented (with the nature of the arguments being known to the


Greenfield had remarked that "the one central attribute of Fortran is

its name".

Olson had been extremely dubious about deletion of features. Fortran

might be archaic and obsolete, but there was a great volume of code still being

used and modified. Fortran was the most portable language, its compilation and

execution were efficient and the language was simple to learn and easy to use.

Fortran 66 compatibility would be demanded for a long time to come.

Brainerd pointed out that many major obstacles had been encountered. whilst

features such as storage sequence sequence association were retained, there

would be grave difficulties in meeting such requirements as for array extensions

and precision specification. The core-plus-modules approach had resulted from

attempts to break the deadlock; if that approach was rejected, the underlying

problems would still be there.


It had been accepted that, particularly now that DO extended ranges had

been abolished, there was urgent need for provision of some form of procedures

internal to a program unit. There had been much discussion as to the scope of

names used in internal procedures. In October, it was decided that the only

names local to an internal procedure would be the names of its dummy arguments

type and dimension declarations for them would be permitted. In January, the

scopes of statement and format labels were discussed but no technical votes

were taken at that meeting.

In March, a provisional specification was agreed. Internal procedures

would appear at the end of the enclosing program unit, and be bracketed by an


An IP could contain DIMENSION and type statements in respect of its dummy

arguments. The scope of an IP name would be the enclosing program unit. The

ENTRY statement and alternate return would not be provided. IP's could not

be invoked recursively. Branching into or out of an IP would not be allowed.

FORMAT statements within an IP would not be accessible from without.

Some questions, mainly concerned with scoping rules, were deferred for

subsequent resolution.


Two distinct types of module had been identified. Language modules would

provide extensions to core Fortran including new statements and syntactic

constructs. Such modules would each add to the size of the language. They

would normally be developed by X3J3. An example would be an array extensions


Procedural modules could be defined in terms of Fortran itself. They would

use Fortran to define new capabilities for Fortran programmers without

increasing the actual size of the language. Such modules might be developed by

groups other than X3J3. Examples might be the ISA standards, mathematical

libraries such as IMSL, SSP and SPSS, and procedural database interfaces.

Procedural modules needed better interfacing tools. There were clear

needs for more powerful procedure specifications, including type definition and

default values for arguments, for additional syntax at the point of call,

including keyword specification of actual arguments, for a name management

mechanism to avoid conflicts between modules, and for an INCLUDE mechanism to

copy in procedure specifications, which would normally be supplied by the

designer of a module and not by its users.

The database working group had requirements for execution time error

handling, for an INVOKE mechanism, for record structures with variants, for

keywords at the point of call, for additional types of actual arguments such as

enumerated sets and implied-DO lists, for variable numbers of parameters, and

default values, for full declaration of external procedures and their arguments

and for parameter consistency checking.

Although various proposals had been considered, no decisions had been

taken so far.


It was accepted that it was necessary to provide for machine-independent

specification of real and complex precisions. A discussion in October had

tended towards specification in terms of decimal digits, so that REAL*10, A

would require that A be held to any precision providing at least 10 decimal

digits. Exact correspondence would be required as between the precisions of

dummy and actual arguments.

An alternative use of REAL*1 for the default precision, REAL*2 for double

precision, etc, was not then liked because it seemed to rule out use of less

than the default precision- However, it appears that such specification in

terms of precision levels is now being favoured.


X3J3 had examined many possible looping constructs in great detail.

A preliminary decision had been taken, to provide initially one very simple

construct that was capable of extension to include any or all of the other

features investigated and which could if necessary co-exist with Fortran 77

DO loops. Since the new construct was felt to be more regular, X3J3 would in

fact propose to replace the present DO mechanism. The conversion impact would

be slight because automatic translation would be easy.

A loop would have the form:

DO [optional control clause]



The construct has an explicit terminating statement to avoid the irregularity

of the present DO loop. A DO-block is a sequence of statements similar to a

block, but it differs from a block in that it may contain loop exit statements,

having the form:


Execution of a DO-REPEAT construct implies repeated execution of the

DO-block until the control condition is met or an EXIT statement is

encountered. Execution of an EXIT statement terminates execution of the

innermost containing DO-REPEAT construct.

Initially, three loop control options would be provided, for indexed

looping - DO (i=e1, e2 [,e3]), for unindexed looping - DO (e TIMES), and

for indefinite repetition - the control clause is omitted and execution

continues until terminated by an EXIT statement.


In March, it was resolved that core Fortran should include a limited

dynamic storage allocation facility. That facility would not allow a

programmer explicitly to specify storage allocation at run time. DSA was

needed even for relatively simple array and string operations. Matrix division

seemed to require an amount of temporary storage that could not necessarily be

predicted at compile time. It was proposed that no feature should be discarded

solely because of a DSA requirement.

It was expected that DSA implementation would be transparent to the user,

the only change perhaps being relaxation of the restrictions on character



The May meeting accepted a proposal for a new data type, BIT, which would

be similar to data type CHARACTER but manipulating strings of bits instead of

strings of characters. Bit strings would, however, be aligned to the right.

A type statement BIT would correspond to the CHARACTER statement and have

similar syntax. Bit substrings would be provided. operations on bit operands

would be //, .NOT., .AND., .XOR., .OR., and comparisons (.LT. etc). There

would be a bit assignment statement. Bit constants could be denoted as strings

of binary octal or hexadecimal digits (B'111010', O'72', Z'3A').

Various transfer functions are proposed, between logical and bit types,

and between bit and integer types (with specification of the required sign

convention). Intrinsic functions would provide for logical and circular shifts

and for counting the number of one bits in a string. There would be variants

of the LEN and INDEX functions.


The May meeting resolved to allow names of up to 31 characters, all

characters of a name contributing to its uniqueness. This brings Fortran into

line with PL1 and ADA; Cobol allows 30 characters, as do Codasyl schemata.

The underscore character will be allowed in names, but not as the first.


If both upper and lower case alphabets are available, the two cases are

to be equivalent except in character constants and in H and apostrophe edit



This statement may be used to cancel implicit typing, so that all names

except those of intrinsic functions must be typed explicitly. No other

IMPLICIT statement may appear in the same program unit.