British Computer Society - Fortran Specialist Group

 Minutes of a Meeting held at the BCS, London, on Monday, 5th November, 1979

Present:   G. L. Harding (Chairman)        ECMWF

P. A. Clarke                    Rothamsted Experimental Station

D. J. Holmes                    Rolls Royce Ltd., Bristol

J. D. Murchland                 Leeds University

M. Nunn                         CCA

T. L. van Raalte                Ministry of Defence

J. M. Roberts-Jones             Liverpool City Council

G. A. Ruscoe                    Geisco Ltd.

A. J. H. Walter                 Rutherford Laboratory

A. Wilson                       ICL

J. D. Wilson (Secretary)        Leicester University

1.  Minutes of Previous Meeting (on the Table) [3 September 1979]

        Under the item "Group Objectives" the penultimate sentence should read

"Clarke felt that the time was ripe for a further investigation to establish

the views of users on an ANSI produced specification of contents for the

next Fortran."  Subject to this amendment, and a few minor typographical

corrections, the minutes of the previous meeting were approved.

2.  Administrative Matters

        Mr. J. Roberts-Jones has resigned as secretary due to pressure of

work.  The group expressed its appreciation to Mr. Roberts-Jones for his

hard work on behalf of the group over the past 18 months. Mr. J. Wilson

agreed to take over as secretary and Mr. A. Walter agreed to act as

treasurer until formal elections can be held at the next AGM (April 1980).

     Secretary's address:  J. D. Wilson,

Computer Laboratory,

University of Leicester,

Leicester LE1 7RH.

3.  Report from X3J3

        Mr. A. Clarke reported on the latest meeting of X3J3, held in Boston

USA in October, at which he and Mr. A. Walter were present as observers. The

following timetable is being attempted:

1979        Oct.        Initial Interface proposal by Subgroup

1980        Jan.        Technical Article on Interface Solution

            Mar.        Technical Article on Core

            May         Language itself in place

            July        Final proposals for Core

            Oct.        Begin document preparation

1981        Jan.        Final proposals for modules (including Data Base)

            Mar.        Proposals with text

            May         Final form of Core - plus - modules

            July        Last meeting for proposals

            Oct.        Edit and cross-check document

1982        Jan.        Document in final form

        The following Committee Votes were taken:

YES        NO

  (i) Include Data Structures with FORM Block,field and STRUCTURE

 definitions. Permit adjustable arrays, implied length

 characters but not "assumed size" arrays (i.e. those

 dimensioned (*))                                                  25         3

 (ii) Bit operators .BOR. .BAND. .BNOT. .BXOR.                          17        13

(iii) Adopt free form source with ! for end-of-line comment and

 multiple statements per line separated by ;

 (lines starting with ! are also comment lines)                    25         5

 (iv) Adopt & for continuation at end of first line and beginning

 of next line.                                                     27         1

  (v) Subgroup 10 must vet all core features                            27         2

 (vi) Permit automatic arrays, but they must not be initialised

 and must not be in COMMON.                                        l6         2

(vii) Approve significant blanks.                                        vote postponed

        A number of other proposals were debated but did not reach the stage

of a committee vote. "Straw votes" were taken in some cases but these have

been shown to vary widely from subsequent comMittee votes. Some of the

proposals discussed were the following.

Portability A number of alternative proposals to define the level of

        precision or the number of decimal digits of accuracy required.

CASE statement - previously agreed; syntax is now being debated.

Data Base extensions Provision should be made for compile-time checking of

        Data Base statements in the language.

Language Architecture The inter-relation of CORE, applications modules, and

        features modules was discussed. The "modified Castle" model was most


modified castle model

CHARACTER extensions Proposals to allow variable length strings, assign

        character variables to others, a new length function to give current

        length of character string, additional character functions.

Intrinsic Functions A proposal to allow a restricted class of functions

        in PARAMETER statements.

        The general feeling of the Fortran Specialist Group was that X3J3

was going "too far too fast" and that simplicity was important within the

existing framework of FORTRAN. Mr. A. Clarke said that X3J3 tended to

accept or reject proposals on the grounds of feasibility rather than

desirability. This will probably result in Fortran 87 (?) throwing out

