Present:   J L Dyke            - Huntingdon Research Centre

                   D J Holmes          - Rolls Royce Ltd, Bristol

                   R F Maddock         - IBM

                   Brian Meek          - Queen Elizabeth College, London

                   David Muxworthy     - University of Edinburgh

                   Keith Normington    - Coventry Polytechnic

                   Mike Nunn           - CCTA

                   T L Van Raalte      - MOD

                   Nick Saville        - Private Consultant

                   Lawrie Schonfelder  - Liverpool University

                   David Vallance      - University of Salford

                   John Wilson         - University of Leicester


                   Chairman            - John Wilson

                                         Computer Laboratory

                                         University of Leicester

                                         Leicester LE1 7RH

                                         phone 0533 554455

                                         ext 165

                   Secretary           - Mike Nunn


                                         Room 408

                                         Riverwalk House

                                         157 Millbank

                                         London SW1P 4RT

                   Treasurer           - T L Van Raalte

                                         Atomic Weapons Research Establishment



1. Minutes of Previous Meeting [26 September 1983]


        (i) In first paragraph of "Matters Arising"

                        "OSI/5" should read "OIS/5"

             The membership of OIS/5 subcommittee comprises:

                        D Muxworthy

                        B Meek

                        J Wilson

                        I D Hill

            with P A Clarke and A M Addyman as correspondent members.

       (ii) In appendix B paragraph 5.(x)

                "rather arguments" should read "rather than arguments"

2. Matters Arising

     (i)  Treasurer's Report

Our Group has to put in an annual bid for funds from

BCS and for the coming year we are making a submission

for £505. This has to cover such things as hire of

rooms and refreshments for meetings, the newsletter

mailing list and the Group's ANSI observer's fee.

The Treasurer is trying to find the best way to pay

money to cover expenses incurred by J Roberts-Jones when

he was Treasurer. Mr Roberts-Jones has been very

difficult to contact.

    (ii)  Membership of BCS FORTRAN Specialist Group

Accompanying these minutes is a membership renewal form for

our group. This MUST be filled in and returned to the

Secretary. Non-BCS members are reminded that there is

a £2 fee for membership of the Group which for the

current financial year must have been sent to our

Treasurer, Mr van Raalte by the end of March 1984.

Otherwise membership will automatically be deemed to

have lapsed.

   (iii)  ISO FORTRAN Meeting at CERN, Geneva.

The FORTRAN experts meeting next April at CERN has been

slightly reconstituted as an ISO working group

[ISO/TC97/SC5/WG9] and those attending should be

"accredited delegates". Presently the Convenor,

Jeanne Martin (X3J3 Secretary), is putting together a

formal membership list. Those interested in attending

from the UK are asked to write to David Muxworthy

(Edinburgh University) so that BSI can formally endorse

them as delegates. Please contact him before the end

of January. His address is:

        Program Library Unit

        University of Edinburgh

        18 Buccleuch Place

        Edinburgh EH3 9LN  phone O31 667 1081 ext2972

David also mentioned that there ought to be a UK FORTRAN

activity report for the CERN meeting. In the past he's

tried to summarise the BCS FORTRAN Group's reactions to

FORTRAN 8X at ISO meetings. In fact anyone who wants

any matters raised at CERN in relation to 8X should

write to our Chairman, John Wilson. The FORTRAN Inform-

ation Bulletin produced by ANSI X3J3 Committee summarises

the current state of 8X. John can supply those

interested with a copy for £2.

Brian Meek suggested that the ISO FORTRAN meeting should

be an explicit item on the agenda at our next meeting.

    (iv)  "British Standard Method of Specifying Requirements for

          FORTRAN Language Processors"

Brian Meek was anxious that the BSI FORTRAN proposal

should be referred to as "British Standard Method of

Specifying Requirements for FORTRAN Language Processors"

and not as "British Standard FORTRAN" which was

misleading. He was also very concerned about what

various people said regarding the proposal in his

absence at the October meeting. In order to

clarify the position Brian has written a letter to the

Group which forms appendix A to these minutes.

3. BCS Business

    (i)   At the 10 November meeting of the Specialist Groups

Board a motion to seek a Royal Charter for BCS was

passed by 27-1. At the same meeting it was decided

to "unbundle Groups". In future BCS members will

automatically have free membership of one Branch and one

Specialist Group but will be charged if they want to

belong to others.

   (ii)   New Specialist Groups - Electronic publishing

                                - CAD (resurrected)

