British Computer Society Fortran Specialist Group

Minutes of a meeting held on Monday 6th December 1976 in lecture theatre

4.34, Royal School of Mines, Imperial College Computer Centre, Prince Consort

Road, London S.W.7.

Present:   Mr. D. T. Muxworthy (Chairman)   University of Edinburgh

Mr. M. Lewis (Vice Chairman)     Imperial College Computer Centre

Mr. A. J. H. P. Dean             Honeywell I.S. Ltd (N.I.S.D)

Mr. M. R. Dolbear                B.P. (London)

Mr. R. Grosvenor                 Honeywell I.S.

Mr. P. J. Hanson                 Honeywell I.S.

Mr. G. Harding                   Imperial College C.C.

Mr. D. J. Holmes                 Rolls Royce (1971)Ltd, Bristol

Mr. P. Loftus                    Marconi Elliott Avionic Systems

                                    Ltd., Rochester

Mr. D. J. Maisey                 I.C.L. Bracknell

Dr. J. Murchland                 University College London

Mr. K. Normington                Lanchester Polytechnic

Mr. H. Pitcher                   N.C.C.

Mr. T. L. van Raalte             M.O.D.

Mr. J. Roberts-Jones             Liverpool City Council

Mr. G. Ruscoe                    Honeywell I.S. Ltd (N.I.S.D.)

Mr. P. J. Vyse                   Honeywell I.S.

Dr. H. J. Zell                   Imperial College

Mr. P. A. Clarke (Secretary)     Rothamsted Experimental Station

Apologies for Absence:

           Mr. B. H. Shearing               Alcock, Shearing and Partners

1.    Approval of Minutes of Previous Meeting

The minutes of the meeting of 4th October 1976 were approved subject to

the following corrections:

On page 2, the last word should read 'contentious' not 'contentions', on page 5,

paragraph 1, replace the words 'Emotions with no arguments do not require a pair

of empty parentheses' by 'Subroutines with no arguments may optionally have a pair

of empty parentheses', on page 4 section 4.4, line 2, 'recommending' should read

'recommending' , on page 10 paragraph 5 'on IDMS operation' should read 'an IDMS

operation' and the last coded OBTAIN statement should have an asterisk in column 1.

2.      Matters Arising from the Minutes

        Since the last meeting, Dr. Stacey has made available copies of the slides

shown during his talk, together with an index of these. They are available on

request from the secretary.

        Mr. Roberts-Jones and Mr. Pitcher noted that Appendix A (Block IF statement)

gave no mention of proper nesting of block IFs and DOs. Mr. Clarke explained that

the two page appendix was only part of a re-draft of the complete section on Fortran

control statements, and the nesting rules were present. They had been further

extended by ANSI at the November meeting.

3.      Activities of other Fortran Groups

3.1     ANSI X3J3 Activities

        Since our last meeting, the minutes of the September meeting of X3J3 had been

received. Mr. Muxworthy discussed some points that had not been fully covered in

our last meeting. These included a proposal to extend names to 8 characters which

had been rejected because it was considered to be too costly for a little benefit.

Discussion of trailing comments, delimited by :* (presumably colon for end of statement

asterisk for comment. This combination would permit a future extension of multiple

statements per line) was postponed until November. Character functions of constant

length are allowed, array block item in I/O lists was deleted because of a syntax clash

with a possible proposal for array cross sections. Mr. Muxworthy suggested this might

be because, as Dr. I.D. Hill had said in June, public comments would tend to emphasise

disapproval and forget to approve of certain welcome features.

        The minutes of the November meeting of X3J3 had not been received, but a document

entitled Fortran 77 which summarises the major changes to dpANS (March 1976) since

it's publication had been received from Dr. Meissner (see Appendix A). This

contained some details of decisions made at the X3J3 November meeting, and these were


        While some people present were against the practice of using extended range of

DO-loops, there was discussion as to the implication of prohibiting extended range.

        When a subroutine was called from a statement in a DO-loop, was the RETURN