much of Fortran 82 just as Fortran 82 is attempting to do to Fortran 77.

        A draft paper "Fortran Standards and the Revision Cycle" has been

prepared by Jeanne Adams. It contains, essentially, the current thinking

of X3J3 on the outline Fortran 82 will take. A copy of this draft paper

is attached to these minutes: any comments or questions would be welcomed

and should be sent to Mr. A. Clarke, Computer Dept. Rothamsted Experimental

Station, Harpenden, Herts.

4. Report from the ADA Workshop

        Mr. A. Walter gave a brief report on the ADA Workshop held in Boston,

USA in October.

        The workshop was seen as a test and evaluation exercise. No-one has

yet written a program in ADA, merely re-coded existing programs in another

language, and no compiler yet exists. The language has some nice features

as a sequential processing language; however, many people are unhappy about

its "exception handling". Concern was also expressed about scheduling

mechanism, or lack of it. "Data hiding" was considered important. The

concept of EXPORT and IMPORT is very strong in ADA.

        The first compiler is expected about mid 1981.

5. Real Time Fortran - Report from PURDUE Workshop

        Mr. A. Walter reported on the PURDUE Workshop held in October. The

PURDUE Workshop was set up to co-ordinate work on real-time or industrial

programs. Technical committee 1 deals with Fortran (2 with Basic, 3 with

ADA etc.)

        A standard currently exists for "Fortran 66" and can be extended to

Fortran 77. It consists mainly of a large number of subroutine calls. An

"Applications Facilities" module for Fortran 82 is currently being worked


        Five states are defined: Suspended, Running, Pending, Dormant, Non-

existent. A task can be in only 1 state at any given time; transitions are

instantaneous. The range of permissible transitions is shown by the

following diagram.

permissible transition diagram

Event marks and Resource marks are defined. Inter-task communications are

not defined. Bit handling (bits are integers), AND, OR etc. are defined as

are OPEN, CLOSE etc.

        It is hoped to produce a Standard by the end of this year.

6. An Array Tutorial (A. Wilson)

        It was stated that certain computation-intensive applications

(sorting, statistics, signal processing, seismic work, telephony, radio

astronomy etc.) made constant use of algorithms (e.g. Batcher sort,

convolution multiply, Fast Fourier Transform) which are difficult to

express in terms of conventional Fortran's array facilities. These

algorithms were presented and shown to possess a common factor: the need

to examine and act upon relationships existing amongst elements of a

single vector. It was shown that such relationships could be conveniently

computed by making use of vector shift functions. Accordingly a proposal

covering vector shift functions will be presented to X3J3 at the 71st

meeting in January 1980.

7. BCS Business

        It appears that some funds are available from the BCS to send someone

to X3J3 meetings on a regular basis. It is not yet clear how much money

would be available nor how the fund would be managed. The person involved

need not be the same on every occasion but must be selected from a small

number of nominees whose names would be submitted to X3J3. Continuity of

attendance at the meetings is important and is a requirement of ANSI.

The person would be required to report back regularly to the Fortran

Specialist Group. The Chairman agreed to pursue this matter with the
Technical Vice-President of the BCS in time for arrangements to be made for
the January meeting of X3J3.

8. Next Meeting

        It has been agreed that, as an experiment, occasional meetings will

be held outside London. The first such meeting will take place at

Heriot-Watt University, in Edinburgh on Monday, 4th February, 1980.

[The venue was later changed to Edinburgh University but with the principal

speaker from Heriot-Watt.]


Jeanne Adams

  The Impact of Today's Technology

DRAFT - October 9, 1979

        The community of users who apply computer technology to their problem

solutions are constantly beleaguered by changes in the technology. Each

decade seems to have a different special problem. brought about by the interaction

between the characteristics of the application and the "state-of-the-art"

technology. Some of the current trends that may affect computing

are the large data collection systems that appear to be on the increase, the

decentralization of computing and distributed processing, and the decreasing cost

of hardware relative to software costs.

        The presence of multiple processors in a distributed system and the

prevalence of multiple computers in local systems environments suggest that

users need a total system concept as the tool used for an application. The

tool should not be a scattered collection of computers each used

individually in solving problems. In addition to the complexity of these

systems, there is also what has often been referred to as the "software crisis"

brought about by the high costs and uneven quality of software tools generally

