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.
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
favoured.
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
on.
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.
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.]
FORTRAN STANDARDS AND THE REVISION CYCLE
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-
cision
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.
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-
rays.
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
statement.
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
modules.
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.
Other.
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-
ings.
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
first.
Acknowledgements
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
are:
Martin Greenfield Vice-chair
Betty Holberton International Representative
Lloyd Campbell Editor
Loren Meissner Secretary
Notes
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.]
References
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.