FSG minutes of 7th December 1972

BRITISH COMPUTER SOCIETY FORTRAN SPECIALIST GROUP

Minutes of a Meeting held

on Thursday, 7th December

1972 at Barnard's Inn,

Holborn Bars, London EC1

at 10.30 am.

Present: Mr J.S. Gatehouse (Chairman) G.E.C

Mr E.O. Bodger IBM Information Services

Mr P.D. Bond Philips Industries

Mr H.W. Bradly C.A.D. Centre, Cambridge

Mr R.L. Butchart D.T.I.

Mr J.C. Cullen B.P.

Dr A.C. Day University College London

Mr I.D. Hill M.R.C.

Mr K. St. Pier G.E.C.

Mr B.H. Shearing Alcock Shearing & Partners

Mr D. Winstanley University of Birmingham

Mr D.T. Muxworthy (Secretary) Edinburgh R.C.C.

Apologies

for Mr P.J. Hammond B.P.

Absence: Mr D.J. Maisey I.C.L.

Mr D.H. Marwick Heriot-Watt University

ACTION

l. APPROVAL OF MINUTES The minutes of the meeting of the 21st September

1972 were approved.

2. MATTERS ARISING FROM a. Members of the Diagnostic Working Party had each

THE MINUTES been asked whether they were prepared to revive

the activities of this group. No response having

been received, the Diagnostics Working Party was

formally wound up.

b. There had so far been a disappointing response to

the invitation to contribute information on

deviations of compilers from the ANSI Standard.

It was thought that SPL were working in this area

and it was decided to forward the four contribu-

tions to Mr Kelly and to ask him to decide further IDKK

action, possibly in association with SPL. Any new

offerings are welcome and should be sent to

Mr Kelly at 96 Kings Road, Walton, Surrey.

The Editor of the Computer Bulletin had been cont-

acted about early replies to letters and had

answered that if any letter was concerned with the

activities of a specialist group he would contact

the Chairman of the Group before printing it.

However as the Bulletin was suspending publication

the question was now hypothetical.

A copy of the Chairman's letter had been sent to the

Editor of the Computer Journal, who had replied that

it was not current practice to send letters to

interested parties before publication, although this

policy may be changed. The Group was invited to

use the Journal to report the conclusions of its

investigations. The Secretary was to invite DTM

Mr Hall, whose letter in the Journal of August

1972 was of this type, to join the Group.

d. It was decided to submit reports of each Group

meeting to "Computing", the successor to the

Bulletin. As a trial, the Secretary would send

a note of topics covered to Mr Shearing, who DTM/BHS/

would write an article in a suitable style JSG

and submit this to the editor of "Computing",

after showing it to the Chairman.

e. No further members of the Group had expressed

interest in the proposed Language Contractions

Working Party. Mr Gatehouse was to contact those JSG

who had put forward their names at the last

meeting.

f. There had been no reply to the Group's views on

the Computer Journal Algorithms Supplement policy

statement.

3. BSI REPRESENT- The British Standards Institute had invited the

ATION Specialist Group to nominate a member of the BSI

DPE/13 (Programming Languages) committee.

Mr Gatehouse had accepted the invitation on the

understanding that he could ask other members of

the Group to attend meetings in his place.

4. HIGH LEVEL Mr Shearing reported that the principal languages

LANGUAGE CONFERENCE discussed at the conference were Algol 68, Cobol,

Fortran and PL/I but it appeared that there would

be no universal language in the foreseeable future.

The conference had helped to alter the impression

that Fortran was a dying language and the audience

had been impressed by the fact that the new Fortran

standard would be compatible with the old.

Arising out of this conference the Chairman had

become aware of "Shell Standard Fortran" and

"Shell Standard Basic Fortran", the former being

the common subset of IBM 360, XDS Sigma 7,

Univac llO8 and Univac 9400 dialects expressed in

the style of the ANSI Standard.

5. DATAFAIR 73 The Group was to organize a discussion session,

"Fortran - the way ahead", at Datafair 73 on April

11th from 3.00 pm to 4.45 pm. It was decided that

Mr Gatehouse should chair the session and that

members of the extensions working party should give

short presentations of the more interesting of the

proposed extensions to the ANSI Standard. An

audience of between 25 and 150 was expected. DTM

6. ISO TC 97 METING The BSI had invited the Specialist Group to nominate

a delegate to the ISO TC97/SC5 (Programming

Languages) meeting in Washington D.C., held on

November 28 to December 1st 1972. Dr Day had

attended the meeting as the Fortran delegate and

Mr Hill as chairman of the Algol subcommittee.

Seven countries, France, Japan, UK, USA, Germany,

the Netherlands and Switzerland were represented at

the meeting and of these the first four attended the

