BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GRONP

    Minutes of AGM held at BCS Headquarters on Monday 13 September 1982

Present:          P Allatt          :    ICCC

P A Clarke        :     ARC Computer Centre

M Dean            :     Ferranti Computer Systems, Wythenshawe

W F Flexner       :     (Retired) Statistical Office of United Nations

I D Hill          :     Medical Research Council

T Horran          :     GEC, Marconi Avionics

C G Lazou         :     ULCC

D T Muxworthy     :     University of Edinburgh

T L Van Raalte    :     MOD

D M Vallance      :     University of Salford

J D Wilson        :     Leicester University (Chairman)

1.      APOLOGIES FOR ABSENCE

None received.

2.      MINUTES OF PREVIOUS MEETING

There are some minor typographical errors in Appendix A.

Future Meetings : 29 November 1982  (Fortran on Cray 1)                          Action:

                   7 February 1983  (GKS)                                        DMV

                  11 April 1983     (AGM - BCS HQ)

The Chairman has arranged for Ken Brodlie, of Leicester University, to

speak on GKS, the Graphical Kernel System, at the meeting on

7 February 1983.

3.        MATTERS ARISING

A number of replies had been received to the Compiler Questionnaire. These

are summarised in Appendix A of these minutes. The Group expressed its

thanks to all those who have contributed.

The Chairman has not yet updated and improved the Fortran 77 booklist.

Members of the Group who have problems receiving minutes should contact

the Secretary.

The Group's annual report has been sent to BCS HQ by the Chairman.

The Secretary will write to ACM to ask if the FSG can act as a node for          Action:

the ForTech newsletter.                                                          DMV

4. TREASURER'S REPORT

Mr Rose, the Assistant Secretary (Technical) of the BCS, has written to

the Chairman pointing out that the BCS have not yet received a statement

of accounts for the year 1981-82 nor have they received a statement of

accounts for the Fortran Forum.

The Group has not itself received these financial statements. The

Chairman, Treasurer and Secretary will meet with Mr Rose to discuss

the matter.

The Secretary and Treasurer will write to non-BCS members to ask for             Action:

the £2 subscription to the Group for the period 1982-83.                         TLVR,DMV

The Treasurer will make payments to all the Group's creditors as soon

as he receives full details from those creditors.

5.    CHAIRMAN'S BUSINESS

1)    The BCS Jubilee Conference takes place on 14 October 1982.

2)    The BCS publishers, Haydn & Sons, have merged with John Wiley

      to produce a new imprint Wiley-Haydn.

Specialist Groups have been asked to give this publisher the

first option, at the planning stage, for the publication of

conference proceedings.

3)    The BCS has agreed that Specialist Groups should keep 60% of

any surplus income generated by organising events.

4)    The Chairman has sent a brief summary of the aims and activities

of the FSG to the BCS.

5)    The next meeting of the Specialist Group's Board is on Friday,

17 September. The main agenda item is a request for a Royal

Charter for the BCS.

The Chairman will attend this meeting. His expenses will be

met from FSG funds.

6)    The Chairman noted that the Dutch Fortran Group have a number

of subgroups that mirror X3J3 activities, for example 'Graphics',

'Databases' etc.

7)    The Chairman felt that there was general interest in providing a

benchmark for Fortran 77.

Chris Lazou noted that CCTA have a suite of Fortran programs in

order to test compiler performance.

Alan Clarke has got a set of tests for error messages for a

substantial part of Fortran 77.

The Secretary will write to members of the Group asking for                Action:

details of the cost and availability of any compiler validation,           DMV

verification or performance tests that they might have in

machine readable form.

6.    DATE AND PLACE OF NEXT MEETING

Monday, 29 November 1982, at BCS HQ, at 2.00 p.m., Chris Lazou, of ULCC,

will present a talk entitled "The Cray 1 as a Fortran Engine".

7.    AFTERNOON SESSION

Dr Alan Clarke, of the Agricultural Research Institute, gave a talk

entitled 'Using Standard Fortran - Past, Present and Future' whose

content is very ably summarised by Dr Clarke in Appendix B to these

minutes.

D M VALLANCE

11.11.82

  APPENDIX A

     SUMMARY OF REPLIES TO FORTRAN 77 COMPILER QUESTIONNAIRE

It is emphasised that the views expressed here are those of the

individuals who responded, and are not necessarily those of the BCSFSG.

Blanks in the table indicate that either conflicting information or no

information was sent to the Secretary.

Thanks to all who responded. I will attempt to update this table in

the light of any further comments that I receive.

D M VALLANCE

COMPUTING SERVICES

UNIVERSITY OF SALFORD

