MINUTES of the Annual General Meeting held on Monday 2nd April 1979

at British Computer Society, 13 Mansfield Street, London W1.


E A Booth                British National Oil Corporation

P A Clarke               Rothamsted Experimental Station

G L Harding              E C M W F

D J Holmes               Rolls Royce Ltd., Bristol

P Kraven                 British National Oil Corporation

B Meek                   Queen Elizabeth College, London

J D Murchland            Leeds University

D E Oldfield             International Computers Ltd.

D K Phillips             International Computers Ltd.

T L van Raalte           Ministry of Defence (PE)

J M Roberts-Jones        Liverpool City Council

D M Scales               Seismoqraph Service (Eng) Ltd.

A W Stewart              Geisco Ltd.

A Wilson                 International Computers Ltd.

J D Wilson               Leicester University


D Hill, D T Muxworthy.

(Mr P A Clarke in the Chair)


The minutes of the meeting held on 5th February 1979 were approved.


Disposal of Surplus. MOTION (Meek) that all BCS Branches be

approached with an offer to provide speakers on Fortran standardisation,

this Group to defray speakers' expenses. Passed unanimously.

Disposal of Surplus. It was suggested that a bulk purchase he

made of copies of the new standard. it was noted with regret that

orders placed with BSI were subject to delay and that the price charged

appeared excessive. The Secretary reported that he had previously

attempted to negotiate with BSI, who had offered a discount so small

that the savings would he more than offset by the costs of postage to

members. Unfortunately, there was an agreement between BSI and ANSI

giving the former a monopoly of supply in the United Kingdom, and it

was reported that orders placed directly with ANSI were being refused.

It was felt that it was now too late to consider local reprinting.

RESOLVED that Mr D T Muxworthy, as Convener of the relevant BSI Working

Group, be asked to register the Group's concern as to the arrangements

for distribution of the new standard.


Mr P A Clarke indicated that he was resigning as Chairman. It was

reported that Mr D Hill and Mr M Lewis were resigning from the



The following nominations were made:

Chairman:       Mr G L Harding (proposed J D Wilson, van Raalte)

Vice-chairman:  Mr D T Muxworthy (Meek, Harding)

Secretary:      Mr J M Roberts-Jones (van Raalte, Meek)

Committee:      Mr P A Clarke (Meek, van Raalte)

Dr J D Murchland (Clarke, Meek)

Dr A Wilson (Clarke, Meek)

Mr J D Wilson (van Raalte, Harding)

All nominations were accepted unanimously and the above-named

Officers were declared elected.

(Mr G L Harding in the Chair)


Meek made a statement in support of the X3J3 core-plus-modules

proposals. He noted that he was in a small minority amongst the U.K.

delegates to the ISO meeting in having no reservations about the