considered to be transfer of control into the range of the loop? If open-coded

procedures were introduced into Fortran could they be referenced from within a DO-

loop? Open-coded procedures currently implemented by preprocessors (and making use

of assigned or computed GO TO's) and referenced from within DO-loops would become

non-standard. It was decided to wait until the full minutes were available before

taking any action on this point.

  The IOSTAT= specifier in I/O statements appeared to offer little advantage over

ERR= and was processor dependent. However, it was thought to be 'in the spirit of


        The functions ICHAR, CHAR and INDEX were considered useful. The fact that

ICHAR could not be used in DATA (or PARAMETER) statements, was a slight restriction -

possibly encouraging programmers to use processor dependent constants, when this was

not necessary.

        Dr. Murchland had noted that in the October 1976 Sigplan Notices, the Vice-

Chairman of the ACM Standards Committee had indicated that the ACM Standards Committee

had received only 25 responses to the dpANS (March '76) (of which 14 were in favour.

and 11 against) which was not sufficient to be representative of the ACM membership

and did not justify the publication of Fortrev in Sigplan Journal.

        Mr. Clarke noted that BCS Standards Committee had not received any response at

the time of his last contact with Mr. Fisher. Mr. Muxworthy noted that the Fortran

Specialist Group had received only six responses, but that ANSI X3J3 had received

over 600 and he concluded that members of the public had short-cut their local

organisations and sent comments directly to X3J3.

        Mr. Lewis said that he had received a newsletter of the CDC Computer Users

Group in which a note by Mr. R. Ragan, a member of X3J3 indicated that the next letter

ballot on the draft standard would probably be in mid 1977.

        We had formerly expected this about March 1977.

3.2     Fortran Development Committee

        Members had received Vol.2. No.4 of the FOR-WORD Fortran Development Newsletter

This contained copy of the IFIP W.G.2.5 proposals discussed at our last meeting, and

a summary of three data-structuring proposals for Fortran submitted to X3J3 by

Mr. D. N. Smith (Tymeshare Inc.). Also it contains many correspondences from

interested people worldwide. Mr. Clarke recommended that members ask for their names

to be put on the mailing list for FOR-WORD by writing to the Editor, Dr. Loren P.

Meissner, 50B 3259, Lawrence Berkeley Laboratory, Berkeley, CA 94772O, U.S.A. At

present, there is no charge for this.

        Mr. Clarke described (with slides) some of the proposals that had been ration-

alised by Dr. Meissner from the many that had been studied in the structured pre-

processor survey. (See Appendix C)

        Comments from those present included the following:

        Mr. Pitcher said that a single GOTO was simpler than the DO (forever) - ENDDO,

Mr. Maisey asked if Fortran was a suitable language for these statements and was

supported by several other people present when he objected to 'doing-away-with'

labels which these statements tend to make unnecessary. An argument in favour of

Fortran labels was that their use guided the eye to the appropriate text - some of

the block structured statements could be difficult to follow because they require

matching up the begin and end of block and when nested deeply this could be tricky.

        Mr. Maisey objected to the inclusion of the statements just for the sake of

'structured programming purists'. He Suggested that they use some other language.

        Mr. Dolbear said that structured programming was a language independent concept.

A structured design could be mapped into most procedural languages, with, or without

structured control statements. The presence of structured control statements

simplified the mapping, He recommended the book 'Principles of Program Design' by

M. Jackson, published by Academic Press as an exposition of the ideas of structured


        Mr. Clarke requested that those who felt strongly against (or for) introducing

these statements should write to Dr. Meissner and the views could be published in


3.3     CODASYL Fortran DBML Committee Activities

  No further information had been received from the CODASYL FDBMLC. Mr. Clarke

said that because he was aware that there were not many Fortran programmers who

were familiar with the CODASYL database facilities, he had prepared a document

'Introduction to Fortran Database Programming' describing them from a Fortran

viewpoint. A circulation copy is available upon request. He noted that the

FDBMLC JOD was not suitable as an introductory text.

3.4     Other Fortran Groups

3.4.1.  Purdue Workshop Activities

The Secretary had received the minutes of meeting of ISA SP61 and IPW Fortran

Committee on 10-12 October 1976. At that meeting there had been discussion of the

S61-1 and S61-2 standards. A draft standard S61-3 on tasking is in preparation

under six headings, Initiation, Synchronisation, Termination, Communication,

Exception, and Critical Regions.

A review of Fortrev had been made and comments on (1) restrictions on COMMON

block of type CHARACTER, (2) extension of PARAMETER, (3) definition of ASSIGN GOTO

with out-of-range argument and (4) keyword specifier EVAL for I/O error value had

been sent to X3J3 and a proposal for type BIT which defines BIT constants, relation

of BIT to INTEGER, relation of BIT to LOGICAL, BIT operations, relational operations

and shift operations.

4.    Progress Reports

4.l   Preprocessor Working Party

Dr. Murchland reported the following activities:

The preprocessors FLECS (Terry Beyer) and Mortran (A. James Cook) have

now been obtained, the latter by courtesy of Dr. Jack Lang (The Computer

Laboratory, Cambridge). Also available was a structured Ratfor preprocessor.

Now there is a problem in obtaining suitable teat problems! What would Group

members regard as adequate evidence for the merits and demerits of a preprocessor?

Loren Meissner (Lawrence Berkeley Laboratory) had offered us the complete

collection of preprocessor documents which they gathered for the survey they did.

Alan Clarke has offered to keep these at Rothamsted and make them available upon


Dr. Murchland asked if there were any comments on the proposed Fortran pre-

processor statement syntax on page 5 of the minutes of the last meeting? Mr. Clarke

said that the syntax could be extended to include declaration statements and compound

structured statements. The WP are still interested in, and working slowly on, the

original items - terminology for describing preprocessors, a list of available

preprocessors and a list of useful references. The terminology seems to get core

difficult - the preprocessors we have do not provide their standard Fortran output

in a form where it could be distributed as a readable Fortran program.

He said that the W.P. was short of active members, neither Ian McNicol nor

Peter Evans had made a contribution to date and new members to the W.P. would be


4.2   Group Promotion/Information W.P.

Mr. Clarke said that he was still working on the document 'Introduction for

new members' and on the revised Contact List. The new list would include, where

possible, telephone numbers and publications (if any) against each entry.

He requested suggestions as to how to make the contact list more effective

and wondered what use had been made of it to date.

4.3   W.P. to Review the CODASYL FDBMLC JOD

Dr. Stacey had agreed to lead this W.P., Mr. J. S. Knowles (Aberdeen University)

and Mr. P. A. Clarke are the other members. As a result of telephone conversations,

the objective of the W.P. has been narrowed to 'review the JOD from the database

programmers viewpoint' rather than to prepare an introductory description.

5.    BCS Business

In the absence of Mr. Shearing, Mr. Muxworthy reported that at the last

meeting of the BCS Specialist Groups Committee. Specialist Groups had been re-

grouped under four headings: Languages, Applications, Transport and General.

This was for publication purposes.

Mr. Muxworthy said that he had written to the BCS in connection with the recent

visit to Great Britain of A. Ershov saying that the Languages Specialist Groups

should have been given the opportunity of arranging a meeting with Prof. Ershov. Prof.

Ershov had considerable experience and interest in computer languages and a

valuable opportunity had been missed.

Mr. Muxworthy had had no reply from the BCS and wondered what was happening.

6.    Any Other Business

Details of a BASIC to FORTRAN translation service provided by the National

Development Programme in Computer Assisted Learning (NDPCAL) had been received and

copy can be obtained by interested members, on request, from the Secretary.

Mr. Dolbear had a request for help to check some algorithms for 'floor' and

'ceiling' functions coded in Standard Fortran. Copies were distributed at the


7.    Date of Next Meeting

The next meeting will be on 7th February 1977.


In the Afternoon, Mr. G. A. Ruscoe (Honeywell Network Information Services

Division) gave a talk on 'Fortran on an International Time-Sharing Network'(see

Appendix B). This was followed by discussion, much of which centred on the

implementation of strings.

Appendix A

[In the original typescript this appendix was presented in two columns
with a small (9pt) font.  It has been re-formatted to improve legibility
in a browser window.]

   Fortran 77

   It appears that a number of individuals and  organizations have been

proceeding on the unwarranted assumption that the draft proposed Fortran

standard (SIGPLAN Notices, March 1976) is essentially a correct

description of the final form of the language as it will be ultimately  

released by the X3J3 committee. Many implementations of the language so

described are beginning to appear or to be referred to in private and

public distribution, in spite of the disclaimers included in all copies

of the published document.

  The purpose of publishing the draft was in no sense to "freeze" the

language specification. On the contrary, the intent was to indicate to

the public the directions of the committee's plans, and to provide a

forum for feedback to permit changes to be made in response to public

review. In the year (more or less) since the text of the draft proposal

was adopted, the committee has made a number of significant changes to

the language. The purpose of this note is to summarize the more

significant of these. For further details, reference should be made to

X3J3 documents containing the minutes of recent meetings (since the

beginning of 1976). These are available upon request from Lloyd Campbell,

whose address appears in the SIGPLAN document.

Name of the language. The committee has adopted the working name

Fortran 77, to be used when informally referring to the language described

by the proposed standard.

Collating sequence. The draft states that letters are in order from A to

Z and digits from 0 to 9, and that blank is less than A and less than 0.

A further restriction has been made, so that the letters and the digits

must not overlap.

Blank lines. It has now been provided that a completely blank line will

be considered a comment line.

Statement ordering. A new restriction applies with regard to symbolic

names of constants (i.e., names defined in a PARAMETER statement) and var-

iables appearing in a dimension bound expression (in a subprogram). These

must not appear in explicit type statements farther down in the same

program unit. Data type of a name. The draft states that the data type of

a symbolic name of a constant (in a PARAMETER statement) is determined by

the form of the constant. This has been changed to depend on the form

of the name.

Scope of names. A clarification has been adopted, to the effect that the

scope of an implied DO variable in a DATA statement is the implied DO


Type restrictions for subscripts etc. Real and double precision

expressions are no longer permitted as subscript expressions, substring

expressions, label selectors for computed GO TO, external unit

identifiers, record number specifiers, record length specifiers, maximum

record length specifiers, or alternate return specifiers. However,

integer expressions that include the INT or NINT intrinsic functions

applied to expressions of other types are permitted.

Intrinsic function names. The draft provided that certain type statements

could change an intrinsic function name to external (i.e., the processor

would expect a non-intrinsic function with the specified name to be

supplied). This has been changed, so that only an EXTERNAL statement can

remove a function name from the intrinsic category in this way.

PARAMETER syntax. Expressions (which may involve symbolic names of

previously defined constants) may be included in the definition of

symbolic constants in a PARAMETER statement. Also, the entire list of

definitions must be enclosed in parentheses. A logical expression used

in the definition of a symbolic name may include relational operators.

New logical operators. Logical operators .XOR. and .EQV. have been added.

Logical operator precedence is .NOT., .AND., (.OR., .XOR.), .EQV. The new

operators represent "exclusive OR" and "logical equivalence",


Block IF. The following statements have been added to the language:

      IF (e) THEN

      ELSE IF (e) THEN


      END IF

Between an IF-THEN and its END IF there may appear any number of ELSE IF-THEN

statements and at most one ELSE (which must not precede any ELSE

IF-THEN). Blocks delimited by IF-THEN and END IF must be properly nested,

with respect to other such blocks and with respect to DO loops.

Prohibit extended range. Transfer of control into the range of a DO-loop

is now prohibited. Transfer into a block IF structure; or from one

sub-block of the structure to another, is prohibited; however, a transfer

from anywhere to an END IF statement is permitted.

Input and output statements. The Stream access method has been

eliminated. List-directed sequential input and output has been retained

(similar to "format-free" methods that have been implemented);

list-directed output is not suitable for list-directed input, however. An

IOSTAT specifier may be included in any input or output statement

(including auxiliary and file positioning input or output statements), to

permit determination of the cause of an error or end-of-file condition

without a transfer of control. The specifier is IOSTAT = ios where

ios is an integer variable (or array element) that becomes defined with

the value zero if all is well, with a positive integer value if an error

is sensed, or with a negative integer value if no error is sensed but an

end of file is sensed. The specific positive or negative values used

are processor dependent. The ERR = s and END = s specifiers are also

still provided.

  The list of "mandatory" error conditions in section 12.6 of the draft

has been replaced by the statement that "the list of error conditions is

processor dependent."

  The preconnected units used for the PRINT statement and for the short

form of the READ statement must not be internal files.

Input and output lists. Empty lists are no longer prohibited, since

whatever difficulties they might cause must also be corrected for the

case of zero-trip implied-DO lists.

   List items of the "array block" form such as

     A(2,3) : A(5,l)

have been eliminated. However, the use of the unqualified array name to

refer to the entire array is still permitted.

  A clarification has been adopted, to the effect that implied-DO

variables become undefined when the list items become undefined due to an

error or end condition during input.

Format edit descriptor. The form Gw.dEe has been added, which has the

same effect as Fw.d or Ew.dEe depending upon the magnitude of the datum.

Auxiliary input and output statements. A file that is opened as a scratch

file must not be closed with KEEP status.

  An inquiry specifier must not be referenced by any other inquiry

specifier in the same statement (to avoid side effects).

New intrinsic functions for character type. The intrinsic function ICHAR

returns the value of an internal character representation, considered as

an integer. CHAR takes an appropriate small integer and returns the

character having the same internal representation. INDEX returns the

first character position for which a given (short) pattern matches a

substring of a given (long) string.

Other subprogram changes.

  The intrinsic functions for type conversion (INT, IFIX, IDINT, FLOAT,

SNGL, REAL, DFLOAT, DBLE, CMPLX) are not permitted as actual arguments.

  Character function names may be used as actual arguments.

  The generic function name ATAN has only one argument; for two

arguments the generic name is ATAN2.

  A statement function of type character, having constant length, is


  Character strings of "adjustable" length (specified by a non-constant

expression) are eliminated as dummy arguments; however, the "passed"

length (determined by the length of the actual argument) is permitted.

  Notes to Table 5 in section 15 have been corrected with regard to the

definitions of the ATAN2 and CLOG functions.

  A subroutine with no arguments may be defined with empty parentheses

following the subprogram name. The same applies to an ENTRY statement in

a subroutine.

Loren P. Meissner

50B 3239

Lawrence Berkeley Laboratory

Berkeley CA  94720

22 Nov 1976

   Appendix B

  Summary of Fortran on an International Timesharing Network

by G. A. Ruscoe

The Network concerned is the Mark III Network Information Service owned and

operated by the General Electric Company of the USA, and marketed in Europe and

Australia by Honeywell. Based on Honeywell 6080 Central Systems the network offers

local access to the same files by local call in Japan, Australia, USA, Canada,

Mexico and most countries of Europe from Spain to Finland and Ireland to Austria.

Although standard Batch Fortran is available on Background Processors, the principal

compiler considered is that specially developed for the Foreground, interactive

service. This has been influenced by certain features of the environment namely:

Terminal use (free-format), Interactive use (conversational or command driven),

Multi-access (shared files, random files), Non-professional use (flexible input,

clear diagnostics), Bias to business applications character handling, data

management, program generation). These factors affect both the programmer and the

