MINUTES OF BCS FORTRAN SPECIALIST GROUP MEETING HELD AT EUROPEAN CENTRE FOR MEDIUM
RANGE WEATHER FORECASTS, SHINFIELD PARK, READING ON 16 OCTOBER 1986
Present: Paul Allatt - Imperial College
Peter Anderton - QMC Computer Centre
Ric Collins - UMRCC
Francis E Cox - Swifte Computer Systems
Steve Davis - BP
John Dyke - HRC
Miles Ellis - Oxford University
Ian Garritty - Cray Research (UK) Ltd
Anne Gooding - Air Products Ltd
Rob Grant - SRTS Ltd
D T Griffiths - SSF
Roman Grzonka - Control Data Ltd
Peter Holland - SS(E)L
David Holmes - Rolls Royce plc
R Alan Jenyon - CAD Centre Ltd
Clive Massey - SWURCC
Mike Nunn - CCTA
T L van Raalte - MOD
John Reid - Harwell
Neil Smith - FS(B)3 Division, RAE, Bedford
John Steel - DAPSU QMC
J Stratford - QMC CC
Alison Wearing - NCC
Paul White - UK Met Office
Mark Wilce - Ryan-McFarland Corp
Alan Wilson - ICL
John Wilson - Leicester University
John Young - MOD (PE)
1. APOLOGIES FOR ABSENCE
Apologies were received from Karen Ma, David Muxworthy, Lawrie Schonfelder and
2. MINUTES OF PREVIOUS MEETING [25 July 1986]
The minutes of the previous meeting were accepted without correction.
3. MATTERS ARISING
(i) John Wilson said that his phone number was now 0533-522235.
(ii) The Secretary had not yet been able to draft a membership application
form for the Group but hoped to soon.
(iii) The Treasurer reported that BCS's new policy for funding Specialist
Groups allocated either £5 per member or £500 - whichever was the
greater. He also pointed out that the cost of BCS HQ Services was
going up. The Group at present has a surplus which is generally felt
should be used to help set up next year's "Fortran Forum" on the new
(iv) The next Fortran meeting had been provisionally arranged for Coventry
but the vice-chairman now said it was very doubtful whether this could
happen because of accommodation difficulties. In the circumstances it
was decided to re-arrange it for BCS HQ in January and try to arrange a
meeting in the Midlands for next June.
(v) It was mentioned that David Burns would probably be prepared to give a
talk on software tools at the January meeting.
(vi) The Chairman thought that next year's Fortran Forum might be arranged
about mid-August to coincide with the ISO WG5 working group meeting in
Liverpool. At our next meeting a sub-committee would be set up to make
arrangements for the Forum. It was hoped to have a more attractive venue
than last time - anyone with ideas where it could take place please let
the Secretary know.
4. BCS BUSINESS
(i) The Chairman said that BCS had set up a new Committee "Software
Engineering Technical Committee" which he attended whose purpose was
to advise BCS in matters arising related to software engineering.
(ii) The BCS Specialist Groups Board has been superseded by a Specialist
Groups Management Committee. The main item on its agenda recently was
the administrative side of BCS including the handling of mailing lists.
(iii) Two new journals were being published viz "Software Engineering Journal"
and "Information and Software Technology".
(iv) The Secretary had been approached by the newly formed "Parallel
Processing Group" to see if we were interested in having a joint meeting
to discuss current implementations of the 8X array extensions. He had
responded that the Fortran Group was anxious to see Fortran implemented
to comply with ISO Standards but, since the definition of array extensions
(plus the rest of 8X) was still being hammered out within X3J3, to look
at 8X implementation at this stage could not help the standardisation
process which we supported. However, we accepted that the supercomputing
community would find it difficult to wait to 1989, say, for the 8X array
extensions to be published in their final form.
5. X3J3 PROGRESS
(i) The Chairman had attended the August ISO WG5 working group meeting in
Halifax, Nova Scotia where a lot of unhappiness had been expressed on
the compromise plan instigated as a result of the negative ballot result
in X3J3 on whether the 8X standard was ready to go out for public
comment. WG5 felt that it had not really been consulted on late efforts
to cut things out of the draft but it was now too late to do anything
(ii) The UK was trying to get the Standard to say something about how errors
were handled and that any standard conforming processor should detect
(iii) John Reid summarised the latest discussion in X3J3:-
(a) The most significant resolution from WG5 was that the 8X draft should
be released as soon as possible for public comment. WG5 was also
concerned at features removed as part of a compromise adopted following
efforts by IBM and DEC to reduce the size of 8X. However, WG5 now
felt it was more important to get the present draft document released
rather than going back to the previous one.
(b) A vote on the size of 8X at WG5 went 18-5 in favour of the proposition
that the language was not too large.
(c) There was a considerable amount of editorial work still needed before
the draft was in a fit state for public review. There will be a
letter ballot soon of X3J3 members to decide whether it can be
released (a preliminary straw poll was 27-7 in favour). All those
voting against have to give specific technical objections. As
unanimity is doubtful it will likely be released if 2/3 of X3J3 are in
John has produced a detailed report of the X3J3 meeting which appears in
6. ANY OTHER BUSINESS
(i) It was mentioned that BCS members can join the Fortran Group mailing list
for free but there is an annual charge of £5 to non-members to cover
overheads. Anyone wishing to join should notify the Secretary.
(ii) The Chairman said that FORCHECK (an F77 verifier/checker) was now
available for PCs.
(iii) The Chairman thanked Dr Andrew Lea of ECMWF on behalf of the Group for
helping to arrange the meeting at Shinfield Park and for the splendid
7. DATE OF NEXT MEETING
The next meeting of the Fortran Specialist Group will take place on
Thursday 8 January 1987 at BCS HQ from 10.30 am to 4.OO pm. In the afternoon
starting at 2.00 pm there will be talks by David Hewitt (Coventry Polytechnic) on
"The implementation of Toolpack" and by David Burns (NCC) on "Software Tools".
As an experiment it is proposed to offer a buffet lunch at this meeting. will
everyone wishing to participate in this please complete the enclosed booking form
and return it to the Secretary by 28 December.
8. OVERVIEW OF ECMWF - ITS ROLE, COMPUTING ACTIVITIES AND EXPERIENCES WITH FORTRAN
At the afternoon session Dr Andrew Lea (Head of User Support) and Rex Gibson
(Head of Meteorological Applications Section) gave talks on the role of the European
Medium Range Weather Centre, its computing activities and experiences with Fortran.
A summary appears in Appendix B.
9. FORTRAN 8X
Also at the afternoon session John Reid (Harwell), a member of the X3J3 Committee,
gave a presentation on the new 8X draft Standard. A summary appears in Appendix C.
Secretary, BCS Fortran
20 November 1986
To: BCS, NAG, Fortran Forum, etc.
From: John Reid
Date: 31 August 1986
Subject: Report on the X3J3 meeting at Halifax, Nova Scotia
Note: This is a personal report of the meeting and in no
sense does it constitute an official record of it.
Reference:  Halifax WG5 resolutions (as amended), August l986
The meeting was dominated by the themes of correcting errors in
the draft document (S8) and improving its readability, making the
technical changes that were agreed at the previous meeting as part of
the compromise that reduces the size of the language, and reacting to
the ISO meeting held in the previous week. It now looks likely that a
fresh letter ballot will be held on the version of S8 that includes
all the changes made at this and the next meeting in November and that
the February meeting will be devoted to processing the ballots. A
straw roll-call ballot on how those members present at Halifax
expected to vote in this ballot was 24-6, so it looks as if the
compromise will obtain the two-thirds majority needed.
2. Meeting of ISO WG5 of TC97/SC22
The ISO Fortran Working Group met in the week preceding the
X3J3 meeting. I did not attend, so this report is second hand. They
passed a large number of resolutions , the most important of which
(passed 7-0-0 by countries and 31-1-0 by individuals) was 'that WG5
believes it is vitally important that all aspects of Fortran 8x be
submitted for public review as soon as possible'. Further, WG5 urges
that the public review period begin prior to the August 1987 WG5
meeting'. In view of the resolution at the previous WGS meeting in
favour of the size of the language at that time, the group was clearly
not very happy with the compromise adopted at the June meeting of X3J3
and with the lack of consultation. However, they accepted the need to
agree to it for the sake of getting the draft standard out for public
review reasonably soon.
WG5 requested a strengthening of the conformance rules (see
section 9), the reinstatement of operator overloading (see section 3),
returning to having a single category of deprecated/obsolescent
features, reinstatement of significant blanks, addition of an
intrinsic that generates random numbers (see section 5), a change to
some of the character functions (see section 6), reinstatement of
structure constructors (see section 3), addition of operator renaming,
and retention of name-directed i-o (see section l2).
3. Derived data types
Lawrie Schonfelder made a strong plea to restore overloaded
operators, moved to the appendix as part of the compromise. This
placed me in a quandary because I want them and yet I also want to
keep faith with the compromise. Lawrie's motion failed initially, but
it became apparent on the last day that this was regarded as a small
reduction by all but one of those who wished to see a reduction in the
size of the language, while Lawrie and two other members felt
sufficiently strongly on the issue for it to affect their vote on the
whole standard . A revote was requested by Brian Smith and myself, and
the motion passed (23-2).
A separate vote (25-1) restored structure constructors, which
again were felt not to be sufficiently difficult to implement to
justify the irregularity caused by their exclusion.
Together, these proposals restore derived data to its former
functionality, which includes constants, overloaded operators,
overloaded assignment, and user-defined operator names.
Part of the compromise was the unification of IDENTIFY with
RANGE. The hope was that a minor extension of RANGE might provide the
ability to construct skew sections. George Paul looked into this and
other possible combinations of statements, all of which he (and the
committee) found unattractive because of the differing aims and
scoping rules. To keep faith with the compromise, George therefore
proposed restoring IDENTIFY with the following restrictions:
(a) only one host
(b) no many-one mappings
(c) a requirement for the mapping to be expressed in a
This was accepted (22-3).
5. Intrinsics for generating random numbers
Following a request by WG5, Alan Wilson prepared alternative
proposals for intrinsics to return random numbers. Opinion among X3J3
members was divided. There were some detailed objections to the
intrinsics proposed and objections on the grounds of lack of
portability since different numbers will almost certainly be generated
on different processors. Eventually X3J3 adopted (15-12) a subroutine
RANDOM with a single real argument of any rank and shape that is
filled with pseudo-random numbers in the range 0≤x<1. Another
subroutine allows the seed value, represented as a rank-one integer
array, to be determined or reset.
6. Extra option in the character intrinsics
WG5 requested that the character intrinsic functions ISCAN,
INDEX, and VERIFY should have an option to allow them to process
strings backwards. This was agreed in principle (11-5-3) and Tracy
Hoover will be bringing a proposal to the next meeting.
7. Transfer function
As part of the compromise, Mike Metcalf proposed the addition of
an intrinsic function that returns a result whose physical
representation is that of its first argument and whose type is that of
its second argument. This would allow, for example, a data management
package to be written for one type and yet be available to store and
retrieve data of another type without conversion.
8. DATA statement
Ivor Philips proposed that the DATA and INITIALIZE statements
be combined into an enhanced DATA statement. With amendments to allow
DATA statements anywhere among the specification statements and to
deprecate placing them among the executable statements, the proposal
was accepted (18-3).
9. Processor conformance
WG5 requested a strengthening of what is said on processor
conformance. Essentially, they wished the processor to have the
capability to detect syntax errors and the use of deprecated or
obsolescent features, and that documentation be provided to specify
the extensions it allows and the processor-dependent parameters and
default values that it uses. Exact wording was not approved, but the
idea was accepted in principle (31-0-5).
10. Effective precision
A very minor problem with the definition of effective precision
was corrected. A processor whose real arithmetic uses the k digits
that are a power of 10, say 10**i, represents exactly all the numbers
that a decimal machine with i(k-l)+l decimal digits represents, while
the general formula credits it with effective precision i(k-l). The
change is to increase the effective precision by one in such cases.
At the previous meeting, it was decided to limit the number of
dummy arguments with passed-on precision to one, so that the number of
versions of a procedure would at most equal the number of native
precisions. The same effect can be achieved with a much more
convenient syntax by allowing any number of such arguments but
requiring them to have the same declared precision and the same
declared exponent range. It also has the merit of allowing all these
arguments to be optional, in which case at least one must be present
on each call. I moved this change and it was accepted (22-3).
Although the ISO WG5 meeting favoured the retention of name-
directed input-output, X3J3 decided (21-6) to replace it with NAMELIST
in accord with the compromise.
It was decided nem-con not to work further on Q-format (count of
number of characters remaining on an input record) keyed-access input-
output, and stream input-output. All of these were requested by the
previous WG5 meeting but not reaffirmed.
It was decided to treat a structure in an unformatted i-o list
as a whole, with a processor-dependent internal representation.
Previously it was specified that it should be treated by expanding its
components into an ordered list, which is really only needed for
Dick Hendrickson pointed out a problem connected with data
transfer operations actually affecting which array element is the
IOSTAT, VALUES, or NULLS specifier as in the example
READ(..., IOSTAT=II(I), VALUES=JJ(I)) I,I,I.
It was decided to disallow such a case.
13. Branching to an END DO statement
Murray Freeman pointed out that branching to an END DO statement
had the effect of an EXIT from the loop whereas a branch to a CONTINUE
at the end of a DO loop has the effect of causing a loop CYCLE. The
committee decided (23-0) that branching to an END DO should be
interpreted as a CYCLE.
14. Editorial work
Following the negative remarks by the guest speakers at the June
meeting, there was great concern about the readability of the draft
standard. Alan Wilson and I have be charged to work on illustrative
examples for all the bnf syntax. The committee decided to add another
level of subsection titles to the contents list, to add an overview of
the additions to Fortran 77 in Section l, to add an informal
description of the document organization to the preface and to add a
cross-reference index of the bnf terms to an appendix. Jeanne Adams
promised to work on expanding the index once the document is more
stable. I have been working on changes to the glossary to bring it
into line with the compromise and almost all my proposed changes were
accepted. It was, however, a disappointment to me that by an
oversight the old glossary (S11) was not bound into the latest draft
standard. It is my belief that consistent use of terms throughout the
document is very important and I am disturbed that few committee
members are as concerned as I am. For instance, the terms that we
agreed for the glossary were not used in a rewrite of the start of
Section 4 that was put in front of us on the last day.
Extra explanatory notes were added for several sections.
A large number of minor editorial corrections were made to the
document, with suggested changes being considered both by the
editorial subgroup and by other subgroups.
15. Next meeting of X3J3
The next meeting of X3J3 will be in Albuquerque, November 10-14.
The premeeting distribution deadline is October 6.
EUROPEAN CENTRE FOR MEDIUM RANGE WEATHER FORECASTS - ITS ROLE, COMPUTING ACTIVITIES
AND FORTRAN EXPERIENCES
Talks were given by Dr Andrew Lea (Head of User Support) and Rex Gibson (Head of
Meteorological Applications Section).
1. Role of ECMWF
(i) ECMWF is a consortium run by 17 European nations with the purpose of
preparing medium range weather forecasts for the member states. As such
it is not part of the UK, does not pay taxes and has 17 Governments
determining its role. Its status is similar to organisations such as
NATO and the European Space Agency.
(ii) Located at Shinfield Park, Reading, ECMWF prepares forecasts for the
member states and does not deal with the general public. "Medium range"
equates to 4-10 days forecasting ahead. Revised forecasts are produced
every 24 hours and despatched to the member states.
(iii) Objectives are to:-
(a) Collect and store observational data (data goes back to 1979 when
ECMWF was set up).
(b) Prepare medium range forecasts.
(c) Disseminate forecasts over 9.6K lines and via GTS (global
telecommunications system) to member states.
(d) Carry out related scientific/technical research.
ECMWF has a team of 55 people developing new models. They also assist
in the world meteorological office programme and offer training in weather
forecasting to member states.
(iv) ECMWF exists because the arrival of supercomputers made it possible to
make 10 days-ahead weather forecasting.
2. ECMWF Computer Configuration
ECMWF's forecast model runs on a CRAY X-MP with SSD (Solid State Device) front-ended
by three CDC Cybers.
The configuration is as follows:-
The Cybers run under NOS/BE but ECMWF are experimenting with NOS/VE and may move to
3. The Forecast Model
The 10-day forecast model runs on the CRAY and CYBERs simultaneously using most of
the memory available and taking over 2.5 hours to run. Coded in Fortran, it averages
275 MFlOPS and peaks at 800 MFlOPS. After weather data is received at ECMWF it has
to be decoded and subjected to quality control checks before being applied to update
a database. The forecast model is run 4 times a day using the most recently received
data but also taking into account data received 6 hours earlier. To provide the
10-day medium range forecast the model is run for a much longer time to a greater
depth of the algorithms. Some of the software used on the CRAY was written at Los
4. Use of Fortran
A lot of people come to work at ECMWF for brief periods so programs developed must
be easy to understand and modify. For this reason high order languages are
important. As the ECMWF model takes a long time to run it is essential to have
fast executing code. Fortran was the obvious choice for program writing because it
was the only language offering the vectorisation facilities they needed. ECMWF use
it for most applications even though it is considered to have some shortcomings.
ECMWF had a strong desire to make use of multi-tasking facilities and was one of the
earliest Cray sites to have a working set of this type of software. It is needed to
fully exploit the parallel facilities of a multi-cpu supercomputer environment.
Using the Cray multi-tasking library is like calling a set of subroutines.
On the CRAY they use Fortran 77 plus some Cray extensions. The "POINTER" construct
introduced is found useful to make use of memory to best effect:-
eg. POINTER (IP, ARRAY (999))
---- Here an array of dimension 999 is defined dynamically and uses a
memory address given by variable IP.
5. Software Development
On non-supercomputer applications ECMWF uses 50% Fortran 66 and 50% Fortran 77.
Migration from F66 to F77 has caused them problems. On the CDC systems there are
separate compilers for F66 and F77 with a means of translation but sometimes this
caused code to become too large to run and so requiring some re-writing of subsystems
Q1 the Cray a single compiler handles both F66 and F77.
ECMWF has defined its own set of software standards. Policy is to use F77 for "Core"
codes (with some exceptions) and allow a specific set of additional features for
supercomputer applications. Where machine or system dependent features are used
they insist on them being coded separately from the "core" code.
Package portability is an important requirement. Over the last seven years ECMWF
has had three supercomputers and find that hardware lasts less time than software.
6. What ECMWF would Like to See in Fortran in the Future
Rex Gibson considers that Fortran falls far short of translating mathematical
notation into code - in fact it is less successful than other languages in this
respect. Multi-tasking requires reference to segmented data using a single common
Fortran codes need to be more readable - unreadable codes are unmaintainable. Also
users do not want to have to re-write applications each time the Standard is revised
so downward compatibility is needed.
7. Audience Questions:-
1. Does ECMWF use the automatic vectorising capability on the CRAY?
Ans: Yes - automatic vectorisation is important.
2. If ECMWF started again what language would they use?
Ans: If they had a free choice they would look around for another language
but Fortran is the only one well supported.
3. How do parts of the ECMWF suite break down over the configuration?
Ans: (i) Analysis/forecast + part of the pre-processing
runs on the CRAY.
(ii) Data acquisition + remaining pre-processing + post-processing
runs on the CYBERs.
(iii) Archive retrieval runs on the IBM.
NB: The post-processing is being re-written at present so that it can be
moved onto the CRAY.
Fortran 8x, the new Fortran Standard
John Reid, Harwell Laboratory
X3J3, the ANSI Fortran Committee, held a letter ballot of its members in February 1986
to ask whether they thought that the draft new Standard was ready for release to the public
for comment. The result was yes:16, no:20, and one did not vote. The rules require each no
vote to be accompanied by reasons and the Committee is required to address each such
reason with the aim of achieving consensus. A number of non-controversial points were
raised, but the main problems were with the overall size of the language and with the
mechanism for language evolution. A compromise that involves a reduction in the size of
the language and slower language evolution was agreed in June 1986 (see Appendix B). The
draft Standard is being revised to reflect these changes and it is intended that a fresh postal
vote of X3J3 members be held in February 1987 and that the draft will be released for public
comment later in the year.
This talk summarized the language under seven main headings and invited discussion.
This synopsis is organised similarly.
2. Language evolution
A program that conforms to Fortran 77 will conform to Fortran 8x. Thus a Fortran 8x
processor is a Fortran 77 processor with extensions. A small number of features that have
replacements in Fortran 77 are labelled 'obsolescent' and may become 'obsolete' in Fortran
9y, that is will not be present in Fortran 9y. A larger list of features are labelled 'deprecated'
and may become obsolescent in Fortran 9y and obsolete in Fortran 10z. The features
involved are listed in Appendix A.
Since there has historically been an 11-year revision cycle, this allows about 20 years for
programs to be modified to remove obsolete feature or to fall into disuse.
3. Array operations
Arrays may be 'automatic' (automatically allocated on entry to a procedure and
deallocated on return) or 'allocatable' (allocated and deallocated by explicit statements).
Dummy arrays may be 'assumed-shape' (take their shapes from the corresponding actual
arguments). Arrays may be of size zero.
Arrays may be used in whole-array expressions such as
B + C*SIN (D)
The operations are performed element-by-element, that is the sine function is applied to
each element of D, multiplied by the corresponding element of C, and added to the
corresponding element of B. The arrays must have exactly the same shape, but scalars may
be intermixed freely. Temporary array storage may be needed for intermediate results.
Array expressions may be used as actual arguments. They may be used in whole array
assignments provided there is exact shape agreement.
Rectangular subarrays, called sections, may be used as arrays. Examples are A(: , 7)
which is the 7-th column of A and A (2:10:2, 7) which consists of components 2, 4, 6, 8, 10
of the 7-th column of A.
Functions may be array-valued. Scalar functions may be called 'elementally' in the way
SIN was called in the above example. There are many new inquiry intrinsics that return the
array properties of their arguments and many new array-valued intrinsics, for example
MATMUL for matrix multiplication, MAXVAL for the largest element, and SUM for
The executable statement IDENTIFY provides access through an alias name to a section
that may be skew. For example,
IDENTIFY (DIAG(I)=A(I, I), I=1,N)
permits the diagonal of A to be accessed as a rank-one array called DIAG.
Arrays of rank one may be constructed as lists of scalars and other arrays of rank one,
possibly repeated. An example of any array constant of size 10 is
[1.0, 2.7, 4[1.0, 2.0] ]. In the integer case, triplets such as 1:10:2 may be included
and are interpreted as for DO indices. There is a RESHAPE intrinsic function to allow arrays
of other shapes to be constructed.
WHERE statements allow array assignment statements to be masked. For example
WHERE (A. GT. 0) B=LOG(A)
causes the evaluation and assignment of logarithms only for elements that are positive.
There is also a block form with an optional ELSEWHERE block.
Arrays may be 'ranged', in which case whole array statements refer to a subarray that is
set and reset by execution of SET RANGE statements.
Audience. Can a subscript I be an integer array?
Reply. No, this feature was moved to an appendix as part of the compromise.
Audience. Why have a special function MAXVAL rather than a generic MAX function?
Reply. Each existing Fortran 77 intrinsic becomes an elemental function that can be applied
to array arguments with the interpretation that each element of the result is what would
have been obtained if the scalar function had been applied to the corresponding elements.
Audience. How does IDENTIFY handle allocatable arrays?
Reply. The alias goes when the array is deallocated.
Audience. In an array assignment statement, is the array expression fully evaluated before
Reply. Yes, so temporary storage may be needed.
Audience. Why were assumed-size arrays introduced into Fortran 77 only to be deprecated
in Fortran 8x?
Reply. With hindsight, the Committee made a mistake, but such mistakes are inevitable as
our understanding of the issues progresses and the hardware changes. Note that the pace of
evolution is slow. The deprecated features still be present in Fortran 8x and 9y.
Audience. What percentage of the draft document relates to the array features?
Reply. It is not easy to estimate since the array features are integrated into the language and
are therefore described in many places, but it is certainly less than 10%.
4. Derived data types
Fortran 8x permits the construction of derived data types whose values have components
that are of intrinsic type or of another derived type. Functions may be used to define
operations on such types of data and subroutines may be used to define assignments
between them. The operators may be intrinsic (e. g. +, *, .EQ.), in which case the existing
priorities are used for the new operators, or nonintrinsic (e. g. .MERGE.), in which case the
priority is maximum for unary operators and minimum for binary operators.
An example of a type useful for sparse matrices is
INTEGER ROW, COLUMN
which allows a matrix nonzero and its row and column numbers to be treated together. A
sparse matrix with up to 100 nonzeros may be held in a array declared thus
TYPE (NONZERO) : : A(100)
The symbol % is used for components of data of derived type. For example,
A(10)%VALUE would be the value of the nonzero stored in A(10). A value may be
constructed as a list of component values. For example, we might set A(10) thus
Derived data types may have integer parameters. For example,
might be used for m by n matrices. Indeed, if matrix arithmetic is wanted, some such type
would be needed.
Derived data provides the language with a powerful form of extendibility. It means that
ordinary in-line operator notation will be available for matrices, extended precision
arithmetic, interval arithmetic, etc.
Modules are collections of data, type definitions, and procedure definitions. For example
FUNCTION ADD(A,B) OPERATOR(+)
ADD=A%R + B%R
is a module containing the definition of the type MATRIX, three matrices (A, B, and C), and
the definitions of matrix operations. Entities may be declared PRIVATE, in which case they
are available within the module, but not outside it.
A simple USE statement such as
provides accesses to all the public entities in the module. To allow for possible name
clashes, there is a renaming facility. Access may be limited to a list of entities.
Modules provide a safe replacement for COMMON. Note that the definitions are given only
once. It is more general than COMMON in that type and procedure definitions are included.
Audience. Can modules be nested?
A procedure may be called recursively provided its leading statement includes the
qualifier RECURSIVE. It may be internal, at one level only, to an external program unit or
to a procedure in a module. Keyword calls, as in the i/o statements of Fortran 77, are
available. The dummy argument names serve as keywords. Arguments may be omitted
provided they are declared as OPTIONAL. The intrinsic function PRESENT may be used to
inquire whether an optional argument is present. Dummy arguments may be declared to be
IN, OUT, or INOUT. Several procedures may have the same name (overloading) provided
they may be distinguished by the types or ranks of their arguments.
Interface blocks that contain statements just like the leading statements of a procedure
may be used to specify the interface to an external procedure. For example, this permits
keyword calls to be made to a procedure written in assembly language. If a procedure is
internal, is accessed from a module, or has an interface block, it is said to have an 'explicit'
interface. An explicit interface is required to call an array-valued function, to call a
procedure with assumed-shape dummy arguments, to call a procedure as an operator, or to
make a keyword call. In all these cases, the interface information is needed so that the
system can set up the linkage before run-time.
Audience. Will the increased complexity of procedure calls, mean less efficient execution?
Reply. The efficiency is implementation-dependent, but the Committee is always careful to
keep efficiency in mind. In this case the call can be resolved at compile-time, so there is no
need for a run-time penalty.
Audience. Why allow overloading of function names? Isn't this bad practice?
Reply. We are already doing this is Fortran 77 for SIN, COS, etc. and this is not regarded as
bad practice. It is intended for sets of procedures that are doing closely related jobs for
arguments with different types.
Audience. Can the system check that the input to a procedure is what it should be?
Reply. This is no different from Fortran 77. The Standard requires matching of argument
types, but whether the match is checked is implementation dependent. A debugging
compiler can do such checks. The Standard does not say what a system does to a program
that does not conform to the Standard. It just says that it must interpret correctly any
program that does conform.
7. Generalized precision
REAL and COMPLEX declarations may be parameterized to indicate the desired precision
and exponent range. For example
takes the shortest machine representation that gives the equivalent of at least 10 significant
decimals and a range of at least 10 *99 (single precision on Cray machines).
There are many inquiry and manipulation intrinsic functions that return information on
the representation or manipulate parts of data (e. g. extract the fractional part).
Constants may be specified with the help of a letter other than E, D, or H that is associated
with a particular precision and exponent range pair, as in the example
REAL (7, 50) PI
EXPONENT LETTER (7, 50) L
In a binary expression such as A+B, the precision of the result is the greater of the
precisions of A and B and the exponent range is the greater of the exponent ranges. For a
general expression, the precision and exponent range may be deduced from its expansion
into a sequence of binary operations and the rule for each binary operation.
In a procedure call, the declared precisions and exponent ranges of the dummy and actual
arguments must match. A dummy argument may be declared as REAL(*,*) or
COMPLEX(*,*) and such an argument automatically matches the corresponding actual
argument provided all such actual arguments in a given call have the same precision and
exponent range. In effect, one version of the source therefore serves for all possible
Audience. What happens within an expression with primaries of different precisions?
Reply. The rules are used to break the expression into a sequence of binary operations.
Each binary operation is performed in a representation that is wide enough to
accommodate both its operands.
Audience. How does a subroutine library handle different precisions?
Reply. A single version can be maintained that accepts 'passed-on' precision arguments. All
such arguments must have the same precision, so it is like the present practice of having real
and double precision versions except that it is more general and only one copy of the source
need be maintained. Which version is loaded can be resolved at link time.
8. Miscellaneous improvements
(a) Input-output. The only major new feature is NAMELIST, but there are a large number of
(b) Source form. Names may contain up to 31 characters, including _, which is regarded as
alphanumeric. The Fortran character set is extended to include
! " % & ; < > ? [ ] _
There is a free source form, incompatible with the Fortran 77 form, that attaches no
particular significance to columns 1 to 6 or 72 onwards, allows end-of-line comments
(using ! as a separator), allows several statements on a line (using ; as a separator),
and uses a terminating & to indicate continuation to the next line. Lines may have
length up to 132 characters and statements up to 1320.
(c) Operator spelling. The operators .LT., .GT., .LE., .GE., .EQ., and .NE. have the
alternative spellings <, >, <=, >=, ==, and <>.
(d) Control structures. There is a CASE construct, exemplified by the following
SELECT CASE (N)
CASE (:0) ! N <= 0
CASE (1) ! N=1
CASE (5:7) ! N=5,6 or 7
DEFAULT ! Any other value
There is a form of the DO loop that does not use labels, exemplified by the following
OUTER: DO ! Unlimited DO, named OUTER
DO (N TIMES) ! N executions
DO I=1,N ! N=1,2,...,N
IF (...)EXIT OUTER ! Possibly exit outer loop
IF(...) CYCLE ! Skip to end of loop
END DO OUTER
(e) Intrinsic subroutines. There are intrinsic subroutines to provide the date and time as up
to 9 integers, to provide information on the real-time clock, and to provide random
(f) Intrinsic functions. There are a large number of new intrinsic functions and all the
Fortran 77 intrinsics are elemental, that is they may be called for array arguments and
are then applied to every element.
Audience. In the source form, are labels still restricted to integers?
Reply. Yes, though constructs can be named, as in the DO block with name OUTER in the
second example of this section.
Audience. With a maximum line length of 132, will there not be a tendency for
implementations to allow only 9 continuation lines?
Reply. Yes, to remain in conformance with the Standard, you would need to restrict
yourself to 9 continuation lines with the new source form and a line length of 132. If you find
this unacceptable, please write to the Committee during the public comment period.
Audience. Are blanks significant?
Reply. As in Fortran 77, they are insignificant except within a character context. They used
to be significant in the new source form, but this was changed as part of the recent
9. General discussion
Audience. What is the expected time-table?
Reply. See section 1. It is hard to see how the Standard could be accepted by 1988, which is
the date many of us have been hoping for.
Audience. Are there any features for multiprocessing?
Reply. No. It is felt by most people that it is too early to standardize. We do not yet know
best how to do it.
Audience. Why have features been moved into an appendix?
Reply. The language had become too big for more than a third of the Committee members
to accept. We had to do something to reduce it. During the public review period, the
appendix will expose features that we have considered but have removed.
Audience. What is the position of IBM and DEC?
Reply. The IBM representative has been consistently negative to the work of the
Committee, and will almost certainly vote 'no' to the release of the present draft for public
review. He does not want any feature of Fortran 77 to be removed ever. The DEC
representative has been far more positive, for example playing a very active role in altering
the language evolution mechanism (see section 2) to something that is acceptable to almost
all the Committee members. However, he is still uncertain about the implementation of
modules, and is therefore quite likely to vote 'no' too.
Appendix A. Obsolescent and deprecated features
The following features are obsolescent:-
(1) Arithmetic IF
(2) Noninteger DO index
(3) DO termination other than on a CONTINUE or END DO statement
(4) Branching to END IF from outside its block
(5) Shared DO termination
(6) Alternate return
(8) ASSIGN and assigned GO TO
The following features are deprecated:-
(1) Assumed-size dummy arrays
(2) Passing an array element to an array
(3) BLOCK DATA
(7) Old source form
(8) Specific names for intrinsics
(9) Statement function
(10) Computed GO TO
(12) DOUBLE PRECISION