SALFORD M5 4WT

* (but there is a means of flagging non-66 standard constructs!)

† (Both YES and NO replies were received)

  APPENDIX B

 Using Standard Fortran - Past, Present and Future

by Alan Clarke

  Computer Department, Rothamsted Experimental Station, Harpenden, Herts

   Article reprinted with permission of Datalink Newspaper (UK)

Introduction

For those who use Basic, Cobol, Algol or any other Non-Fortran language, these

articles attempt to outline the essence of Fortran, the things that ordinary

Fortran users find most useful. Bells and whistles are ignored and preference

given to a few essential concepts. Some personal opinions and questions are

presented in the hope that readers will forward their views.

PART 1 - The Past, Fortran 66

Early Days - Efficiency Paramount

Fortran is now so old that we forget what a great advance it represented in

1954. John Backus, the originator, has recently revealed that one of his

greatest fears was that Fortran would fail because it could not perform as

well as machine code. In the event, the efficiency was acceptable and it

turned out that the productivity gain from the Fortran (Formula Translator)

way of expressing solutions to problems, which were mainly numerical in those

days, was so important that even after many decades, it is debatable whether

newer languages represent any further significant advance for these problems.

The fact that Fortran is still the main language for scientific and

engineering problems testifies to this.

Universal Nature

Since then, Fortran has been extended to increase its power and range of

application. It would be true to say that there is no computing problem that

can not be solved using Fortran, with some machine code routines if

necessary. The ability to interface to machine code (or "external") routines

is essential to Fortran.

Let us admit that Fortran has been far from ideal for problems involving

character or text manipulation, but a solution has always been possible and

recent changes are greatly improving this.

Closeness to the Machine - Storage Association

Many experienced Fortran programmers know the type of machine code instruc-

tions produced by their compiler for each Fortran statement. They also have a

good idea of the relative speeds of the Fortran statements. They know that a

"storage association" exists between data entities in the language and the

actual computer store locations occupied. And they know how to take advantage

by addressing data directly through machine code or by using alternative

addressing mechanisms in Fortran. Critical routines may be replaced by

machine code. These tricks of the trade improve efficiency considerably. In

effect, Fortran can be used as a "low level" language. This ability has been

lost in many newer "high level" languages.

Assembly Line Methods and the Subroutine Concept

The Fortran approach of breaking down a problem into parts, producing a sub-

routine for each part and finally assembling the parts into a whole product,

is just as valid today as it was when it was first conceived. It is the same

approach as that adopted by industry for manufacturing machinery, cars, etc.

The advantages are many. Standard parts (the nuts and bolts) do not have to

be re-invented, because they are widely available - in the form of subroutines

in a subroutine library. The individual parts may be produced by several

different companies and this enables a high degree of parallelism in the

production process. In a programming environment it allows a job to be

divided between members of a team, each of whom can specialise on a small part

of the overall product. It also allows for independent testing of the parts.

Tools can be devised for this which can further speed the process.

To make the parts fit together, their interface must be defined carefully to

ensure correct communication. Usually this consists of passing the inputs and

outputs of each process in a constrained manner. In Fortran we could write:

        CALL CALC(A,B,C,TOTAL,MEAN)

to calculate the total and mean of three numbers in A, B and C.

In Fortran, the independence of subroutines exists because entities have a

"scope" or existence which is limited to the one subroutine only. In some

other (block structured) languages there is a danger of using names in "inner"

procedures that have been defined (possibly by someone else) in an "outer"

procedure - with unexpected results.

The Fortran 66 Standard

Fortran became so widely used on many different computers that standardisation

was highly desirable to maintain portability.

The Committee that produced the 1966 standard had to define a subset of all

the features provided in the then-emerging language that manufacturers called

Fortran IV, to abstract the underlying concepts and to draft the standard

document in terms of these.

It was the first computer language to be standardised. The standard was a

success in that suppliers could meet the standard and users could ask for and

get a product which would run all their existing programs. One problem has

been that very few people know what is in the standard. Standards are rarely

taught as part of Fortran training courses.

Permissiveness

A second problem with the standard is the deliberate allowance of extensions

to the language. Any supplier can add any new feature he likes or his

customers ask for. The only restriction is that he cannot give interpre-

tations to existing statements in the language which are contrary to the

standard interpretations.

A consequence is that without exception all compilers implement an extended

language and for the novice user there is often no way of knowing what is

standard and what is not. In this light, it is not surprising that many