user and are reflected in the language features and system routine library.

For the programmer they imply-Free format, line numbered source text; an on-line

debug facility; compiler checking options, and excellent error messages; list directed

input and various types of character variables, especially strings. For the user

there is conversational input which may be flexibly entered and easily

checked by the program; free format data files; programs which appear as additional

system commands or a program which starts at sign-on and controls all operations until


Specific areas of interest are.

l. Shared access to files - implemented by routines which allow shared open with

read access, Lock before write and unlock, Sleep if file busy and Wake if one program

is to interact with another. Identity can be obtained (Part number, user number etc.)

as well as time and date in GMT and user time. Random access to files and a

Hierarchical Indexed Sequential access method are vital to business applications as

are calendar functions, bit manipulation for data packing and picture editing of output.

2. Command system operations - any system command maybe invoked by program, especially

file creation, purge, permission, etc. with status information.

Also programs may be invoked as pseudo-commands, instead of RUN e.g. /PAGELIST FILE1;

FILE2,DW; . . .

The program may read the parameters, read the current file and replace it and generally

act as a normal command.

3. Character handling If one feature characterises the compiler it is the STRING

type. Strings are dynamic (up to 4K characters) with flexible storage allocation and

automatic garbage collection. The language allows assignment and concatenation,

and user string functions. Functions and routines allow efficient string search,