Fortran working sessions. Seven members of X3J3

represented ANSI.

Dr Day reported that X3J3 were completing work on

their revision of the Standard and were now

courting international opinion with a view to the

new standard being accepted by ISO as well as by

ANSI. It was probably too late to add significant

new features but it was possible to remove or amend

extensions which had been approved but which were

disliked. A formal resolution that the new standard

be "totally compatible" with the old had been defeated

2-4 but one to the effect that the greatest care be

taken to avoid incompatibility and that any incompat-

ibilities be documented was approved. Members of

X3J3 wanted the current ISO recommendation, R1539,

to lapse so as to enable different subsetting of the

new standard. ANSI are to forward copies of the

draft proposed American National Standard (dpANS)

as soon as it is available; the question of BSI or

BCS reproducing this was raised but not pursued.

Dr Day distributed a note on proposals to be sent

from the Group to X3J3. This had been revised

following a meeting of the Extensions Working Party

the previous day and there followed a detailed

discussion of the paper. The version ultimately

sent to the Chairman of X3J3 appears as Appendix A

to these minutes.

The Group wishes formally to record its thanks to

Dr Day for all the work he has done in connection

with the meeting, and its thanks to the National

Computing Centre Ltd. and to University College

London for making the visit possible.

It was made clear that X3J3 welcome comments from

individuals on their proposals. Comments may be sent

to the Chairman:

Mr F. Engel Jr,

179 Lewis Road,

Belmont, Mass. 02178.

and/or to the X3J3 member with special responsibility

for international liaison:

Mr J.C. Noll,

Room 2F-406,

Bell Laboratories,

Holmdel, N.J. 07733.

Mr Noll is also on the editorial subcommittee of

X3J3 and any editorial comments may be addressed

to him. Constructive criticism on editorial matters

is always welcome.

7. DATE OF NEXT The next meeting will be held on Friday, March 2,

MEETING 1973 at 10.30 am. The place of the meeting has been

provisionally arranged to be the Tearoom of Barnard's

Inn.

APPENDIX A

December 8th 1972

TO: ANSI X3J3

FROM: BCS Fortran Specialist Group

SUBJECT: Proposals concerning the new Fortran standard.

PROPOSAL l. That the SUBARRAY statement be removed from the new

standard.

Rationale: (a) Subarrays are irregular (compared with arrays) in

terms of the places where they may appear. They cannot be

used as arguments to subprograms. It is not certain whether

they may appear in I/O lists. They may not be used for a

FORMAT specification, as the storage may be non-contiguous.

They cannot occur in DATA lists, as they may be controlled

dynamically by means of variable subscripts.

(b) The subscript expressions permitted by the new

standard in DIMENSION and type statements cannot be allowed

for the subscripts in SUBARRAY statements, as this would imply

deferred evaluation of expressions, causing very great

inefficiencies for each subarray reference. Redefinition of

adjustable dimensions will not have any effect in a DIMENSION

or type statement, but the reverse is true for SUBARRAY.

recursive definitions. Although the X3J3 proposal does not

say so, presumably array element references are not allowed in

the subscripts, as otherwise the following statement would be

possible:

SUBARRAY JIM(34) AT A(JIM(2))

Even without this problem, recursion can occur, as shown by:

SUBARRAY JIM(34) AT A(25), A(45) AT JIM(32)

(d) If the proposal for subarrays is to be compatible

with the new rules for DIMENSION and type statements, then

lower bounds should be included, introducing further complications.

(e) The syntax for the statement is peculiar. It has

keywords in the middle of the statement, a situation matched

only by the ASSIGN statement.

(f) The 'principle of least astonishment' is violated

in such examples as:

DO 13 I = 1, 15

13 A(4) = B(4)

Here the loop can only be redeemed from the realm of nonsense

(or from being optimised out of existence) by being preceded

by statements such as:

DIMENSION C(55), D(55)

SUBARRAY A(6) AT C(I), B(6) AT B(I)

(g) The SUBARRAY statement is not likely to be of help

to many.

PROPOSAL 2. That reverse cross-sections of arrays be removed from

the new standard.

PROPOSAL 3. That array cross-sections be removed from the new

standard.

Rationale: (a) As with the SUBARRAY proposal, the problem of non-

contiguous storage is introduced. Cross-sections may therefore

not be passed as arguments to a subprogram, and may not be used

for a FORMAT specification.

(b) If cross-sections are nevertheless passed as arguments,

the irregular situation arises whereby correct results may be

obtained only if the cross-section is forward and is based on

the first subscript.

assignment statement using cross sections does not cause

overlapping to occur.

(d) For reasons of regularity, many repercussions of

this proposal must be considered. Are cross-sections to be

permitted in I/O lists? Or block transfer list items in an