programs written in (some supplier's dialect of) Fortran are neither standard

conforming nor portable.

Members of the BCS Fortran Specialist Group have been pressing for a

"conformity" option for the user who wants to write standard conforming

portable programs. It would make the Fortran processor (compiler, etc.) warn

the user when he is using non-standard facilities, but this option is not part

of the standard yet.

Portability

It is widely recognised that Fortran 66 really is the most portable language

available today. There are many features that enhance this and they are often

based on a machine independent abstraction which can be mapped easily onto any

machine.

One case of this is the idea of input/output units. To the programmer, these

are just numbers. The programmer infers certain attributes to these by per-

forming input/output operations on them. In Fortran 66 the options are few:

formatted or unformatted (i.e. binary), input or output and printer control

characters (e.g. new page) or not. Only sequential access is available. As

almost all systems support files, the notions of "printer", "card reader",

"magnetic tape", "disc file", etc., are virtual, and it is quite safe, and

portable for a program to use three units for (notional) magnetic tapes, two

for (notional) printers and three for (notional) card readers.

The actual mapping of unit numbers to devices or files is not defined in

Fortran 66 and is considered to be one of the functions of the operating

system, to be done externally. This has been very successful.

Review

The features described so far are considered by many programmers to be

essential to Fortran. Many have even come to regard them as the correct or

best way to tackle the problems.

PART 2 - The Present, Fortran 77

Introduction

At a recent Fortran Forum, a show of hands indicated that while 20% of Fortran

users are still stuck with Fortran 66 (i.e. manufacturer's products called

Fortran IV), the majority have now progressed to the newer more powerful

Fortran 77 standard (for which manufacturers use various names - to be sure it

is Fortran 77, check the small print).

Fortran 77 - An Evolutionary Development

By 1968 many extensions beyond Fortran 66 had appeared in compilers. A

further revision of the standard was required. The Committee, chaired by

Frank Engel (who later received a BCS award for this work), were again

breaking new ground. No-one had ever revised a computing language standard

before. From the start, they voted that the new standard would be an

evolutionary development that would not invalidate programs written to the

original standard. This was most important because of the enormous investment

that had been made by the users over the preceding decade. The revision took

over seven years to complete and the cost of the effort was estimated to have

been in excess of two million dollars. User involvement and input was

encouraged. When the draft was published there was an enormous response for

more features. A new wave of "structured programming" enthusiasts were

demanding their say.

Fortran 77 Criteria

To maintain compatibility with Fortran 66 the following criteria were used

when considering proposals for changes:

1.      New features could be added to the language if they were well proven

        both in utility and usage. To add untried facilities would not be

        standardisation but research.

2.      New features should not conflict with Fortran 66. This avoided problems

        of compatibility.

3.      Features from Fortran 66 should not be deleted. This ensured that

        existing programs could be carried forwards.

4.      Features to be included would be those that significantly improved

        portability and yet kept the language simple.

5.      Features which were potentially obsolete should not be developed further.

The results of criteria like these were a "conservative" revision. The main

changes that resulted were the addition of character data type, additional

input/output in a list-directed manner, input/output from/to internal files

and file handling operations such as OPEN, CLOSE and INQUIRE statements.

Type CHARACTER

The long overdue addition of a character data type has been welcomed by all

users. Even numerical and statistical programs have to communicate with their

users, and this is usually done through a command language or menu system

which requires quite extensive character manipulation.

The CHARACTER data type provides character strings of a static length. It is

envisaged that the more general 'dynamic' string handling facilities will

follow in the next revision.

Fortran 77 defines character constants, variables, arrays, functions and

operators for copying, comparing and joining characters. A substring notation

allows users to extract selected characters from a string.

INDEX is a useful intrinsic function which indicates if one character string

contains another.

List Directed Input/Output

Fortran has the powerful but complicated formatted input/output. List

directed input/output recognises the need for a simple alternative comparable

to that provided in BASIC. The layout is not specified by the programmer, it

is left to the processor. It can&used by beginners for a quick look at values

with minimum effort. It is also more suited for on-line use.

        Example: PRINT *,NAME,AGE,SCORE

Internal Files

A character variable or array may act as an internal file. READ and WRITE

commands can transfer values to and from the character locations in

store. During the transfer, a FORMAT may be used to encode or decode the data

(i.e. convert from character form to binary or vice verse).

File Handling Commands

The commands OPEN, CLOSE and INQUIRE perform many of the functions that job

control languages have done in the past. These commands make it possible to

write on-line interactive programs that handle files in a friendly manner.

In some ways these commands turn a blind eye to the reality that there are no

standards for filenames or files and these vary considerably between computer

systems.

What Fortran 77 does to overcome this is to say that a filename is a character

string whose length and other attributes are user-defined.

OPEN is used to establish a connection between a unit number and a file. It

also declares attributes of the file.

        Example: OPEN(UNIT=1O,FILE='INSECTS',ACCESS='SEQUENTIAL')

Note the use of keywords (e.g. UNIT=) to simplify the writing and ordering of

options on these statements.

CLOSE terminates the connection between unit and file and declares what is to

be done with the file (e.g. KEEP or DELETE).

INQUIRE gives access to the attributes of the file. Does it exist? Is it

open?, etc. It is possible to inquire about files either by their name or

through the unit number to which they are connected.

IF-THEN-ELSE

There was an overwhelming cry for this feature. IF-THEN-ELSE should have been

accompanied by block CASE and block DO statements, but it would have taken too

long to standardise these because the whole issue only came to the fore after

the draft standard had been sent out for review.

One good thing about the 'structured programming' issue was that the existing

Fortran 66 control statements were regarded as obsolete and not extended or

improved. One exception was a token gesture of allowing an extra comma in the

DO statement. This was intended to prevent the notorious case when, if the

comma is omitted, the DO becomes an assignment - which is known to have sent

spacecraft adrift. The "zero trip DO" was also defined (see later).

User Experience with Fortran 77

Despite the passing of four years since the standard was released, experience

is still limited. The reasons are now clear. It takes suppliers several

years to produce good compilers and these are implemented on the supplier's

latest range of computers. Users who have older computer models have to wait _

until they upgrade. Even when Fortran 77 is available, extensions to existing

programs continue to be written in Fortran 66. In many cases, it is only when

new programs are started that the new standard is used.

Once use has started, it takes several years to get a full appreciation of the

new features. Only when new programs have to be transported to other

computers does the portability aspect becomes known. It is now realised that

ten years is a reasonable period for the standard revision cycle.

Compatibility with Fortran 66

Those who now use Fortran 77 have found it highly compatible with Fortran 66.

The minor incompatibilities (listed in an Appendix to the standard) represent

no serious problems. Suppliers can ease these problems further.

A particular case that has caused problems is the "zero trip DO loop".

Briefly, the new standard says that the body of a DO loop will not be executed

if the termination criteria of the loop are met when it is entered. The

action in this case was not defined in 1966, but some suppliers had

implemented a "one trip DO".

Portability of Fortran 77

As soon as substantial numbers of Fortran 77 compilers were available, a

portability study was undertaken by J. Larmouth at Salford University and

sponsored by the NBS (Ref. 1). The conclusion, that Fortran 77 programs will

become at least as portable as Fortran 66 programs are now, is encouraging.

Many practical steps that enhance portability of programs are listed in the

report.

Conclusions

Fortran 77 is a more powerful language than Fortran 66. It is highly

portable. It is compatible with Fortran 66 and is meeting new requirements

for on-line use. The first steps towards a more structured language have been

taken.

Ref 1) Portable Fortran 77 programming - J. Larmouth, 1980, available from