available. Among the many requirements for quality software are portability, along

with clarity, maintainability and ease of use. Programming language standards are

very important for at least two reasons in today's computing climate. One is

that it is important to write programs that will transfer easily among the

complex of computers in a distributed system. The other is that standards are

necessary (but not sufficient) for the development of quality software.

        As a result of these trends in the characteristics of computer use, there

has been a renewed interest in the development of language standards among

government agencies, vendors, and users of complex systems. A number of

languages are candidates for standards or are being processed in a revision

cycle. Among these is FORTRAN, the first programming language standardized in

the United States1. The history of FORTRAN began as early as 1954 when

research began into development of a language closer to the problem statement

used by the programmer. Early implementations appeared in 1956. Since that

time, FORTRAN has been standardized (in 1966) and revised (1978)2.  The use of

FORTRAN continues to to be popular; large investments in the industry ensure

that the language is very much alive.

The Need for Limited Language Development

        There is always resistance to change in programming languages; however,

programming languages must be responsive to the user community and the kinds

of applications that account for continuing popularity. It is important that

language standards keep pace with the industry and with user needs. The

technical committee (X3J3) under the American National Standards Institute has

begun a second revision cycle to develop a FORTRAN standard that will be com-

patible with the large investment in software and user programs written in

standard FORTRAN. At the same time, work was begun to provide new features

that reflect the state-of-the-art applications appearing in complex multi-

processing and networking environments.

        During 1978, the technical committee studied language features from many

perspectives in order to examine the design of FORTRAN as a whole. These

studies were done to place the needs expressed by users for FORTRAN features

in a broad enough context so that candidate features for the language could be

chosen within a carefully considered framework. In certain areas, development

is necessary because of the need for a function that is not yet provided in

the marketplace. A standardization effort in these areas will allow programs

to achieve portability in a timely fashion. A core-plus-modules architecture

is under consideration to facilitate these goals as well as to facilitate the

interface of special applications such as data base management to FORTRAN.

Main Committee Tasks

        Activities of the committee consist of work in three areas.

1.      The maintenance of the current standard, X3.9-1978 (FORTRAN 77)3

2.      The development of a revision to the.current standard

3.      Task Group activities concerned with special applications (for example,

        data base)

As compilers develop that support the current standard FORTRAN that was

released in 1978, questions arise about interpretations of the standards docu-

ment. These questions are studied and a clarification or interpretation is

prepared. In about a year, a technical report will be released containing the

committee's resolution of these issues. The report may then be used along

with X3.9-1978 in preparing standard conforming programs and developing com-

pilers that process standard conforming programs. This activity is an impor-

tant responsibility of the committee.

        The revision to the standard and the special applications are closely

interrelated and need to be carried out concurrently. The organization of the

committee (X3J3) into subgroups and a Task Group (X3J3.1) reflect this need.

Sub-group Studies

        The technical work is divided among six subgroups and a Task Group for

detailed examination of the issues. Recommendations on the following general

topics are then processed in full committee.

1.        Language Architecture and Form of the Standard

2.        Interfaces with Special Applications and Extensions

3.        General Considerations for,.Input/Output and Input/Output from Terminals

4.        Storage, Data Structures, and Requirements for Specifying Numerical Pre-


5.        Structures for Controlling Program Flow

6.        The Needs for Array Processing Features

7.        Data Base Manipulation

Language Architecture

        The careful study of various possibilities for a language architecture

was an outgrowth of the philosophy to consider the language as a whole and to

make it possible to extend the language in future standards easily. For some

time, X3J3 has been considering a "core-plus-modules" approach to the

language. This has naturally engendered numerous and often lengthy discus-

sions of the nature of the core and its associated modules. What are modules

and how are they related to the core? Many other issues of philosophical and

technical importance to the architecture have been reviewed. A final proposal

for the architecture will be processed in full committee early in1980. The

draft proposal, which was reviewed at an international experts meeting last

fall under ISO/TC97/SC5, includes suggestions from this group. A diagram of

the architecture is shown in Figure 1.

architecture diagram

Figure 1. Diagram of Architecture

Note to reader. Definitions of the Features Extended Module and Applica-

tions modules will be clarified at the next meeting of X3J3 and will appear