4. X3J3 Progress

    (i)   A written summary has been received from John Reid (Harwell)

          on the X3J3 meeting in Seattle on 14-18 November 1983

          and is in appendix B.

   (ii)   Lawrie Schonfelder gave the Group the following verbal


X3J3 is about to switch modes - up to now they have been

working on lots of new material but things are now

reasonably complete so they are moving into editorial


A lot of time was spent on the FORTRAN Information

Bulletin to get it into a suitable form for submission

to X3. The S7 document itself is too big for publication

and also has a few holes. One body of opinion is that

S7 in trying to use a F77 type structure has imposed

too great a strain and that a further working document

S8 should be produced. However, it would be pretty

horrifying to attempt it at this late stage.

Instead a small task group has been asked to go away

and restructure S7 as well as they can.

          FORTRAN structures discussed included:

          Do loops                - some discussion on format

          Consistent functions    - a proposal from John Reid but

                                    the committee was not too happy

                                    with the idea

                                    [consistent functions have no

                                    side effects and depend completely

                                    on arguments]

           Array processing       - should additional intrinsic

                                    functions COMPRESS/EXPAND be


                                  - IDENTIFY statement was further nu

                                    discussed but problems with it

                                    not resolved

           generic statements     - removed

                                  - now provided by other means

           date/time              - intrinsic function for cpu time

                                    was considered but there is

                                    difficulty in deciding what is

                                    meant by cpu time

           event handling         - got rather a rough ride and this

                                    feature is in rather an unfinished


           I/O                    - a few clean up proposals

           bitstream I/O          - tentative proposal with

                                    unresolved problems including

                                    breaking lots of other FORTRAN


A draft of 8X for public comment is likely to be ready in 1986 and

the final version published in 1988.

5. Kernel Graphics

David Muxworthy reported that although the GKS Standard was still

going through the ISO processes it was essentially settled. It has

been published as British Standard 6390 and costs £26.

The present specification is only 2-D but a Working Group has been

asked by ISO to produce a 3-D extension by next June.

The proposed FORTRAN binding is up for public comment until March 1984

(see appendix C). Any comments should be sent to either David Muxworthy,

Jeanne Martin (X3J3 Secretary) or members of the ISO graphics


6. Any other Business


7. Date of Next Meeting

     (a)   The next meeting will take place on Monday 27 February at

           10.30 at BCS HQ, 13 Mansfield Street, London. In the

           afternoon Steve Hague (NAG) will give a talk on Toolpack.

     (b)   The AGM is due to take place on 16 April.

8. Filmshow "The history of FORTRAN"

Bob Maddock of IBM kindly brought along and showed a film on the

early development of FORTRAN. It was fascinating to hear members

of the original team that developed the language, including its

leader John Backus, talking about how it all happened, It all

started in 1953 as an IBM research project and amongst its design

aims was to produce a compiler that could produce the most

optimised programs possible. Anyone else who would like to get hold of

the film should contact Bob at IBM UK Labs Ltd, Hursley Park,

Winchester, SO21 2JN.