the U.S. National Bureau of Standards.

PART 3 - The Future, Fortran 8X

Introduction

No sooner had the Fortran 77 standard been published than work commenced on

the next round of revisions, dubbed Fortran 8X. The basis was an ever growing

pile of proposals, many of which were left-overs from the conservative Fortran

77 revision. Details described below outline current thinking which was

presented to the recent ISO meeting of Fortran experts in Vienna. Be warned

that these decisions may be rescinded before the 8X standard is released.

The New Architecture, Core and Modules

For the third time Fortran standards workers were faced with an unprecedented

situation. How was it possible to make radical changes to the language and

yet maintain compatibility? This time it would not be possible to avoid

conflict with existing features.

Discussions led to what Committee members hope will be an architecture for

incremental evolution, quaintly called core and modules. The core and modules

architecture consists of dividing the language features into four categories.

Firstly the "core module" is the nucleus which contains a compact, complete

and permanent language. Secondly, the "obsolete features module" contains all

those features in the previous standard which are not to be found in the

core. Thus together the core and the obsolete features module form a language

which is compatible with, and an extension of, the former standard.

It is intended that features in the core should completely replace features

relegated to the obsolete features module and that at subsequent revisions,

the obsolete features should be dropped from the standard entirely. This

gives a phased evolution, with users having ten or more years to upgrade their

programs to use the new core language.

A third module referred to as an "extensions module" has been proposed. This

is intended to contain language features which are state of the art technology

on an experimental basis which would please many go-ahead users who feel

stifled by the backwardness of the present situation. It should be understood

that features in the extension module may be moved to the obsolete features

module on a subsequent revision of the standard. However, features that prove

enduring could become part of the core language on a subsequent revision.