here. The diagram will be the one that is voted at the October meeting and

further explanations will be written based on the decisions of the committee.

There are other topics relating to the architecture.

1.     Core Criteria. In order to facilitate the correct placement of the vari-

ous proposed facilities in the core language or in the several modules

which might extend the language, it is necessary to develop a set of cri-

teria for the decision process. The set of criteria being evaluated as a

list for judging the placement of a feature in the core or a module

include the following:

1. Features required by applications modules

2. Completeness and consistency characteristics

3. Elegance and simplicity of form

4. Portability and compatibility with current software

5. Compilation and execution efficiency

6. Conciseness with a minimum of complexity

7. Minimum duplication of functionality

8. Broad acceptability by vendors and the user community

9. Characteristics that are basically FORTRAN

2.    Management of Application Modules. When an architecture is introduced

that includes the possibility of many kinds of applications modules

interfacing the language, then recommendations for evaluating the scope

of the language and managing the standards process becomes an important

part of a successful effort. Such things as how the applications modules

are reviewed by the committee in order to become standard and how a new

applications module project is defined are among the management problems

that need to be clarified. The members of the committee are not neces-

sarily technically expert in data base, industrial processes, graphics

and potentially many others. Decisions about the technical content in

these areas must be coordinated with the experts in these areas. The

liaison activities and the formation of task groups when requested are

important considerations that this subgroup is addressing.

3.    Experimental features and Obsolete features. It should be possible to

retire features that no longer serve the user community well and intro-

duce new features that may or may not survive in the language. Features

that are candidates for retirement will appear in the obsolete features e

module for reference by those users who have depended on a particular

facility that is considered no longer current. With an obsolete module

and an extension module, there would be a way for a feature to enter the

language gracefully and leave the language at the end of its useful life

and yet place a minimum impact on the large software investment in exist-

ing programs. Extensions that prove not to be useful to the user commun-

ity may never appear in the core language and may be dropped. These

features normally would not appear in an obsolete module.

Interfaces to Modules

        The subgroup chartered with the investigation of interfacing modules in

the language believed initially that modules defined within the X3J3 committee

would not present problems. This group has concentrated on modules defined

outside the FORTRAN group.

        Until now, extensions to the capabilities of the FORTRAN .language typi-

cally have been achieved with external procedures. This feature allows the

user to extend the program's capability and ease of use without the necessity

of extending the language. In other words, special applications would appear

as collections of subroutines and functions. Believing such procedural exten-

sions to be very appropriate, yet realizing that the current procedure invoca-

tion facility is limited in its expressiveness, the group spent considerable

time investigating enhancements in this area. Over the past year a prelim-

inary proposal for enhancing the procedure facility was prepared.

        As work on the procedure invocation facility progressed, it became

clearer that the set of enhancements that the group felt comfortable proposing

might fall short of meeting the needs of more "sophisticated" or "demanding"

modules, for example, the data base facility referred to above. Because of

this and the charge to the committee to standardize in this area, the group

began to investigate the possibility of permitting a module to define addi-

tional syntactic elements as well as making use of those that already existed

in the base language. These considerations may have a very serious impact on

the language. However, this approach is relatively independent of the

enhancement of the procedure invocation facility which will be an important

part of the extensions that will appear in the next revision.

Program Form

        The demands of users submitting programs from terminals in FORTRAN has

resulted in a proposal for a modification of the form of a statement more

suitable for terminal access. Many programmers accustomed to submitting FOR-

TRAN programs without terminals have also requested that a relaxed program

form be considered. The result has been a proposal that would standardize an

appropriate program form that is easier for all to use. The traditional form

dictated by submitting card decks will be an alternative for users of unit

0- record equipment.

Array Processing

        The array processing proposal has already passed in the full committee

processing. However, it is not yet determined whether or not these features

or a subset will appear in the "core" language. The current FORTRAN 77 opera-

tors (arithmetic, relational, logical, character, and replacement) were

extended to accept arrays as operands just as they now accept scalars. This

allows manipulation of arrays as fundamental objects and facilitates "formula

translation" for array and matrix oriented problems. FORTRAN 77 operations

are extended on an element-by-element basis for corresponding elements of

arrays. These operations are defined keeping in mind the principle of "least

