FSG minutes for 16 October 1986

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

David Vallance.

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

8X Standard.

(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

about it.

(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

errors.

(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.

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

favour.

John has produced a detailed report of the X3J3 meeting which appears in

Appendix A.

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

accommodation provided.

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.

MIKE NUNN

Secretary, BCS Fortran

Specialist Group

20 November 1986

APPENDIX A

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: [1] Halifax WG5 resolutions (as amended), August l986

l. Summary

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 [1], 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.

4. IDENTIFY

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

special way

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.

11. Real(*,*)

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).

12. Input-output

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

formatted i-o.

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.

APPENDIX B

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.

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:-

configuration diagram

The Cybers run under NOS/BE but ECMWF are experimenting with NOS/VE and may move to

this soon.

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

Alamos.

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

notation.

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.

APPENDIX C

Fortran 8x, the new Fortran Standard

John Reid, Harwell Laboratory

1. Introduction

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

summation.

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

assignment?

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

TYPE NONZERO

REAL VALUE

INTEGER ROW, COLUMN

END TYPE

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

A(10)=NONZERO(6.0,10,7)

Derived data types may have integer parameters. For example,

TYPE MATRIX(M,N)

REAL R(M,N)

END TYPE

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.

5. Modules

Modules are collections of data, type definitions, and procedure definitions. For example

MODULE JKR

TYPE MATRIX(M,N)

REAL R(M,N)

END TYPE

TYPE(MATRIX(10,10))::A,B,C

CONTAINS

FUNCTION ADD(A,B) OPERATOR(+)

TYPE(MATRIX(*,*)) A,B,ADD

ADD=A%R + B%R

END FUNCTION

END MODULE

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

USE JKR

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?

Reply. No.

6. Procedures

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

REAL(10,99)

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

PI=3.141592654L0

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

precisions.

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

minor enhancements.

(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

...

END SELECT

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

END DO

IF(...) CYCLE ! Skip to end of loop

END DO

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

numbers.

(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

compromise.

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

(7) PAUSE

(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

(4) COMMON

(5) EQUIVALENCE

(6) ENTRY

(7) Old source form

(8) Specific names for intrinsics

(9) Statement function

(10) Computed GO TO

(11) DIMENSION

(12) DOUBLE PRECISION

(13) CHARACTER*len