The fourth category are features which form "application area support

modules". They would provide language standardisation benefits to

applications such as database (Codasyl and relational), graphics and real-

time. These modules must be compatible with the core and language extension

modules and will be developed and maintained independently by specialists in

each application area. They will not be an integral part of the Fortran

language.

Dynamic Storage Allocation and Data Structures

Probably the most significant change adopted for Fortran 8X is to implicitly

allow stack-type dynamic storage. This has many benefits such as making it

easy to define temporary working storage for library routines or array

operations. It also makes data structuring, variable length character and bit

strings and recursion feasible. The main disadvantage is the loss of

closeness to the machine that was possible when storage association existed.

Stacks favour hierarchical data structures and it seems that that is what will

appear in Fortran 8X. Initial proposals are for a "simple" structure of

heterogeneous elements. The method used to define structures is first to

define a template or form. Then in a separate declaration statement, any

number of these structures may be named and allocated storage. For example:

        FORM DATE

        INTEGER DAY

        CHARACTER*3 MONTH

        INTEGER YEAR

        END FORM

        DATE TODAY,YESTERDAY,TOMORROW,YRDAY(365)

The last of these is an array of date structures. To reference an element of

a structure, a dot notation is currently preferred, e.g. TODAY.MONTH would

refer to today's month.

Further extensions to the "simple" structure proposal would allow hierarchical

structures with an element taking the form of a repeating group or a

substructure. In the latter case, a reference to a nested structure would use

several dots, e.g. TOWN.ROAD.HOUSE

Control Structures and Labels

New block CASE and DO statements are proposed. CASE is similar to that found

in most modern languages. A DEFAULT case is provided for. The new DO

encompasses most DO, FOR, WHILE and UNTIL statements found in other

languages. An EXIT statement permits exit from the loop at any point in the

body of the loop. A multi-level EXIT statement allows for termination of

'outer' nested loops. A CYCLE statement is being considered to allow skipping

to the next iteration.

A new method of labelling block statements is to be used. Labels may be

alphanumeric. In earlier standards only numeric labels were allowed.

Source Form

Without a numeric label field, a free format layout is to be allowed when

writing programs. A new continuation convention using the "&" character will

replace the card-based column six convention. Again this reflects the move

towards the use of on-line terminals.

Note that although programs using the new data and control structures do not

need a label margin they certainly do need indentation, otherwise programs

will be unreadable. Indentation is not part of the standard.

The new source form is incompatible with the Fortran 77 form. It is believed

that this incompatibility can be overcome by the use of compiler switches.

Array Processing

Contemporary machine architectures are moving towards greater operational

parallelism. To meet this, programming languages must enable the expression

of parallel operations. To gain the full advantage from array processors,

many algorithms will have to be re-formulated.

Fortunately research on languages such as Vectran and APL can be drawn upon.

Basic array processing consists of being able to request operations on whole

arrays or on array sections. A section is part of an array that has to be

identified by its position in the array. Examples of sections are: a row or

column or diagonal of a matrix. To define these a "section subscript"

expression is used. These differ from traditional array subscripts in that a

"section subscript" addresses many elements, the traditional subscript only

addresses one.

The notation for section subscripts seems primitive. For example, an asterisk

means "all elements in order", -* means "all elements in reverse order".

A(*)=A(-*) would thus reverse the order of the elements in A. Note however,

that it is the positional order that we are referring to and not the order in

which individual elements are assigned. The assignment may (or will) be done

in parallel. The notation A(S1:S2) refers to a section with lower bound S1

and upper bound S2. The so called "triplet" notation extends this by

specifying a step or increment. A(1:11:2) would address every alternate

element from one to eleven. I would be interested to hear from readers who

have better ideas for these notations.

In general array names and array sections may appear in the same places as

variables except for those places where an array would be nonsensical.

Many new functions for arrays and matrices are proposed.

Control Over Precision

Fortran does have two levels of precision, single and double. However, these

are concepts which are not machine independent. New features will enable a

decimal precision and exponent range to be requested. The processor will map

these into an appropriate internal precision.

A GENERIC statement will enable subroutines to be written independently of

precision. Formerly the user had to write two routines, one single precision

and one double. Portability of numerical routines should benefit greatly from

these changes.

Conclusions

The fact that effort is going into development of Fortran is an indication of

the joint commitment by users and suppliers to protecting the investment made

in programs and ensuring that the facilities available continue to relate to

current hardware. There are rumours that Fortran will be with us in the year

2000. Comments from readers are very welcome and will be passed on to the

Fortran Standards Committee (ANSI X3J3).

P. A. Clarke,

21 September 1982