Present :       Jackie Bettess       University College of Swansea

                S Brazier            GMW Computers

                M W Clark            Imperial College Comp Centre

                J Elkin              KBC Process Consultants Ltd

                W Flexner            Retired

                Joyce Graves         University of Nottingham

                D Holmes             Rolls Royce Ltd Bristol

                J Murchland          (Part-time acting Secretary)

                D Littlewood         NCC

                D M Vallance         University of Salford

                T L van Raalte       MoD (Complementary acting secretary)

                S Watkins            UMIST

                A Westlake           International Statistics Centre

                J D Wilson           University of Leicester (Chairman)


                F E Cox              Swifte Computer Systems Ltd

                M R Dolbear          B P International Ltd London

                D Everett            Computer Graphics, University of Leicester

                D Fordred            BBC

                S J Hague            NAg

                W S Hilder           National Children's Bureau

                R Iles               NAg

                Naresh Mooljee       Edinburgh Regional Comp. Centre

                L R Rice             Nat. Inst. Biol. Stds. and Control

1.      MINUTES OF PREVIOUS MEETING [5 December 1983]

        (i)   In 2(i) the submission made was for £607 (not £505)

        (ii)  In 3(i) the sentence "In future ... others" is a proposal and

              has not yet been decided.


(i)     Finance

        A letter has been received from the Vice-President (Specialists Groups)

indicating that the FSG is likely to get the budget of £607 requested.

        The Chairman has asked for support for regular attendance at the ISO

Fortran Experts meeting in Geneva. The amount involved would be about £1000

in alternate years. An encouraging reply had been given.

        The Treasurer has written to the former Treasurer in order to obtain

some form of a claim against which to make payment.

(ii)    "British Standard Method for Specifying Requirements for FORTRAN

        Language Processors"

        The working group has completed a draft which will go before OIS/5

for approval. A final draft is expected to be available from BSI shortly for

public comment.


(i)     The Specialists Group Board Meeting was held on 9 February. The

proposed policy of unbundling while in abeyance regarding the membership of

Specialists Groups is under consideration regarding the choice of documentation

which members will receive.

(ii)    The BCS is updating its list of book reviewers. Groups were asked to

propose a contact who will organise reviews. Will anyone interested in

reviewing or organising reviews give their names to the FSG Secretary (whose

address appears in the last minutes) in time for the AGM on 16 April.

(iii)   The BCS is considering the establishment of a pilot BT Gold Mailing

box scheme. Groups will be advised.


(i)     Anyone interested in attending this meeting must get in touch with

D Muxworthy at the Edinburgh Regional Computing Centre in order to have his

name officially approved by the BSI.

(ii)    Anyone who wants an issue to be raised at the meeting should inform

D Muxworthy or J D Wilson in writing as soon as possible.

5.      X3J3 PROGRESS

(i)     ANSI has not been accepting new proposals since November 1983, though

it is thought that this might not apply to minor modifications. The further

stages in the timetable are expected to be:

        Feb. 1985 : Publication of the proposals for the new standard

        Mid 1987  : Publication of the new standard after two years

                    consideration of public comment.

[A report on the February 1984 X3J3 meeting is appended.]

(ii)    There was some discussion on progress of the standard.

        (a) J Murchland said that there is a need for work to test the vali-

        dity of the standard. Vallance agreed but pointed out that such work

        needed substantial financial support.

        (b) J Murchland raised the question of the measurement of time in

        programs. He suggested that there should be standardisation outside

        Fortran to which Fortran conforms.

        (c) J Murchland considered that the need to extend libraries implies

        the need for standardised names.

        (d) J Murchland asked whether there is a guarantee that F77 programs

        can be run under 8X. Wilson expressed doubts but could not give a

        definitive answer.


(i)     D Muxworthy would like to hear from anyone who is interested in a

program for converting from nH to character string formats.

(ii)    Mike Nunn can supply copies of a first draft of a CCTA note on the NCC

Fortran validation scheme.

(iii)   J Murchland drew attention to the Annals of the History of Computing,

vol. 6 which is devoted to the history of Fortran.


The next meeting of the Group will be the AGM. It will be held on