assignment statement? These are apparently two proposals to

do very similar things, but have quite different limitations

(one cannot step backwards, and the other cannot refer to less

than a complete cross-section). Are cross-sections to be

permitted in DATA statements? Or implied DO loops in

assignments? Have cross-sections of subarrays been considered?

This whole area seems rather ill thought out, with partial

extensions criss-crossing one another.

PROPOSAL 4. That the order of specification statements must not

be more restrictive than in the present standard.

Rationale: (a) As the meeting of ISO/TC 97/SC 5 showed, there is

very great pressure for the new standard to be compatible with

the old. To restrict the order of specification statements

would be an incompatibility of the first magnitude, which

would invalidate a considerable proportion of the programs

which currently conform to the standard.

(b) If the justification for this restriction is in

order to make things simpler for a one-pass compiler, then

the restriction could well be made a feature of one of the

lower subsets of the new standard. However, as far as we

can see, this should not present problems even to a one-pass

compiler. We are not sure whether the proposed restriction

would involve DATA statements, and we would appreciate

further information on this point.

PROPOSAL 5. That the length of variables defined in a CHARACTER

statement should be given in parentheses instead of

following an asterisk and preceding a comma. The length should

only occur following the keyword CHARACTER, and then applies to

every variable defined in that statement.

A comparison is made here of Boswell's 'Compromise

Syntax' and 'BCS Syntax' to show how they correspond.

Compromise Syntax BCS Syntax

CHARACTER*5, A(l0),B(2,2),C CHARACTER(5) A(l0),B(2,2),C

CHARACTER*(N), D CHARACTER(N) D

CHARACTER*(*), E(11) CHARACTER(*) E(11)

CHARACTER*(N*M), F(13) CHARACTER(N*M) F(l3)

CHARACTER*3, G, H*5 J CHARACTER(3) G, J and

CHARACTER(5) H

Rationale: (a) According to the X3J3 proposal, parentheses would

be necessary only if the length was not a constant. The

asterisk and comma are always needed. If parentheses are

always obligatory the rule is perfectly simple and regular,

and both the comma and the asterisk may be dispensed with.

(b) The X3J3 proposal is unsatisfactory in such cases

as the declaration for G, H and J above. The inexperienced

user is liable to wonder Whether the length of J is 3 or 5,

as he will have learnt from the P factor in a FORMAT statement

and from the COMMON statement that a change made in the

middle of a statement may apply to succeeding items.

will include precision of numeric variables. This should be

declared in terms of decimal digits, and for economy of syntax

should parallel the length feature of character variables.

However, the asterisk notation is used by IBM for precision

in terms of bytes. We should therefore avoid this notation

for representing the length of character variables.

PROPOSAL 6. That the new standard should allow programmer-defined

functions of CHARACTER type, returning a fixed length

character value whose length has been declared in both the calling

program and the function itself.

Rationale: (a) If CHARACTER type is introduced, it should be a

fully regular type, matching in every way possible the types

already available.

(b) Although a variable length function may well be

preferable, this seems out of the question at the present time.

It is nevertheless better to be able to write fixed length

character functions rather than none at all.

seeing that the amount of storage required for the value is

known to both calling and called segments, just as for words

requiring one or two words for the result. If character

arguments may be transferred, then character functions can be

implemented, as the value returned can be treated as an

additional argument.

PROPOSAL 7. That the implied DO in an I/O list should be extended

in the same way as the DO statement, allowing

expressions as the parameters, and real or double precision

variables as the control variables. Function references in the

expressions must not cause I/O operations to be performed.

Rationale: (a) The two types of loop-controlling features should

be kept in step for reasons of regularity.

(b) A real or double precision control variable could

in certain circumstances be very useful. The I/O list may

contain a function reference for which one argument should be

the control variable, or it may be necessary to write out a

regular series of real values. The same extensions cannot,

of course, be applied to the DATA statement, as any implied

DO there must be interpreted at compilation time.

PROPOSAL 8. That an alternative keyword should be found for the

PARAMETER statement.

We agreed in our dislike for "PARAMETER", but we were not

able to reach full agreement on any other term. "CONSTANT" won

most approval. Other keywords suggested were "HOLD", "SYNONYM",

"EQUALITY" and "IDENTITY".

Rationale: (a) The term PARAMETER is used widely to describe an

argument. This will cause much confusion, as the items

defined by the statement are certainly not arguments.

(b) Although ill-phrased references to CONSTANT variables

may be confusing, it is true that the items declared by means

of this statement are symbolic representations for constants,

and some term should be chosen which reflects this fact.

of this feature uses the term PARAMETER, but the fact that the

first implementor got the term wrong should not be used as a

reason to foist this unfortunate error on the whole Fortran