proposals. He supported the concept (but not necessarily the actual


There were conflicting requirements needing to be resolved in

the design of any language. In the case of a language such as Fortran,

there were considerable historical influences such as the reduced

character set. Users had very strong desires for maintenance of strict

upwards compatibility; but they also wanted a variety of new facilities.

Such new features should address particular application areas, such as

a database interface (which was now required by X3 to be considered by

X3J3), and extensions for real-time and graphics. In addition, there

were more general requirements for the language to be developed to

exploit advances in machine architectures and to recognise trends in

the usage of programming languages: there were needs for array handling

capabilities, for freer source forms allowing for terminal input, and

for useful structured programming constructs beyond the block IF, such

as better looping, and case, statements. There was also a desire to

rid the language of a number of "archaic" features.

On the other hand, it must be recognised that continued addition

of features to the standard can cause compilers to grow, and grow.

As he understood the proposals, the intention of X3J3 was that

'Fortran, with all these extra goodies added to it, ... would be

stripped down to a core consisting of those data and control structures

that were strictly essential for "old-fashioned" programs; the core

would be a truly minimal subset.' A number of Fortran 77 features

would be omitted from the core, which would be A subset (as distinct

from the subset) containing those features it was desirable to retain.

The core language would be a viable language. It would not be downwards

Compatible. In any particular implementation, one or more nodules would

be available in addition to the core. It was an essential feature that

a user could specify; invocation of particular modules. Some modules

might be implemented as subroutine libraries (e.g. graphics), whilst

others might add new statements or new variants of existing statements

(e.g. database).

In order to provide upwards compatibility for existing programs,

a module would always be provided, containing those Fortran 77 features

deleted from the core. He felt that the terms "Fortran 77 module" and

"archaic features module" were misnomers: he would call it a

"compatibility module".

Harding suggested that for some micros there would be little point

in preserving Fortran 77 compatibility.

Murchland expressed doubts as to whether a full implementation

containing all modules was feasible.

(At this point, Mr B Meek left the meeting.)

Murchland said that he was opposed to the X3J3 proposals. He had

reservations as to the stated intention to get a modern language whilst

maintaining existing programs. X3J3 ought to recognise their inability

to cover the full range of Fortran usage. He regretted moves to

discriminate against "unloved" features.

Harding stressed that there was an urgent need for a new standard

interface; he welcomed the impetus given by the core-plus-modules-e

proposals to development of an enhanced procedural interface.

Clarke made a statement opposing the core-plus-modules proposals;

this is attached as an appendix.

Harding felt that the fact that the proposals envisioned

maintenance of Fortran by several different committees was no more than

a recognition of the existing position; future development would be

assisted by a formal interface definition.

There was a short discussion as to potential alternative

approaches. Harding suggested that Fortran was one of the very few

languages that did get updated; it was not realistic to compare the

necessary design process with that of languages which were immediately

frozen. Clarke wished to avoid the possibility that the proposed

approach would make it easier for "silly" features to be added to the

language. Harding said that the test was whether implementors and

users adopted new features. Kraven felt that, no matter what the

standards said, users will continue to write whatever they want to.

van Raalte pointed out that a module that proved to be popular could

nevertheless include individual features that might be undesirable.


Alan Wilson gave a very interesting talk. He first described

the current state of discussions within X3J3 on the provision of array

processing features. He then described the ICL Distributed Array

Processor and gave examples of the algorithms being developed to

exploit it.


Monday 4th June 1979, 10.30 a.m., British Computer Society,

13 Mansfield Street, W1. The main speaker, at 2 p.m., will be

Mr W D Manville of GEC Computers Ltd., on "Fortran Systems for

the GEC 4000 Series".



    Some thoughts on the core-plus-modules

approach to standardising Fortran

The case for a core-plus-modules approach has been formally proposed by

Walt. Brainerd at the meeting of Fortran experts (Nov. 78) and at Fortran

Forum (London) (Dec. 78), a copy is attached to these minutes. (Appendix B)

These comments refer to technical and other problems associated with

core-plus-modules (that have been raised in subsequent discussions) in
an attempt to clarify the full range of implications of its adoption.

The comments on the proposals can also be classified by their impact on

(a) Existing Fortran programs (b) Existing implementations (compilers etc.)

(c) The Organisation necessary to support Fortran standards (d) The Fortran

User (e) The Fortran language and (f) General comments, observations and


Impact on Existing Fortran Programs

Many people have claimed that the use of Fortran 82 would be for new

programs only. This is because the Fortran Core language proposed is

incompatible with F77. Existing programs would have to be developed and

maintained by use of the Fortran 77 module. Within a program it is not

possible to have some routines in F77 and some in F82.

For an existing program to operate under Fortran 82 requires that it be

completely rewritten (without COMMON, EQUIVALENCE, computed GO TO etc.).

If this is the case, and it seems so - then why not change completely to

another language - one that is more powerful than F82 and get even larger

benefits from the effort of rewriting?

The tremendous changes proposed for Fortran 82 defeat the purpose of

"evolutionary standards" (if such things exist).

Impact on Existing Implementations (Compilers etc.)

It would appear that the compilers of a core-plus-modules language would

have to be structured themselves into modules to handle the core and each of

the modules necessary. How the compiler handles incompatible modules is not


Certainly because of the retention of old/redundant features, compilers

will also have to carry a large overhead.

There are no implementations of core-plus-modules Fortran and hence

no-one knowns how it will be implemented or even if it can be implemented

A runtime system to support core-plus-modules with incompatible modules

is not a practical proposition. Only compatible modules could be used at the

same time. There would be no way that the runtime system could check to see

if the modules (routines) used were semantically compatible - this would be an

additional source of uncheckable "user error".

Impact on the Organisation of Fortran Standards

Difficulties arise in co-ordinating changes to any of the standards and

in particular, changes to the core language. As we understand it, ANSI X333

will be responsible only for the 'core' language and the Fortran 77 module.

Will they also be responsible for determining which of the proposed modules are

to be standardised? Or is a new organisational structure necessary, possibly

along the following lines? The way authority is to be delegated to these
various committees should be made clear.




X3J3 - Fortran system Co-ordination



|                  |                  |               |

X3J3 - Core Fortran     ISA standards      CODASYL Database     etc

|             (real time)        Standards Group.



|                          |                                |

X3J3 - Fortran (77)      X3J3 - Subset Fortran          X3J3 - array processing

        module                                             (module)

There is a problem that no single group are now masters of the whole

application spectrum and there will be no one to speak authoritatively for the

whole of the standardisation activity.

Impact on the Fortran User

There certainly is a requirement to be able to support 'language

extensions' for major application areas and users would benefit from having a

standard way of tackling these problems.

The proposals that exist lack detail. Many of the 'reorganisations' that

appear to be implied by core plus modules (such as "deletions" on a grand

scale) are unacceptable to many users, and haven't been 'thought through'


The Fortran user may be able to write Fortran 77 programs that will

conform to F82 - but because of the extensive nature of the changes, these

programs would either be trivial or excessively badly written because of

exclusion of features due for deletion.

The User of a core-plus-modules compiling system must be aware of what

features he is using are in the core and what features are in modules, and

what modules are incompatible.

In fact, the problem may exist at a sub-module level. Only some of

the features in one module may conflict with some of the features in another

module (or the core module). For example, provided labels are not removed from

the language, the computed GOTO in the Fortran 77 module could be used in the

same program unit as CASE statements of the Fortran 82 core. But it is believed

that COMMON and EQUIVALENCE could not similarly co-exist with array processing

and fixed form source could not be mixed with free-form source.

Impact on the Fortran Language

The addition of various modules(super) - languages will in effect make

Fortran a larger language system. This means that any changes will have wider

ramifications and more time will be required to produce extensions that do not

conflict within the system - it will also become increasingly difficult to

devise such extensions. The overall effect will be to cause a slowing in the

rate at which the language develops. This is contrary to the rapidly developing

hardware environment currently prevailing, and I suspect, (from the list of

Brainerd's proposed changes), to Brainerd's intentions. To overcome the above

slowing down, Brainerd is proposing a "tremendous" change to the Fortran

language before core-plus-modules gets working properly. Note that if his

proposed changes occurred after the introduction of core-plus-modules, most of

the "modules" would already be 'frozen' around Fortran 77 and it would be far

more difficult to change them.

There is the implication that the new core language will be "sufficiently

trim that new language features can be added in a natural way" to justify the

tremendous changes he proposes. But he gives very little hard evidence that

the new language will be any better at adapting than the old one. (The case

for removing EQUIVALENCE is well made, but the case for most of the other

changes is omitted. In particular, the removal of COMMON would not be

acceptable to many current users, I suspect).

Difficulties arise:

(a)  When the language extension is not "at the same level" as Fortran.

It is a very high level language or is a very low level (perhaps

machine dependent) language.

(b)  When the language chosen is otherwise incompatible with Fortran.

i.e. It is non-procedural, requires special data structuring

conventions or conflicts with existing Fortran standards.

Nothing has been said in the proposal about what happens to subset


If this is retained (and presumably the reasons for its existence still

hold), there is a danger of falling into the 'COBOL' situation of having to

support an impossible number of modules and subsets of them.

I suspect that Brainerd intends Fortran Core 82 to be sufficiently

"small" to eliminate the need for a subset. However, there will still logically

be a requirement for a FORTRAN 77 SUBSET MODULE containing redundant features

of the Fortran 77 subset (in the same way as the FORTRAN 77 module would

contain redundant features of full Fortran 77).

We note that the proposal indicates a 'Fortran 77 module' to contain

"redundant" features of the core language (module). If core-plus-modules

were in effect, say module M existed for a special application. Then by 1982

much of M would also be redundant and it would be necessary to create a special

module for redundant features of M, call this M77 as well as the revised

version of M, call this M82.

Each revision cycle would create "double" the number of modules.

Core-plus-modules type changes can only 'evolve' through the mechanism of

'replacement by duplication' (e.g. having F77 as a "module".) - which only

serves to "clutter up" the language, not to "clear it up". (It is argued that

eventually it would 'clear up'. but when?).

General Comments, observations and opinions

Core-plus-modules is being put forward as a general "magical formula" to

all our problems - and tends to obscure some of the real issues - of good


Not enough time has been spent on considering other 'proven' alternatives -

such as the "nested layers" type approach, a "generalisation" type approach

or through the use of preprocessors. It should be noted that no other

language really gains (anything/much) from being structured as a 'core +


Core-plus-modules is being used 'to obscure the fact that X3J3 is acting

as a language design team rather than a standardisation one.

Because no implementation of core-plus-modules fortran exists, the whole

process is untested and may be unsound. It is one of the constraints on

standards groups to only adopt well tried methods.

It has been suggested that the X3J3 committee should look at the way that

other software evolves. Mention has been made of the "release" system

used by many organisations such as that used for NAG numerical algorithms.

New releases completely replace old ones and users are expected (and are

able) to revise their programs within a few months usually.

Also consideration should be given to the way that computer manufacturers

update their operating systems - something might be learnt here.

PAC 2 May 79




Walt Brainerd

    MS 260

  Los Alamos Scientific Laboratory

P. O. Box 1663

   Los Alamos, NM 87545


Submitted as a working paper for the 1978 November meeting

of the group of Fortran experts, ISO TC97/SC5

In 1978 January, ANSI X3J3 voted to adopt a framework

consisting of a "core" and "modules" for developing the next

revision of the ANSI Fortran standard. Of course, this is a

decision which could be reversed if the approach appears to be

unsuitable or technically unsound after some experimentation.

However, the approval of this procedure is an indication that the

committee wants to invest considerable effort in an attempt to

make this approach work.

There are at least three reasons for adopting the "core +

nodules" approach:

1)   to provide a mechanism to interface with collateral

standards and implementations in major applications areas

2)   to provide a mechanism for having optional functional