surprise" to users. The current intrinsic functions have been extended to

accept arrays as arguments and a number of new intrinsic functions were added.

Matrix multiply and matrix divide also appear on the list. User written func-

tions also have been extended and a method of conditional operations on ele-

ments of an array complete the list approved. These extensions provide a

fundamental set of facilities for manipulating vectors, arrays and matrices.

Further work is anticipated with respect to array sections, slices and subar-


Structures for Controlling Program Flow

        In addition to the features that encourage structured programming tech-

niques in FORTRAN, such as the study of generalized looping constructs, this

group is concerned with event handling and compiler directives.

Data structures and numerical precision

        The list of topics in this area is long and varied. In addition to data

structures and numerical precision, the studies include bit data type,

environmental inquiry, character data extensions, and extensions to the data


The Data Base Task Group

        There are two committees that are working closely together.  One group

consists of the experts in the area of data bases in general and the CODASYL

data base in particular4. This Group has been formed as a Task Group (X3J3.1)

under X3J3 and is working on a recommendation for a CODASYL FORTRAN. While

this has been an important activity for X3J3.1, other data base conventions

are under study as well including relational data base concepts. The other

group is the data base group on the main X3J3 committee that introduces con-

cepts needed by the Task Group in the body of core FORTRAN or one of the other


Proposals Passed

        Proposal processing began early in 1979. A number of features have

already been passed by the main committee.

        Language Architecture. The model in Figure 1 was adopted by the commit-

tee at the October 1979? meeting. It is hoped that the architecture will

allow the development of the FORTRAN language to proceed dynamically well into

the future. The plans for features to be introduced cautiously and with

attention to the current usage and the plans for potential obsolescence of

archaic features should provide FORTRAN with a constructive method for intro-

ducing growth and change.

        Control Structures and Program Flow. Three proposals have been passed:

internal procedures, looping extensions and the CASE statement.

1.    Internal procedures were introduced to provide a block of code with con-

trolled access within a program structure. The syntax has been under

discussion and has not been finalized by the committee.

2.    In extending loop constructs, the subgroup carefully considered a con-

struct that could not only coexist with the present form of the DO, but

also could be extensible in future standards. The new construct is

bracketed with the keywords, ID and REPEAT. A loop EXIT statement is

also introduced.

3.    Another block construct is found in the CASE statement that was passed by '

the committee. The case construct follows the sane generalized pattern

and semantics as the block-IF in the current standard and the block-DO

introduced above.

        New Data Types. One new data type has been passed for inclusion in the

core or a module.

1.    The bit data type feature passed by the committee is modeled after the

character data type. The proposal includes a new type statement, bit

substrings, and bit operations used in the bit assignment statement. A

number of bit intrinsic functions were added as well as other extensions

that would fit the bit data type into the rest of the language.

Array Processing.

1.    The array processing features that were passed are described in the sec-

tion on subgroup topics outlined above.

Statement, syntax and form conventions.

1.    The FORTRAN character set was extended to include nine more characters:

exclamation point, double quote, percentage, ampersand, semicolon, less

than, greater than, question mark and underline. No specific use of a

given symbol is included in the proposal passed. These characters are

all of the "non-national" ASCII set not already included in the current

FORTRAN standard.

2.     A symbolic name may consist of one to 31 alpha-numeric characters, the

a first of which must be a letter. The break character is included in

order for users to write multiple mnemonics that are understandable and

distinguishable from similar combinations of letters. Several other

current languages have 3O to 31 character names.

3.    Lower case letters may appear in FORTRAN source statements if the charac-

ters are capable of representation by the processor. In interpreting the

source code, no distinctions are made between upper and lower case

letters, except in character data.

4.    The form of a character constant may appear with a double quote instead

of the apostrophe.


1.    A number of language facilities under serious consideration for inclusion

in FORTRAN may require some modest dynamic storage allocation in order

that the feature may be added effectively. In arrays, bit string, and

character string operations, this feature is quite useful. For these

reasons, the committee passed a proposal permitting a limited dynamic

storage facility in FORTRAN; however, the nature of the limitation

explicitly prevents the programmer from specifying storage allocation at

run time.

2.    IMPLICIT NONE is an optional form that removes default integer and real

typing within a program unit. when IMPLICIT NONE appears in a program