Monday 16 April 1984 from 10.45 to 16.00 at BCS Headquarters. It will

include a report from the Geneva ISO meeting.

T L van Raalte (Treasurer/Acting


M Nunn (Secretary)

26 March 1984


To:         BCS and NAG

From:       John Reid

Date:       11 February 1984

Subject:    Report on X3J3 meeting at Austin, 6-10 February, 1984


[1] 89(7)KWH-1 An exception handling proposal

[2] 89(2)DTM/JAMS-1 Revised event handling improvements

[3] 89(6)JKR-1 Minor technical changes to the array intrinsics

[4] 89(6)JKR-4 Zero sized arrays and the data statement

[5] 88(6)AW-3 Array constructors: an enhancement

[6] 89(6)AM-1 Changes to the ALLOCATE mechanism

[7] 89(6)LJO-3 Array section selectors revisited

[8] 89(6)RRR-1 Block WHERE construct

[9] 89(9)JLS-2 Parameterized data types

[10] 89(9)JKR-2a Intrinsics for date and time

[11] 89(6)JKR-3a Changes to the IDENTIFY statement

[12] 89(11)JKR-5 Length of lines and statements in source form

[13] 88(11)JKR-11 On the significance of blanks and the underline character

[14] 89(9)LJO-2 Pointers revisited

l.      Summary

        The chairman sought to inject a sense of urgency into the

committee. Her aim is that at the February 1985 meeting the committee

should agree that S7 (or another document that replaces it) is

suitable for sending to the parent committee, X3, for release for

public comment. She therefore asked for firm plans from each subgroup

for proposals matching such a time frame and proposed to disallow any

technical proposals not included in these plans. I support her aim,

but am worried about the ban on other technical proposals especially

since no written list of subgroup proposals is available. It is

important to avoid wide-ranging new proposals which would have a major

impact on the language and require rewriting large amounts of S7, but

I believe that minor proposals should be allowed to be discussed while

the major effort is devoted to improving S7. Hopefully, common sense

will prevail.

2.      Rewriting S7

        Lawrie Schonfelder totally rewrote most of Chapter 4 of S7.

This concerns data types and is needed because of the inclusion of

derived data types in the language. It was accepted with minor

amendments (23-0). With Alan Wilson I am undertaking a total rewrite

of Chapter 14 (detailed specification of the intrinsics) and the parts

of Chapter 13 that this hinges upon. This is needed because the new

intrinsics are written in the Fortran 77 style which does not lead to

a clear description of functions that are much more complicated than

the Fortran 77 ones and does not define keywords for the arguments.

Our rewrite is not complete yet. We obtained useful comments from the

committee. The desirability of defining keywords for all arguments

was supported (23-3-4) and the overall approach was welcomed (34-0-0).

3.      Event handling

        There was a discussion as to whether event marks should

constitute a data type and a straw vote was unfavourable (2-14-10).

The problems are that event mark values are changed as side effects of

the execution of ordinary statements, and that assignments of event

marks cause side effects. It was suggested that the need for event

marks could even be avoided completely by attaching events directly to


        Kurt Hirchert brought a draft S7 chapter [1] on his exception

handling proposal before the committee and a straw vote approved it

(21-0-11). He recognized that it was written too hurriedly for it to

be ready for inclusion in S7. If this is accepted, it will be

desirable to drop the present event handling facilities or modify them

to exclude exceptions.

        While it is clear that the present event handling facilities

remain controversial, it was agreed that David Muxworthy's

modifications [2] were improvements and proposals 1,3,8,11,12,14,15,16

of [2] were approved (18-0,18-2,15-0). He did not move proposals

associated with event-marks as a data type.

4.      Kahan presentation

        Kahan gave a presentation on behalf of the IEEE floating-point

standardization committee. His requests were for

     i) the details of exceptions to be left to the manufacturer

    ii) compiler optimization to be performed only if it leaves

results unchanged to the last bit

   iii) for the precision of the arithmetic used for floating-point

subexpressions, to allow i) dominant mode, ii) widest precision and

iii) strict matching; and to provide a means of finding out which is

in use

    iv) put nothing in the standard about required precision and