areas described within the standard

3)   to specify a smaller, more elegant, language than Fortran

77 without decreasing the status of Fortran 77 as a

standard language.

Each of these reasons is now discussed in more detail.

One of the major concerns of X3J3 is the development of

collateral standards in areas such as data base management, real

time process control, and graphics. X3J3 does not have the

resources to do the technical development of standards in all of

these areas; in some cases X3J3 may not even be involved directly

in the approval of such a standard. Therefore, it is important

that X3J3 provide a scheme whereby collateral standards in these

applications areas can be regarded as modules in the language that

are "attached" to the core of the language in a standard way. The

only mechanism considered so far for interfacing with these

modules is through the CALL statement, extended to allow the

arguments to be identified by key words. This topic is covered in

more detail in another paper and is an area that can use more good

ideas, because it is a very difficult and important problem.

A second kind of extension might be called a "language

feature module." This sort of module would include a collection of

related language features that might not be appropriate to include

in the core, but which should have its form specified so that all

extensions to the core in this area will be the same. Example

candidates for such modules are array processing, a bit data type,

and specification of numerical precision. Fortran 77 should be

considered to be such a module.

It may be quite inappropriate to add some of these language

features to Fortran 77. For example, it would be rather messy to

add a bit data type or REAL*11 (indicating at least 11 digits of

precision) on top of the Fortran 77 equivalencing mechanism.