unit, no implicit statements of any other form may appear. The program-

mer must then use explicit typing for all variables.

3.    A minor restriction in the character data statement in the current stan-

dard has been removed. Implied DO variables may appear in substring

expressions in DATA statements.

Proposals under consideration

        Some of the proposals that are under consideration but not passed by the

committee include a specification for numerical precision, a suitable source

program form, the significance of blanks, and others. Work is proceeding in

the area of event handling, macro facilities, compiler directives and global

data. These features and the proposals passed by the committee may or may not

be included in the next standard. As with all other standardization efforts

that must achieve consensus from the user community, the votes taken may be

reintroduced and subsequently changed. Strong sentiment within the user com-

munity in favor of a feature or against a feature may alter the actions

already taken or the actions planned by the committee. In order for a stan-

dard to be accepted, new ideas must be publicized and reviewed before the

final draft is released so that feedback can occur and provide the committee

with information about the work. Both support and rejection of the features

under consideration are needed so that a standard is not controlled only by

those persons who oppose the work.

Feedback from User Community

        The processing of proposals will continue in the next year. The commit-

tee would like to. hear from the user community. There have been a number of

surveys and questionnaires that have been circulated both nationally and inter-

nationally, and the responses have provided the committee with excellent

material in determining user needs. The public comments after the last draft

standard also have provided the committee with valuable input. Occasionally

letters and papers are sent to us. In each case, the committee attempts to be

responsive to the suggestion or the inquiry. Observers are welcome at meet-


        The members of X3J3 are planning to write a number of articles about the

nature of the features that are being planned, along with a discussion of the

underlying reasons for the additions under consideration. Among these arti-

clues will be one that explains the core-plus-modules system architecture and

one that provides greater detail about application modules, and the extension

and obsolete features modules. The minutes of the meetings contain details of

the technical work. Requests should be directed to the X3J3 secretary. The

minutes of the meetings contain details of the technical work. Requests

should be directed to the X3J3 secretary. Feedback from the user community

will be important to the committee work. [Duplicate sentences as in the original]

        There has always been the debate whether standards should follow the

implementations that exist or whether to engage in development in areas where

the implementations are extremely diverse, or where there is no implementation

and the need is quite apparent from public comments and concerns. Probably, a

combination of both of these procedures needs to be used in producing a stan-

dard that will serve the community of FORTRAN users best. Keeping the

language simple and very much "FORTRAN" must be goals that govern the stan-

dardization work. When there is a conflict with these goals and the needs of

the characteristics of the language itself and its traditions must come



        This article was reviewed by the X3J3 committee. They provided many

suggestions to the presentation of the technical work. The subgroup heads are:

Winfried Burke               Language Architecture

Dean Herington               Interfaces to Modules

James Matheny                Input/Output and Program Form

Werner Schenk                Storage, Precision, Data Structures

John Lauer                   Controlling Program Flow

Richard Ragan                Array Processing

Bob Upshaw                   Data Bases

Bob Drake                    Data Base Task Group

        Walt Brainerd is the steering committee member who is

responsible for coordinating the technical work of

the subgroups. Other members of the steering committee


Martin Greenfield             Vice-chair

Betty Holberton               International Representative

Lloyd Campbell                Editor

Loren Meissner                Secretary


1. X3.9-1966 is the first standard. See Reference.

2. The acronym is FORTRAN 77 since the committee work was completed at that

time. The final release date is 1978. See Brainerd W. F. FORTRAN 77

3. The standard may be purchased from the American National Standards

Institute, the publisher.

4. See reference to the CODASYL Journal of Development.

[In the original typescript the footnotes were at the bottom

of the appropriate page.]


1.    American National Standard Programming Language FORTRAN. ANSI X3.9-1966.

American National Standards Institute, New York, New York, 1966

2.    American National Standard Programming Language FORTRAN. ANSI X3.9-1978.

American National Standards Institute, New York, New York, 1978.

3.    Brainerd, Walt, editor. "FORTRAN 77". Communications of the ACM, Vol. 21

No. 10, (October 1978), pp. 806-820.

4.    CODASYL FORTRAN Data Base Facility Journal of Development. Version 1.0,

Ottawa, Ontario, Canada, January 1977.