range for elemental intrinsics such as SIN.

     v) avoid moving the evaluation of constant expressions to

compile time in case this means that no exception is raised at run

time when it should be

   vi) require the implementor to supply information about certain

undefined results.

5.      Array processing

        My minor changes [3] to the array intrinsics were approved.

They are

     i) extend array intrinsics to apply to derived data types, where

appropriate (22-0)

    ii) change the DIAGONAL intrinsic to require the diagonal

elements in a vector and have an optional fill argument to provide a

value for off-diagonal elements (24-0)

   iii) provide generic names for functions having only specific

names (23-0)

   iv) rename 'SHAPE' to 'RESHAPE' and 'EXTENT' to 'SHAPE' (18-1)

       My proposal [4] to allow zero-sized arrays in DATA statements

was accepted (21-0).

       Alan Wilson's suggestion [5] to allow rank one arrays within

array constructors was passed (20-0).

       Alex Marusak's proposal [6] to allow arrays to be reallocated

while preserving their data, was not accepted (4-8-17). Except in

rank one cases, reallocation is likely to require a copy anyway and it

was felt preferable to use a fresh allocate, a copy, and a free of the

old version. This also makes it clear what happens to virtual arrays

mapped into the allocated array (they need reidentifying).

       Linda O'Gara suggested [7] using square brackets for array

sections to avoid the confusion with character substrings, but this

was not liked (5-18-10) principally because of worries over hardware

that does not represent these characters.

       Rich Ragan's motion [8] to tidy up the description of the WHERE

block was passed (23-0). WHERE blocks may not be nested but were

described as if they can, with a maximum nesting level of one.

       My proposals on the IDENTIFY statement [11] were passed (20-4),

subject to minor changes. These proposals are

    i) to permit scalars and whole arrays to appear (i.e. provide

an aliasing facility)

   ii) to allow the parent to be an array of structures with array

components and index both levels of subscripts

  iii) establish that execution of an IDENTIFY statement sets up a

mapping from actual storage to a virtual array.

6.      GKS binding

        The GKS binding was discussed briefly. Concern was expressed

about the number of names imported into a user program.

7.      Parameterized data types

        Lawrie Schonfelder's proposals to use the keyword TYPE in place

of FORM and to allow attributes in derived data types ([9], proposals

A(i) and A(ii)) were passed (19-1 and 16-1). The previous problems

over optional specification of attributes were resolved by making

their specification non-optional, which is not a serious loss.

        There was some discussion as to whether the operators =, .EQ.

and .NE. should have default definitions and a straw vote eventually

favoured having default definitions and allowing them to be redefined

for derived data types only.

8.      Date and time

        After considerable amendment and discussion, my proposal [10]

for intrinsic subroutines to return the date and time were passed (21-6).

The principal changes were to specify that local time is

returned, permit GMT to be calculated and return impossibly large

negative numbers when there is no facility.

        A straw vote on a CPU-time intrinsic was favourable (23-6-5).

9.      Source form

        The committee discussed Peter Kirby's suggestion [12] that no

minimum required length for lines in free source form should be

specified. Subgroup 11 favoured raising the limit to 256. They did

not want no limit because then a compiler that only accepts lines of

(say) length 40 would still be standard-conforming. The committee

agreed that some number was necessary (24-4-4) but did not like 256

(8-2-19) nor any number greater than 132 (6-12-11).

        The committee also discussed Peter Kirby's suggestion [13] to

treat underscores as nulls within keywords, identifier names and

numeric constants. They did not like this within identifiers since it

might make two versions of the same name look very different (2-10-3)

but they were well disposed to the idea within numeric constants (8-2-5).

l0.     Pointers

Linda O'Gara led a discussion [14] on pointers. She felt that

Hoare's recursive data structures would not provide an adequate

replacement (see [14]) and this was confirmed in discussion. The

Seattle straw vote on syntax in favour of an extra symbol being needed

when the pointer is referenced (but not for referencing the pointee)

was confirmed (13-4-6). Concern was expressed about the wide effects

on the language that would arise from adoption of pointers. A vote of

l0-6-11 favoured continued work on the topic.