For these reasons it is important to design a core that is

sufficiently trim that new language features can be added in a

natural way.

Since Fortran 77 will be one of the modules, the core need

not be constrained to contain all archaic features of Fortran.

One of the design objectives is to eliminate those features (e.g.,

the arithmetic IF statement) that are no longer necessary, due to

the addition of better equivalent features or those features

(e.g., storage association) that actually stand in the way of

adding features recognized as contributing to high quality

programming practices.

To provide just one example illustrating how the storage

association concept impedes the addition of useful features,

consider the possibility of a conditional array assignment.

REAL A(90), B(90), C(90), D(90)

A(*) = 0

B(*) = 0

WHERE  (A(*) .LT. 2) DO

C(*) = B(*) + 1


If no equivalencing is allowed, the assignment may be

implemented as

 DO 9 I = 1, 90

9     IF (A(I). LT. 2) C(I) = B(I) + 1

However, if the program may contain the statement

EQUIVALENCE (C(1), 8(2))

the loop above will set C(I) = I for I = 1 to 90 instead

of setting each element to 1. The implementation will be more

complex on most machines.

In 1978 August, X3J3 approved a proposal to create a first

cut at a core language by starting with Fortran 77 and making the

following changes. Of course, this list is not final, but is

given to provide a flavor of the final result. When reading the

list of changes, it is important to keep in mind that Fortran 77

will be one of the modules, so any compiler that contains the

Fortran 77 module will be able to process programs containing any

of the features of Fortran 77.

The following two paragraphs are excerpted from the X3J3

proposal to indicate some of the objectives of the approach:

The general philosophy governing this core design is that the

core should be comprehensive, containing virtually all of the

generally useful features of Fortran and that it should form a

practical, general-purpose programming language. Modules would be

used largely for special-purpose language features that entail

high implementation costs or are used primarily in special-purpose

application areas. The number of such modules should remain small

in order to minimize problems of program portability. Three