community.

PROPOSAL 9. That the BACKSPACE, REWIND, ENDFILE, SKIPFILE,

BACKFILE and any other statement referring to I/O

operations should permit the unit reference to be:

(UNIT=value)

Rationale: This is in order to maintain and increase the regularity

between these statements and the READ, WRITE, OPEN and CLOSE

statements (see Proposal 13).

PROPOSAL 10. That the INQUIRE statement not be added to the new

standard.

PROPOSAL 11. That direct access READ and WRITE statements be

permitted in Fortran, differing from the corresponding

sequential READ and WRITE statements by the addition of the

parameter

REC=value

within the parentheses enclosing the unit designation.

PROPOSAL 12. That wherever the new standard includes as keywords

abbreviations of English words (e.g. ERR, REC), the

full word also be permitted as an alternative (e.g. ERROR, RECORD).

PROPOSAL 13. That OPEN and CLOSE statements be permitted of the

following form.

OPEN (UNIT=value, NAME=charvalue, ERR=label)

CLOSE (UNIT=value)

In the OPEN statement, the specification of NAME and EPR

are both optional. If the unit designation comes first within the

parentheses, then "UNIT=" may be omitted. If the unit is specified

by an integer constant or an integer variable, and no other

information is given by the OPEN statement, the parentheses may be

omitted, and the statement takes the form:

OPEN value

The OPEN statement is executable, causing the program to become

associated with the file. The charvalue above is a character

value which provides a way of referring to the file in terms

external to the Fortran program. If it is not possible to

associate the program with the file, execution continues at the

statement specified by the label. All other attributes of the

file (old or new, device type, record length, label type, protection,

direct or sequential, keyed or unkeyed, space, disposition on

closing, blocking factor etc.) will (if they are necessary) be

given outside the Fortran program. If an OPEN statement for a

particular unit has not been executed, the first READ or WRITE

statement for that unit will implicitly open the file.

The CLOSE statement is also an executable statement,

causing the program to become disassociated with the file. In

this statement "UNIT=" may be omitted, in which case, if the unit

designation is an integer constant or an integer variable, the

parentheses may also be omitted, and the statement takes the form:

CLOSE value

Rationale: (The X3J3 proposals referred to here are those which

were described at the Washington meeting of ISO/TC 97/SC 5.)

(a) As "keyword parameters" have already been included

in the proposed new standard through "END=" and "ERR=" it

seems good to use this syntactic technique elsewhere.

However, the X3J3 proposals have parameters which are in a

sense "keyword" and yet have no equals sign (e.g. VARYING).

These have no parallel in Fortran. If OPEN is to be made

regular with READ and WRITE, so that "UNIT=" may be omitted if

the unit is given first, then ambiguity results, since a

keyword such as NEW cannot be distinguished from a variable

unit number if it is in the first position.

(b) Some of the proposed features of the OPEN statement

are incompatible with the present Fortran standard. For

instance, specifying whether a file is formatted or unformatted

contradicts the present possibility of writing on one unit

with a mixture of formatted and unformatted WRITE statements.

The VARYING option does not do anything, as at the moment one

can read records of different lengths provided that the I/O

list plus the format tally; with the new option one must still

provide an I/O list (and format) of the correct length. The

new standard should allow a mixture of direct access and

sequential I/O statements to be used with the same file.

parameters to specify variables which are to be given values.

The result is similar to an assignment statement in which the

assignment is from left to right, and is highly undesirable.

(d) It appears that the aim of the X3J3 proposals has

been to include all features of the file, so that non-Fortran

control statements may be eliminated, a state of affairs which

may be especially helpful to users of terminals. This has

not been successful. Some features which will be of vital

necessity have not been included, e.g. the number of records

for a new direct access file. Some features place an

intolerable burden on the operating system, e.g. using INQUIRE

to find the maximum record length of an unlabelled magnetic

tape file, which involves reading every record. It is

impossible to specify the device type required for the file

without including in the Fortran language a list of obsolescent

devices which will rapidly become incomplete, and yet it may

be necessary for the user to inform the system of the device,

even for scratch purposes. For these reasons it seems clear

that Fortran should not be used to give information about the

file which is not needed by the Fortran program.

(e) The BCS proposals given above are both simple and

effective in providing new I/O facilities for Fortran. By

means of the "ERR=" parameter in the OPEN statement an enquiry

can be made as to whether an old file exists, or whether there

is sufficient space available for a scratch file. Ry the use

of OPEN and CLOSE statements different files may become

associated with the same unit number at different times during

execution. External names can be read in from the data and

used in the NAME parameter of the OPEN statement. By means

of CLOSE, devices may be unloaded and freed, or scratch space

may be released.

Colin Day.