extraction, alteration, conversion to arithmetic value and manipulation generally.

These features allow the passing and vetting of input data, especially on-line input

making due allowance for such factors as use of upper or lower case, inclusion of

excess blanks, abbreviation of words and so on. Many programs, especially pseudo-

commands require a small amount of input which can be made as flexible in form as

possible and where errors are detected the correct input can be prompted. This

revolutionises the user environment. Examples of the use and method of implementation

of strings are instructive.

4. Language extension For many applications the genera1-purpose package has been

superseded by the preprocessor, written in FORTRAN. This takes an application program

in some form and generates a special purpose FORTRAN program, which may be retained

for regular use. Sometimes the application program is a distinct language (e.g. DMS),

Sometimes a form which allows the inclusion of FORTRAN statements (e.g. TABOL).

This form of pre-processor is again heavily dependent on string handling for parsing

the input.

Appendix C

Some proposed control structures for Fortran

The following statements are derived from those published by Dr. L. P. Meissner

in the October 1975 issue of FOR-WORD. The notation 'S' is used to mean a single

Fortran statement or block of Fortran statements and'L' a logical expression. The

control structures are designed to provide control for sequence, selection and

iteration of statement execution. For statements to be executed in sequence, the

statement order is sufficient and no further controlling statements are required.

For selection and iteration, several possibilities are given.