examples might be (1) a module providing comprehensive array

processing facilities, (2) one providing data base management

facilities, and (3) one providing features of Fortran 77, and

possibly certain other isolated special-purpose features, not

contained in the core.

Another goal is to produce a more elegant language by moving

redundant features and including features which lend themselves to

modern programming practices.

The net effect of these changes is the following

1) Subroutine linkage facilities are enhanced to improve the

interface with applications modules written in Fortran.

2) Archaic control structures are replaced with modern ones.

3) The concept of storage association is removed.

4) Fixed-form source is replaced with free-form source.

There are two kinds of changes: features added to Fortran 77

and features remaining in Fortran 77 but not included in the core.

To be added                           To be moved to Fortran 77 module

Free-form source                      Column 6 continuation

Larger character set                  C for comment

Longer names


Simple data structures                EQUIVALENCE

Some array processing                 COMMON and BLOCK DATA

Global data definition                Passing an array element or

                                      substring to a dummy array

Bit data type                         Association of ENTRY names

A length (digits) for REAL            DOUBLE PRECISION


Enhanced looping                      Arithmetic IF

Case construct                        Computed GO TO

Internal procedures                   Alternate RETURN

Subroutine linkage                    ASSIGN and assigned GO TO

Statement functions

ERR = and END = specifiers


H, X, and D edit descriptors

Specific names for intrinsics


Annual Report of BCS Fortran Specialist Group 1978/79

This year has seen the long awaited completion and publication of the

FORTRAN 77 language standard. It has seen too, the start of further revision

for a proposed standard to be completed by 1982. These standards are prepared

by the American National Standards Institute (ANSI) X3J3 committee that is

responsible also for the International (ISO) standard.

The work of our group has been to help collate British opinion on Fortran

proposals and forward these to ANSI X3J3 so that the standards they produce

are acceptable to interested parties in Britain. This has been done in close

liaison with the British Standards Institute. The two main events of this year

have been the meeting in London of a group of Fortran standards experts hosted

by the BSI and including many members of our Specialist Group, and a one-day

Forum on Fortran organised by the Specialist Group at which the Fortran experts

met British Fortran users. We were delighted that 110 people attended this, and

thank Mr. J. Roberts-Jones (Group Secretary) for its organisation, Mr. M. Peltu

(then Editor, Computer Weekly) for publicity and ANSI X3J3 for providing

thirteen speakers and panel members. We were also delighted that Frank Engel

Jr, the Chairman of ANSI X3J3 during the FORTRAN 77 revision period was awarded

Honorary Membership of the BCS for his contribution to Fortran standardisation.

During the year there have also been six committee meetings. Speakers

included Dr. Peter Barker (NUMAC) on "PL/l as a successor to Fortran", Irene

Mallgrave (CRAY computers) on "The Fortran Compiler for the CRAY-l", David

Muxworthy (Univ. Edinburgh) on "Activities of BSI DPS/l3 WG6 and the next

Fortran Standard", Alan Clarke (Rothamsted Experimental Station) on "Using the

Fortran Interface to CODASYL databases", and Dr. Alan Wilson (International

Computers Ltd.) on "Array processing algorithms and the DAP".

Officers elected for 1979/80 are Gary Harding (European Centre for Medium

Range Weather Forecasts) as Chairman and John Roberts-Jones (Liverpool City

Treasury) as Secretary. David Muxworthy (Edinburgh Regional Computing Centre)

was elected vice-chairman.

P. A. Clarke

25th April 1979



Mr P A Clarke,                           Harpenden (05827) 62271 X64

Computer Department,

Rothamsted Experimental station,

Harpenden, Herts.


Mr G L Harding, (Chairman)               Reading (0734) 85411 X319

European Centre for Medium-range

  Weather Forecasts,

Shinfield Park,

Reading, Berks.


Dr J D Murchland,                        01-657 6478

35, Rectory Park,

Sanderstead, Surrey.


Mr D T Muxworthy, (Vice-chairman)        031-667 1081 X2844

Program Library Unit,

Room 2609,

James Clerk Maxwell Building,

Mayfield Road,



Mr J M Roberts-Jones, (Secretary)        051-227 3911 X617

Date Processing Division,

City Treasury,



L69 2DQ

Dr A Wilson,                             Bracknell (0344) 24842 X2419

international Computers Ltd.,

Lovelace Road,

Bracknell, Berks.

RG12 4SN

Mr J D Wilson,                           Leicester (0533) 50000 X165

Computer Laboratory,

University of Leicester,