[The film is now available at the Computer History Museum.  For further

information and a link to the film see


9. Derived Data Types in FORTRAN

In the afternoon Lawrie Schonfelder, of Liverpool University gave

a talk on the proposed derived data types for the next FORTRAN

Standard. A synopsis follows and in appendix D is an excerpt from

the FORTRAN Information Bulletin which defines them.

Derived data types are types defined by the user as aggregates of

intrinsic type objects.

    (i)   Specification

              TYPE    type name [(param list)]

                      component field declaration

                      [component field declaration]....



               TYPE STOCK - ITEM

                    ID: INTEGER

                    DESC: CHARACTER (LEN=2O)

                    QUANTITY: INTEGER

                    PRICE: REAL (PRECISION=6)


   (ii)   Structure Declaration

          Names for derived data types may be declared similarly

          to those for objects of intrinsic type:

               TYPE (type-name [(param-list)]

                    name [(array-dec)][,name (array-dec)].....

               is an attribute oriented "type statement".

                    name [,name]......: TYPE(type-name[(Param-List)]

                                        [,attribute list]

               is an entity oriented "declare statement".

   (iii)   Attribute lists look like:

               attribute list    is attribute [,attribute]

               attribute          is DIMENSION (array-dec)

                                  or INITIAL (expr)

                                  or SAVE

                                  or IN    etc

A structure component can be referred to by qualifying the

structure name:

          Structure-name % component-field-name [(array-selector)]


             eg WORD % LENGTH

                LINE % CHARS (1:LINE % LENGTH)


          Structure is:

               MODULE mod-name

                     type and object declarations [PUBLIC and PRIVATE]

                     internal procedure definitions

                                                 [PUBLIC and PRIVATE]

                     external procedure definitions

                                                 [PUBLIC and PRIVATE]


                USE [/mad-name/] ONLY ([aocess-list])


                USE [/mod-name/] [ALL(rename-list)]

                                 [EXCEPT (name-list)]


These look like:

[INTERNAL] [RECURSIVE] [typ] FUNCTION fun (d-arg-list)

                             [RESULT(res)][OPERATOR (op=)]

            Similarly for SUBROUTINE PROCEDURES.

     (vii)  I/O is still a problem. At present components of a

            structure have to be written out one at a time. Using

            formatted I/O what will be needed is a user defined

            format specifier.

Mike Nunn (Secretary)

12 January 1984




COMPUTER UN|T                                                                                                                                       CAMPDEN HILL ROAD, W8 7AH

DIRECTOR BRIAN L.MEEK,M.Sc.                                                                                                                                                                         TELEPHONE: 01-937 5411

                                                                                                                                                                                                      TELEGRAMS: QUEENBETH.LONDON W8

Mr Mike Nunn                                          5 December 1983

CCTA, Room 408

157-161 Millbank

London SWlP 4RT

Dear Mike

BCS Fortran Specialist Group

I was very concerned at the minute of the meeting of 26 October 1983

concerning the proposed British Standard 'Method of specifying

requirements for Fortran language processors' since the discussion it

reports displays a profound misunderstanding of the nature of the

proposed standard. Could these notes therefore please be appended to

the next minutes?

The proposed standard is an indirect standard, not a direct one. It is

not a 'British Standard Fortran', and perhaps the first thing to do is

to change the heading in future to 'British standard for specifying

Fortran processors'. However, even then the proposed standard does not

specify a 'standard conforming processor' which Fortran implementors

must follow. What it does do is define a standard way in which the user

of a Fortran system can specify what properties he wants from that

system. To be sure, one possible use of the proposed standard is to

produce a very tight specification for a Fortran system, which would

place many specific requirements on the implementor. However, a

standard can be used in many ways. At the other extreme, an individual

could use it as a checklist, which would draw his attention to features

of implementations that he has not thought of, or has taken for granted,

without his ever producing an explicit specification (whether for the

production of a processor, or for the supply of a processor, or for

testing a processor). Even if he produces a specification, he could use

it as a set of guidelines without ever needing to claim that the

specification actually conforms to the standard. Yet even at this

minimal level of picking out the individual elements of importance to

the particular user, the proposed standard will be of value.

Nevertheless it is hoped that users in general will base their

specifications and evaluations for Fortran processors on the standard as

a whole and not just on a selection of elements, since the standard is

designed to ensure a much higher level of portability of Fortran 77

programs between implementations, and much greater predictability of

what will happen when a program runs, than the ANSI standard on its own

attempts to guarantee. However, it is still the user who determines

whether the processor meets the specification, not the standard.

[new page]

If I may comment on the particular points made in the minutes, I think

it is very unfair to ask us to show 'concretely' how this project will

improve the ANSI standard, when its content is still under discussion.

However, there are many specific examples of problems caused by

deficiencies of the ANSI standard, and anyone who is aware of them or

thinks they are not important is living either in a dream world or in a

very sheltered  environment. As for the reasons the ANSI standard leaves

things undefined, the group is very well aware of them and are taking

them into account. As for casting the language in 'concrete' (clearly a

favourite word!), the proposed standard is not about the language at

all, but about implementations. It is accepted that people will want to

'sell' implementations in the traditional way, on 'features' rather than

on quality. Clearly by the time it is published, there will be things

coming out which will be in 8X, or people think will be in 8X, or people

wish to try to ensure will be 8X. The proposed standard would not

preclude them.  However a processor specification produced in

accordance with the standard would require them to be flagged as

non-standard; require a 'standard mode' of operation in which they

would be rejected; require them to be documented, and defined in the

same way as in the ANSI standard, and if possible expanded into

conforming Fortran 77 code.

As for U.S. companies 'not being interested', if we take that attitude

we might as well give up any attempt to influence ANSI X3J3 or anyone.

It is in fact very unfair to the many in the U.S.A. who do care what

people abroad say. I believe responsible implementors do exist and will

welcome the guidance this proposed standard will give, and that this is

true regardless of their nationality.

Our aim in this project is to enhance the value of the ANSI standard and

promote its use. An important element is to demonstrate that it can be

done at all, and without causing horrendous problems for implementors.

In any case, a 'permissive' approach to standard ought to allow to those

who wish it, the possibility of foregoing some of the variability the

permissiveness allows!

I hope that in future people will try to understand our intentions, and

at least wait to see what we produce, instead of prejudging the issue.

Yours sincerely

B. L. Meek


To:        NAG, BCS, DAP unit, etc.

From:      John Reid

Date:      22nd November 1983

Subject:   Report on Seattle meeting, 14-18 November 1983


[1]  88(*)JLW-1a     Fortran Information Bulletin

[2]  87(11)JKR-6     Removal of a restriction concerning

                     internal files

[3]  88(11)JKR-9     On the character set

[4]  88(*)JKR-10     On the choice of built-in names

[5]  88(11)JKR-11    On the significance of blanks

[6]  88(11)JKR-12    Enhanced I/O operations to computer


[7]  88(8)JKR-2a     Consistent functions

[8]  88(6)RAH-1      Deletion of ALT

[9]  88(6)AW-1       Compress/expand

[10] 88(6)MS-1       Assumed-shape array

[11] 88(6)MS-2       Array names in dimension bound expressions

[12] 88(6)JKR-3a     Deletion of OTHERWISE

[13] 88(6/9)JKR-5a   Changes to IDENTIFY

[14] 88(9)JLS-2      Parameterized data types

[15] 87(*)JKR-5      Intrinsics for date and time

[16] 87(7)KWH-1      An exception handling control structure

[17] 88(7)KWH-1      An exception handling control structure

[18] 88(11)JHM-1     SG11 clean-up proposals

[19] 88(11)NHC-1     Unformatted binary i/o

1.      Summary

        The only major proposal passed at this meeting was the formal

acceptance (22-0) of Jerry Wagener's Fortran Information Bulletin. A

fair amount of committee time was spent considering detailed changes.

        A large number of editorial changes were made to S7, which

will mean that the next version is a bit cleaner . However it is still

not a satisfactory document. A small "task group" was set up to

consider how it might be improved or replaced.

Most of the full committee time was spent considering suggestions

not yet ready for formal votes. Four full afternoons were spent in


2.      Block DO syntax

        A four-way straw-vote on syntax went thus:

DO...REPEAT :8, DO...END_DO :9, LOOP...END_LOOP :4, undecided :1.

Using : in DO was favoured (1O-6-6) and another 4-way vote went this

DO(N TIMES) :8, drop (N TIMES) :2, DO(1:N) :8, undecided :2.

3.      Consistent functions

        I discussed my proposal [7] on consistent functions with subgroup

7/8 who in turn asked me to speak to the full committee. The subgroup

pointed out that Alan Clarke was asking for consistency throughout

program execution, that I was asking for consistency very locally

(during a single reference or set.of FORALL references) and that other

"lifetimes" were desirable, e.g. so that a compiler on asynchronous

hardware could execute these statements in parallel

                                A=FUN (B)


                                E=FUN (F)

The full committee was concerned about error handling, or even the

simple passing back of an error flag. Straw votes were not in favour

of Alan Clarke's idea (6-11-15) or mine (4-10-16) and little better

disposed to an intermediate lifetime (8-3-22). Given that a

satisfactory definition of consistency can be agreed, the committee

wanted (14-3-13) a suitable assertion statement.

4.      Array processing

        The proposal [8] to delete ALT, whose functionality is now

available via array constructors, passed 22-0. The proposal for the

new intrinsics COMPRESS and EXPAND [9] was favoured (17-1-17) but

deletion of PACK and UNPACK was not (0-12-24). It was agreed that a

major rewrite of Chapter 14 of S7 (on intrinsic functions) was needed

with a proforma description of each (37-0-1) and that all intrinsics

should continue to be included (32-1-4). Alan Wilson and I were

charged with the task of preparing sample rewrites for the next

meeting. The tidying-up proposals [10] and [11] were passed by 17-5

and 22-1.

        In the subgroup, my proposal [12] to delete OTHERWISE

failed (2-5-0), but a complete rewrite of the description of WHERE

blocks in S7 was agreed. On the IDENTIFY, my suggestion [13] to

extend it to scalars as an aliasing mechanism was accepted by the full

committee (19-2-11), my suggestion to extend it to structures was

accepted by the subgroup (4-0-3) and my suggestions to make an

identification cease when the parent is reallocated or reidentified

were accepted (21-0-9) and (11-8-14).

        There was total disagreement in the subgroup over many-one

mappings in vector-valued subscripts and IDENTIFY statements. There

was also disagreement over restricting the number of IDENTIFY

statements within which a virtual array name may appear. I will

prepare a new proposal excluding these issues.

5.      Parameterized data types

        Lawrie Schonfelder's proposal [14] on derived data types (which

for example, would allow a derived type MATRIX to be parameterized by

precision and order) was accepted in principle (18-3-13) but withdrawn

for detailed changes.

        A proposal to remove the GENERIC statement was passed 25-0. The

functionality is now provided by procedure overloading.

6.      Date and time

        There was broad agreement on the need for date and time

intrinsics but my proposal [15] which follows an existing standard

slavishly was not liked (9-17-7). I will prepare a fresh proposal

that returns the same information and makes use of the enhanced

features in F.8x. I asked for a discussion on the need for a CPU time

intrinsic and it was clear that this has much less consensus (straw

vote on the principle: 16-13-7) so I propose to work on date and time

only for the present.

7.      Event-handling

        The present event-handling features are not progressing well.

Detailed changes were not welcomed while the facility does not yet

provide any useful functionality. Hirchert's alternative ([16],[17])

is better understood and the static connection to the handler is

preferred strongly by some committee members. Straw votes (just)

liked ENABLE as a control structure (10-8-15) and as an exception

mechanism (12-8-13).

8.      Pointers

        Linda O'Gara presented a tutorial on pointers and sentiment

appeared to be largely in favour. It was felt that if pointers were

adopted they should be permitted to point to arrays (28-0-5) and that

ALLOCATE and FREE would no longer be needed (15-6-14). For syntax,

three alternatives were considered, illustrated by the case where A

and B point to rank one arrays:

possible pointer syntax

The three statements are assignment of the pointer, assignment of an

element of the array and assignment of the whole array. A straw vote

(17-10-1-6) favoured the first alternative.

9.      I/O Proposals

        Some minor clean-up proposals (A,C,D,E,F and I of [18])

were passed. There was much discussion of proposal E3, the problem

being that one may not want padding, e.g. when reading from a tape

with fixed record lengths. Eventually a vote

(13-5-7) favoured functionality of padding under the control of an

additional specifier in the READ statement.

        Unformatted binary i/o [19] was discussed without reaching any

firm conclusions, through there was sentiment in favour of stream i/o.

Note that BIT type is not in the language.


GKS interface to Fortran 77 title page

The remaining 15 pages of this document have not been digitized.


2.4 Derived Data Types

The structure of a derived data type is a programmer-defined aggregation of

fields, each field being a data element of primitive type (or another derived

data type). The aggregation pattern may be fixed or variant (that is, par-

tially dependent on one of the prior fields). A derived data type is defined

with a TYPE construct; variables of this type may be declared in the normal

manner. Intrinsic operations on derived data objects are assignment, equality

comparison, input/output, and use as procedure arguments. These intrinsic

operations may be augmented with additional programmer-defined operations.

The structure qualification symbol (for referencing a component of a struc~

tured object) is the percent sign (%).

structure-definition  is   TYPE type-name



                           END TYPE [type-name]

variant-case-block    is   SELECT CASE (tag-field-name)

                                  [ CASE case-selector

                                        [ field~dec1aration]... ]...

                                  [ variant-case-block ]

                           END SELECT

field~declaration     is   type-declaration

                      or   declare-statement

component-reference   is   structured-object-name % field-name

type-constructor      is   type-name (expr[,expr]...)

type-constant         is   type-name (constant-expr[,constant-expr]...)

Notes and Examples -

       ~ Functions may return derived data type values.

       - The following definition of PLOT_OBJECT defines a data structure

         made up of two fields of type real (the location in two-space),

         one field indicating the nature of the object, and finally the

         object data itself. In this case the object may be either a point

         symbol or a line segment.

                type PLOT_OBJECT

                   X0,Y0: real                        ! object location

                   CODE:  integer                ! type of object

                          select case (CODE)

                                 case (1); SYMBOL: character ! point symbol

                                 case (2);  X1,Yl: real      ! line segment

                          end select

                end type PLOT_OBJECT

        Let P,Q: type (PLOT_OBJECT) declare two variables P and Q.

        Then the following expressions are examples of valid operations:

                ( P%X0 + Q%X0 ) / 2               ! mid-point of P and Q along X

                if (P%CODE.eq.Q%CODE) then        ! compare P and Q CODE fields

                P = PLOT_OBJECT(0.,0.,1,"+")      ! give P an initial value

                read *, Q                         ! input value of Q