Simple Selection                                Multiple Character Case Selection

IF(L)THEN                                       CHARACTER MONTH*3

S                                               SELECT(MONTH)

ENDIF                                           CASE('JAN')


Binary Selection                                CASE('JUN','JUL')


1F(L)THEN                                       ENDSELECT


ELSE                                            Simple Iteration (forever)


ENDIF                                           DO


Multiple Binary Selection                       ENDDO

IF(L1)THEN                                      Conditional Iteration(1)


ELSEIF(L2)THEN                                  DO WHILE(L)

S2                                              S

ELSE                                            ENDDO


ENDIF                                           Conditional Iteration(2)

Multiple Integer Case Selection                 DO UNTIL(L)


INTEGER MONTH                                   ENDDO


CASE(5,6,7,8,9)                                 Generalised Iteration with Interrupts


CASE(1,11)                                      (NEXT AND EXIT Statements)

RATES=WINTER                                        DO

CASE(12)                                               DO

RATES=XMAS                                                S

OTHER                                                     IF(L1)EXIT 99----------------

RATES=NORMAL                                              IF(L2)NEXT 99-------------   |

END SELECT                                                 S                        |  |

                                                           IF(L3)NEXT-----------    |  |

                                                           S                    |   |  |

                                                       ENDDO <------------------    |  |

                                                       S                            |  |

                                                       IF(L4)NEXT---                |  |

                                                       S            |               |  |

                                                99  ENDDO <-------------------------   |

                                                    S <--------------------------------