ON 9 DECEMBER 1985

Present:-       J L Dyke           - HRC

                Miles Ellis        - Oxford University

                Bill Flexner       - Retired

                Mike Geary         - NAG

                D T Griffiths      - SSF

                David Harris       - Alpha Comp Ltd

                J P Holland        - SS(E)L

                Carol Hewlett      - LSE

                Chris Lazou        - ULCC

                Karen Ma           - British Telecom

                Brian Meek         - King's College, London

                K Normington       - Coventry Polytechnic

                Mike Nunn          - CCTA

                E G Reilly         - B MT

                T Van Raalte       - MOD (PE)

                N R Saville        - Private Consultant

                John Steel         - QMC

                David Vallance     - Salford University

                Steve Watkins      - UMIST

                John Wilson        - Leicester University

                John Young         - MOD (PE)


Chairman:          John Wilson

                   Computer Centre

                   University of Leicester

                   LEICESTER LE1 7RH

                   Tel: 0533 554455 ext 9137

Vice-Chairman:     Keith Normington

                   Computer Centre

                   Coventry (Lanchester) Polytechnic

                   COVENTRY CV1 5FB

Secretary:         Mike Nunn


                   Riverwalk House

                   157/161 Millbank

                   LONDON SWlP 4RT

Treasurer:         John Dyke

                   Huntingdon Research Centre

                   HUNTINGDON PEl8 6ES

l.      Apologies for Absence

Apologies were received from David Muxworthy, Dennis Parkinson,

John Reid and Lawrie Schonfelder.

2.      Minutes of Last Meeting [16 September 1985]

        2.l. The Chairman, who was abroad at the time of the last

        meeting, expressed his thanks to the Vice-Chairman,

        Keith Normington, for deputising for him.

        2.2. Corrections:-

        Page 1 "Mike Ellis" should be "Miles Ellis."

        Page 3 "BSC Study" should be "BCS Study."

        Page 5 "Chris Laxou, believed Frotran" should be

               "Chris Lazou, believed Fortran."

3.      Matters Arising

        3.1. Draft British Standard "Method for Specifying Requirements

        for Fortran Language Processors"

        Following our September meeting, the Secretary had written

        on behalf of the Fortran Specialist Group expressing

        dissatisfaction with the limited opportunity for members

        to comment on the new draft. The reply received from the

        Secretary of the BSI OIS/5 Committee was discussed, but was

        generally considered to miss the point on some of our complaints.

        As a member of OIS/5, Brian Meek put forward the following views:-

           (i)      Due to limited resources, BSI staff are only

                    announcing that new Standards are available

                    for public comment via "BSI News."

           (ii)     Those OIS/5 members who also attend our Group

                    did not know that the draft had been released

                    for public comment (it appeared during the

                    holiday period) and so could not let us know.

                    It had been delayed at BSI HQ.

           (iii)    He thought it was still not too late for comments

                    to be considered. They should be passed direct

                    to David Muxworthy, CAST, Edinburgh University,

                    l8 Buccleuch Place, Edinburgh, EH8 9LN.

        3.2. BCS Standards Meetings

        A meeting of representatives of the different BCS Specialist

        Groups was taking place on December l6 to appoint nominees

        for the National Computer Users Forum (NCUS) and also determine

        a more coherent BCS policy on language standards than in the past.

        On February 28 there will be a BCS meeting open to other

        members to discuss why standards matter, the activities of BSI

        and BCS attitude to standards.

        Brian Meek felt that all Specialist Groups should be aware of,

        and participate in, standards activities. In the case of the

        Fortran Group we were already doing so - even without BCS funding!

        He also pointed out that the BSI Fortran panel will be reconstituted

        to provide the official UK view on "Fortran 8X" to X3J3 and will

        expect the BCS Fortran Specialist Group to submit a response.

        [Therefore all members of this Group are invited to send

        comments to the Secretary for discussion and possible endorsement

        by the whole Group as input to BSI and X3J3. This in no way

        precludes individuals from sending comments direct to X3J3 who -

        by the constitution must consider and respond to all comments


        The release of the final "8X" draft for public comment had

        been slightly delayed and it was not quite clear when this

        would now be. However, it is the intention of your Committee

        to organise another "FORTRAN FORUM" to discuss the draft soon

        after it is released, probably early in 1987.

        3.3. Letter from Gregory Aharonian - "Lets Kill Future Fortrans"

        There was a lively discussion provoked by the letter received

        from Gregory Aharonian in Massachusetts who wanted to kill off

        Fortran. Some of the views expressed by members were:-

        Nick Saville     -      APL was dramatically inefficient and also


                         -      C allowed users to do very dangerous things;

                         -      Ada was unlikely to supersede Fortran;

                         -      most of the languages quoted were far less

                                efficient than Fortran;

                         -      on first sight of the limited I/O in Pascal

                                he was quite shocked.

        Keith Normington -      Fortran had a certain style of its own

                                and had the advantage of not trying to do too

                                clever things;

                         -      C by contrast had the disadvantage of being

                                for clever programmers;

                         -      we should tell Mr Aharonian that we had

                                considered his letter, but it was not feasible

                                just to abandon Fortran and legislate it out

                                of existence;

                         -      it was becoming fashionable in the academic

                                community to 'knock' Fortran.

        Chris Lazou      -      Most scientific work had always and would

                                continue to be written in Fortran;

                         -      Fortran had masses of software available

                                which was not the case with most other languages

                         -      85% of users at his own site (ULCC) use Fortran;

                         -      Fortran would continue until there was a

                                programming revolution.

        A letter had been received form Professor Dennis Parkinson (QMC)

        challenging many of the assertions in G Aharonian's letter (see

        appendix A).

4.      BCS Business

        4.1.   The Treasurer had asked BCS for a budget of £500 for

        the Fortran Group for 1986/7. There were suggestions that

        we should ask for more.

        4.2.   A letter had been received from the BCS Newcastle Branch

        (see appendix B) announcing a one day conference in May and

        seeking representatives from Specialist Groups to give presentations.

        The Chairman said that he understood that David Muxworthy would

        give a talk on behalf of the Fortran Group.

        4.3.   At a recent meeting of the BCS Specialist Groups Board

        a uniform system for sending out mail to Group members was


5.        Fortran Forum

        5.1.   John Reid (Harwell) who regularly attends X3J3 meetings

        said that the Chairman, Jeanne Adams, was not optimistic now

        that the draft "8X" Standard would be released for public

        comment before the end of 1986. Therefore it would be sensible

        to have our Forum soon after that happened, i.e. probably early 1987.

        5.2.   Chris Lazou, Chief Organiser of "Fortran Forum 85"

        had just received the accounts from BCS Conference Section and

        they showed that the event had produced a profit of £1659 for

        the Group. The Treasurer would open a deposit interest bearing

        account for the money which would be used to help set up the

        next "Forum". Chris Lazou believed that even though there would

        be no "Forum" in 1986, we should organise some other event to

        keep up the momentum which "Fortran Forum 85" had generated.

6.      X3J3 Progress

        6.1.  None of the regular UK attendees of X3J3 meetings was

        present on this occasion, but John Reid had submitted a written

        report (see appendix C). The main thrust of the latest meeting

        at Tulsa in November, ha been that it was decided that the

        draft standard was not yet ready for the postal ballot of X3

        members which would be needed before it could be released for

        public comment. Most of the work was in trying to clean up

        details rather than introduce new features. The Chairman read

        out the key features of John's report for the benefit of those

        attending. [Since the meeting John has kindly provided a

        report on the subsequent X3J3 meeting at Sunnyvale in January -

        see appendix D].

7.      Any Other Business

        7.l.  NATLAS - National Testing Lab (NPL based) has been set

        up as a Group to devise standard testing methods for proving


        7.2.  After some discussion the Group decided that there

        should be a regional meeting during the coming year. It

        was decided that Birmingham or Coventry was the best choice

        for this and it was allocated for the September meeting.

        7.3.  It was suggested that it would be interesting for the

        Group to visit a site of particular interest and meet its

        Fortran users on the day of a future meeting. It was agreed

        that the Secretary would approach European Weather Centre at

        Bracknell to see if they could arrange a tour for the Group

        together with the opportunity to talk with their Fortran

        users. It was hoped that this could be set up for June.

8.      Date of Next Meeting

The next meeting of the Group would take place at 10.45 am on

Monday l7 March at BCS HQ, 13 Mansfield Street, London. It would

include the AGM. In the afternoon we would have three individual

speakers talking about floating point accuracy and numerical precision

in Fortran. They would be Mick Pont (NAG), Chris Cartledge (Salford

University) and Lawrie Schonfelder (Liverpool University).

9.      Talk "Using DEC Computers in the Field of Dynamic Simulation"

In the afternoon David Harris of Alpha Comp Ltd gave a talk on the

use of DEC computers in the field of dynamic simulation. A summary of

this appears in appendix E.

Mike Nunn


February 1986


QMC arms


                                                                                  UNIVERSITY OF LONDON

DAP SUPPORT UNIT                                                                                       MILE END ROAD

COMPUTER CENTRE                                                                                     LONDON E1 4NS

Director J P Brandon M Sc                                                                                              Tel  01-980 4811

Head of Unit Professor D Parkinson

2 December 1985

Mr M Nunn


Riverside Walk

157 Millbank

London SW1P 4RT

Dear Mike,

You asked for comments on the Aharonian note - I am sure that it will

produce heated comments from the FORTRAN group - enclosed, please find

my own reactions.


Yours sincerely,

Professor Dennis Parkinson

Head - DAP Support Unit

P.S. Unfortunately I cannot attend the 9 December meeting owing to other



c.c.    J Steel

        H Liddell

        A Wilson



  DAP Support Unit

 Queen Mary College

University of London

Gregory Aharonian's paper "Let's Kill Future Fortrans" is yet

another salvo in the computer language war. A basic premise of

the paper is that FORTRAN can be killed by actions of committees.

FORTRAN will only die as the result of market forces, that is

when no manufacturers see sufficient market demand to justify the

provision of FORTRAN compilers.

The cessation of activities by ISO/ANSI in developing new

standards would probably be welcomed by 75% of the FORTRAN user

community who like the rest of the community, do not really like

change. Most of the FORTRAN community would be happy to stay with

a fixed language with its existing compilers etc. FORTRAN would

then only die out by a combination of:

        a) Retirement of current programmer base

        b) Lack of recruitment into the FORTRAN users community,


        c) Non-implementation of FORTRAN compilers on new computer

           hardware systems.

Currently, no computer manufacturer who wishes to sell products to

the scientific/engineering market dare not offer a FORTRAN


Demand for FORTRAN may wane if there are available alternative V-

languages which:

        a) are capable of producing programs of better, or

           comparable efficiency to FORTRAN,

        b) Offer a sizeable increase in programmer productivity

           relative to FORTRAN, and

        c) are capable of handling both large and small programs

           as well as FORTRAN.

The majority of the discussions of the relative merits of

languages, FORTRAN-PASCAL-C-BASIC etc. are not very constructive.

For small programs the best language is that which the User feels

most at home with, which is probably the first language they

learnt. Each language has some area of application in which it is

better than the others, but it is a naive commentator who would

claim that one language is best for all types of applications.

If the standards community want to kill FORTRAN then they should

proceed as follows:

        i)      Introduce updates to the standards more frequently,

        ii)     Ensure that the new standards almost incorporate

                the last one as a subset

        iii)    Encourage manufacturers to add further extensions to

                the language e.g. BLAS, but do not actually

                incorporate these in the standard, and

        iv)     Ignore the fact that programming languages are

                first and foremost tools to allow users to

                solve problems and spend so much effort on making

                the tool look pretty, that the sharpness of its

                cutting edge is damaged.

Parallel Constructs

Aharonian does not see the need for extending FORTRAN to include

parallel constructs suggesting that APL is used. This suggestion

seems somewhat at odds with the suggestion that for other

operations, C is the language to which the FORTRAN community

should switch. Is the suggestion that C and APL should be somehow


There is a touching faith in the ability of programs such as

Parafrase to bring out parallelism in existing programs. Tools

such as Parafrase, do provide a part solution to the "dusty

FORTRAN deck" problem, but to suggest that their existence is a

reason not to provide parallel language constructs is ridiculous.

At a recent presentation of the array extensions to FORTRAN, I sat

alongside a veteran FORTRAN programmer who totally misunderstood

the point of it all, but just kept muttering, "I can do all that

with a DO loop!". Indeed you can, unfortunately (?) do almost

anything you want with FORTRAN - it's just often complicated.

Consider the following, not untypical, task which arises in

problem areas such as image processing and solution of partial

differential equations. Given an array of variables

Xij i = 1...n, j = 1...m, compute a new array

Yij i = 1...n, J = 1...m

such that Yij = Xi-1,j + Xi+1,j + Xi,j+1 + Yi,j-1

where        X0,j ≣ Xn,j   Xi,0 ≣ Xi,m                i = 1...n

             Xn+1,j ≣ Xi,j Xj,m+1 ≣ Xi,1              j = 1...m

In non array FORTRAN this problem could be programmed as follows:

        REAL INTEGER X(N,M),Y(N,M)

        INTEGER N,M,I,J




        DO 10 I = 2, N-1

        DO 1O J = 2, M-1

        Y(I,J) = X(I-1,J)+X(I+1,J)+X(I,J-1)+X(I,J+1)

 1O        CONTINUE




        DO 20 I = 2, N-1



 2O        CONTINUE




        DO 30 J = 2,M-1



3O        CONTINUE




        Y(1,1) = X(N,1) + X(2,1) + X(1,2) + X(1,M)

        Y(1,M) = X(N,M) + X(2,M) + X(1,1) + X(1,M-1)

        Y(N,1) = X(N-1,1) + X(1,1) + X(N,2) + X(N,M)

        Y(N,M) = X(N-1,M) + X(1,M) + X(N,1) + X(N,M-1)

This is difficult to do accurately! Indeed, I expect that some

eagle eyed reader may well discover an error (I made 6 corrections

to the first draft!).

The array extension in FORTRAN 8X - use the shift functions and

reduce the coding complexity to:



Y = CSHIFT(X,-1,1)+CSHIFT(X,1,1)+CSHIFT(X,2,1)+CSHIFT(X,-2,1)

The reader may think that I have cheated in picking a special

example but in reality I have been kind to the Fortran example.

In practical examples the probability is that the fragment would

be part of an iteration scheme. The programmer would want the

values of X to be overwritten by the new iterates Y. In this case

the 8X FORTRAN would simplify to:




The syntax of the CSHIFT functions is not pretty but the decrease

in programming complexity is spectacular. If the reader still

doubts the advantages they should modify the requirement to

include the restriction that the iteration should only be

performed if Xij is greater than say 2.0.

In 8X FORTRAN the code simply becomes:


The coding of this in FORTRAN 77, C, PASCAL, LISP or even APL is

left as an exercise for masochists.


FORTRAN-77 is not beautiful - but neither is C, PASCAL, ADA etc.

They are all low level languages requiring the user to waste much

effort in specifying irrelevant information. The purpose of a

computer language is to enable programmers to create programs

which are correct, maintainable and efficient.

Modern economics also requires that the resulting programs are

produced efficiently and are transportable. Papers such as that

of Aharonian which suggest that these ends can be achieved simply

by abandoning, say, FORTRAN for C are not helpful.

Two possible futures for FORTRAN can be predicted.

1)      Evolutionary - a gradual change 88-99 etc, which will

        evolve the language in such a fashion that eventually

        it becomes just a regional dialect of a widespread


2)      Extinction - due to lack of enthusiasm of the younger

        generation in following the habits of their predecessors.

        If we try to draw an analogy with spoken languages, we

        see that this can be a long drawn out process. Attempts

        by authorities to stamp out languages such as lrish,

        Welsh, Cornish etc. have not been successful.

The idea that we can change everyone to speaking some

theoretically better language (Esperanto?) appears to be pure,

wishful thinking.


The British Computer Society        BCS logo


Mr. R.S. Burgess

Chairman, Newcastle and District Branch

Newcastle upon Tyne Polytechnic

School of Computing and Informatics

Northumberland Building

Northumberland Road


Dear Mr. Nunn                                               15 November 1985

Proposed One-Day Conference in Newcastle

Speakers from the BCS Specialist Groups

I am writing to you as Secretary of one of the British Computer Society's

Specialist Groups. The committee of the Newcastle Branch of the British

Computer Society is proposing to organise a one-day conference with

speakers from the Society's specialist groups for members of the

Society in the NE of England.

One of the criticisms made of the Society's activities, by members in the

NE, is that the vast majority of the specialist groups are based in the

London area, and it is difficult and expensive for them to attend

their meetings. This proposed conference is an attempt to partially answer

that criticism by bringing some of the specialist groups up to the NE.

The tentative date suggested for the conference is Friday, 30th May, from

9.30 am to 4.00 pm. It is proposed to organise two parallel sessions

involving 8 different presentations in all, each presentation lasting about

1 hour 15 minutes (including time for questions and discussion).

The topic for each presentation at the proposed conference would be left

to the individual speaker providing that firstly, it related to specialism

of the specialist group he/she was representing and secondly, it was a

topic likely to be attractive to a significant number of members in the

region. It is also proposed to charge a minimum conference fee to attendees

who are members of the Society, enough to cover hire of accommodation,

visiting speakers' expenses and refreshments. This means that we do not

intend to offer visiting speakers a fee!

I do hope that your specialist group will feel able to contribute one

speaker for such a conference. I would appreciate the early consideration

of this proposal by yourself and your group and an early indication as to

whether your group would be willing to provide a speaker for the proposed


Yours sincerely

R.S. Burgess

Chairman, Newcastle and District Branch

copy to your Chairman


To:       BCS, NAG, FORTEC, etc.

From:     John Reid

Date:     16 November 1985

Subject:  Report on X3J3 meeting at Tulsa, 11-l5 November 1985

Note:     This is a personal report of the meeting and in no

          sense does it constitute an official record of it.

References:  [1] 97(*)JKR-2 Deletion of vector-valued sections.

             [2] 97(*)ALM-1 RANGE proposal

             [3] 97(l4)JKR-9 Conformance

l.      Summary

        Once again the main thrust of the meeting was detailed work on

the draft standard, S8. The editorial subgroup met for three days

before the meeting. A number of detailed proposals needed for the

standard, were passed. I will not describe them here. At the end of

the meeting the chairman asked whether the document was ready for a

postal ballot of X3J3 and the committee thought not (3-29-l). It

still needs a lot of polishing, but the committee is quite optimistic

(20-3-11) that it may be ready after the January meeting. If this is

so, the chairman envisages two more        meetings processing "no" votes and

forwarding the document to X3 next summer.

        A major proposal, ranging of arrays, was passed (see section 10)

without much dissension. However there was considerable discussion of

result typing (section 4) and array argument compatibility (section

5), both of which were resolved, and of the combinatorial explosion

that passed-on real attributes can cause (section 3), which looks as

if it may be resolved at the next meeting. The chairman is trying

hard to limit discussion to problems associated with features that

have been passed, rather than making changes or additions.

2.      Deletion of vector-valued sections

        I proposed [l] the deletion of vector-valued sections and their

replacement by GATHER and SCATTER intrinsics. This was on behalf of

the task group set up in Urbana to explore reducing the size of the

language. My proposal failed last year when I moved it as a personal

proposal and it failed this time too (7-6-15, l0-11-5, 6-14). The

counter arguments centred on the greater clumsiness of the use of

intrinsics and the problem that the equivalent of




which will not be a valid assignment if the elements of A that are not

selected are undefined.

3.      Passed-on precision

        It was decided (18-7) to remove the interpretation that when

more than one dummy argument is declared with passed-on precision in

the same statement, they all have the same precision. This rule is

unnatural and insufficiently general to link real and complex

arguments. The intention was to move another proposal that would

provide an alternative linking facility, but the syntax proposed was

not liked. There was much concern at the possible "combinatorial

explosion" if there are several arguments with independent passed-on

precisions (if there are n arguments and 3 precisions, 3n versions are

involved). Carl Burch proposed the ruthless cure of interpreting all

passed-on precisions as being identical, but did not move it because

he felt that it was too inflexible. George Paul suggested using the

CASE syntax to enumerate the versions wanted. This appears to meet

the requirements, and Geoff Millard and I will prepare a proposal for

the next meeting.

        There was some question as to whether the committee wishes to

retain passed-on precision, but a straw vote on deletion was negative


4.      Result typing

        There was much debate over the syntax for recursive functions.

The obvious extension of Fortran 77 may lead to an ambiguity for a

recursive array-valued function. About eight alternatives were

considered, all of which had one disadvantage or another. The rules

in S6 work, but were not correctly transcribed to S7. They provide a

RESULT clause to rename the result and do not permit the new name to

be typed. Eventually the argument "if it ain't broke, don't fix it"

seemed to win the day and the S6 rule was reaffirmed (l8-7).

5.      Array argument compatibility

        I proposed requiring an explicit interface when calling

procedures with assumed-shape dummy arguments. This will permit an

implementation to keep all other kinds of dummy arrays contiguous,

thereby allowing calls to object modules (perhaps written in another

language) that require this. Implementations that use a "dopevector"

convention do not need the restriction, but it is mild. I hope that

libraries will make their interfaces explicit, anyway, so that calls

to library routines are checked by the system as for intrinsics at

present. After much debate, including a three-hour evening session,

the proposal passed (14-12).

6.      Conversion none

        The Bonn ISO meeting requested a CONVERSION NONE declaration,

which would mean that no automatic intrinsic type conversion takes

place within expressions or across assignments. The idea was received

sympathetically (20-4-9) and a subgroup was asked to look at it


7.      Deprecation of automatic implicit typing

       I proposed the deprecation of automatic implicit typing so that

in the long term the safer IMPLICIT NONE would become the default, but

this did not pass (6-18).

8.      Deprecation of real and double precision DO indices

        My proposal to deprecate real and double precision DO indices

passed (17-3).

9.      Input-output proposals

        Jim Matheny's proposal to allow OPEN for an internal file was

accepted (22-0).

        His long-standing proposal for PROMPT= on read statements to

terminals passed (16-6).

l0.     Ranged arrays

        Alex Marusak's proposal [2] on ranging arrays passed (19-5).

This has been wanted by the array subgroup for at least three years,

but no formal proposal was made ahead of last year's deadline for new

material. This proposal includes a RANGE attribute for arrays and a

SET RANGE statement that sets the subscript ranges within the declared

ranges. There are also additional intrinsic enquiry functions for the

ranged bounds, size and shape.

ll.     Pointers

        Pointers were not discussed at this meeting except for a straw

vote on whether they should be on the list of items for the next

meeting, which was undecided (11-8-6). I asked for this vote since I

prepared a proposal for the September meeting, which has not been


l2.     Conformance

        My proposal on conformance [3] was discussed, and it was clear

that it was not ready for a formal vote. I was clearly wrong in

suggesting removing the use of "must" and "must not" to indicate

requirements and prohibitions, since the document is being written

this way. My proposal also suggested placing a list of errors in an

appendix and requiring some indication of how the processor treats

each. I became convinced that the list would have to go in the

standard itself and I am worried about the time it will take to

produce the list and gain acceptance for it. The chairman would

prefer this material in some companion standard.


To:         BCS, NAG, etc.

From:       John Reid

Date:       27 January 1986

Subject:    Report on X3J3 meeting at Sunnyvale, 20-24 January 1986

Note:       This is a personal report on the meeting and in no sense

            does it constitute an official record of it.

l.      Summary

        A significant vote was taken at this meeting. On a roll-call

vote, l7-11, it was decided that the time has arrived for a letter

ballot of the committee as to whether the draft standard is ready for

release for public comment. The response to this ballot has to be "no

with reasons", "yes", or "yes with comments". The chairman has asked

those voting "no" or "yes with comments" to bring technical proposals,

with text for the draft standard, to the next meeting. The committee

will seek to reach a consensus with noes replaced by yeses and

comments resolved. If consensus proves impossible, it is allowed to

proceed with a 2/3 majority in favour.

        The probable reason for most of the 11 votes against a letter

ballot now is that the draft standard (S8) is not yet a polished

document, although it is improving fast (see section 3, below). I

voted "yes" because I want to process "in parallel" both technical

objections and editorial changes to the document, in the hope of

public release in the summer of this year. The IBM representative,

Dick Weaver, and a significant number of other members think that F8x

is too large (see section 7). The letter ballot will require each

member to state his or her position clearly and work on proposals to

correct the objections.

        Most of the meeting was spent on detailed editorial improvements

to the document. We also made a significant change to the

interpretation of "deprecated" (see section 6), considered pass-on

precision, and extended the list of objects permitted as dummy

arguments to include allocatable arrays.

2.      Passed-on precision

        Good progress was made with the "combinatorial explosion"

problem associated with passed-on precision and exponent-range

parameters, though it was not fully resolved. The problem occurs

because (as things are now) on a machine with 3 precisions there would

be 3n versions of a procedure with n arguments having passed-on

precision. For example, there would be 35 versions of

                SUBROUTINE MANY(A,B,C,D,E)


The favoured solution is to allow a dummy argument to be declared with

the precision of itself so that the above becomes


if all five arguments are intended to have the same precision and five

separate declarations are needed if five independent precisions are

really wanted. It turns out to be important that intrinsics are not

available for the declared precisions, so comparable rules are needed

for derived types (e.g. for a type holding matrices).

3.      Editorial changes to the draft standard

        Very early in the meeting, it was decided to require a formal

vote for any change to the draft standard. This resulted in a very

large number of editorial papers, most of which were block proposals

containing many changes. The advantage is that there is a record of

every change that the committee made and any disagreements (e.g.

between the editor and a subgroup) were exposed.

        These changes have greatly improved the document, but it is not

yet ready for public release. A particular problem is that the

section on scoping has not been adequately revised in the light of

nested internal procedures, type definitions, and interface blocks.

4.      Bit data for masking

        It was agreed by unanimous or near-unanimous votes to allow bit

data as an alternative to logical data for masking in the intrinsic

functions, WHERE, FORALL, IF, and CASE.

5.      Allocatable dummy arguments

        Functions whose results are allocatable arrays are already

permitted and it was agreed (19-7) to extend this to procedure

arguments. It was decided that it was inappropriate to permit intent

(IN, OUT, or INOUT) specification for such arguments. This is because

it is not obvious whether the intent should apply just to the

allocation status or to this and the actual value; in either case

an intent IN argument would be better as an assumed-shape array.

6.      Deprecated features

        Dick Weaver proposed strengthening the interpretation of

"deprecated" to say that the deprecated features "are intended to be

removed from the next version of the Fortran standard". He wishes to

provide firmer direction to users of the language making business

decisions about investing in revision of existing software. I was

opposed because of the cost of making such changes during just one

revision cycle. I was comfortable with the previous wording which I

interpreted as giving a strong push against use of the deprecated

features, while not actually leading to removal until their use drops

to a low level. The proposal passed (22-5).

7.      Size of the language

        Dick Weaver suggested (without text changes to the draft

standard) that modules, internal procedures, recursive procedures,

derived data types, and exception handling all be removed. He

believes that the language is larger than PLI or Ada and will not meet

the need of the community for a small, easy to learn, language with

simple and efficient computational model. He supported his case by

counts of numbers of statements, BNF rules, keywords, and intrinsic

procedures. It was not generally agreed that this provides an adequate metric

for comparing the sizes of languages. Jerry Wagener pointed out that it

indicates that Ada and Fortran 77 are very similar in size. On the basis of

the count of BNF rules, the Weaver proposal would reduce F8x by about 20% and

approximately halve the increment from F77.




l.l. David Harris works for Alpha Comp Ltd located at Wareham, Dorset

who are a DEC OEM. He is also Chairman of DECUS (UK). In earlier days

he worked at the Atomic Energy Authority and his earliest computer

experiences were with the Ferranti Mercury. He did a lot of work there

on fluid flows and then set up his own firm Alpha Comp Ltd to do work

on simulators.

1.2. Why simulate?

        l.   To improve understanding of the process one was

             trying to model;

        2.   It was cheaper to do a computer simulation than

             actually build something in real life.

1.3.    Examples of simulators:-

        Flight simulators - reduced pilot training costs;

        Chemical plant control system - optimise yields and

        ensure safe operation.

1.4.    Design considerations for a simulation package:-

        Easy to use, eg menu facility;

        Interactive displays;

        Portable to real time;

        Output in many forms;

        Easy interface to other modules.

1.5.    Most simulation packages are Fortran based, but very

        few are portable to real-time.

1.6.    Advantages of VAX for simulation:-

        Virtual memory - reduces programming problems;

        Accuracy of 32 bit word;

        Extent of software available;

        Cheapness compared with mainframes.

        Disadvantages of VAX:-

        Not so good value for money as PDP/11 for simulations;

        Not suitable for real-time interfaces.

l.7.    Advantages of PDP/11 for simulations:-

        Cheaper than VAX;

        Cost effective to dedicate a single machine to a study;

        Can interface to real world.

        Disadvantages of PDP/11:-

        Slower than VAX;

        l6 bit word offers reduced numeric accuracy;

        Lack of available software, eg NAG.

1.8.    For dynamic simulation the only languages worth considering are Fortran

        and Pascal even though MOD are putting up a rearguard action on Ada.

l.9.        DEC operating systems:-

        RT ~ single user with multiple jobs spawned by one user;

        RSTS - Resource shared executive aimed at the commercial

        environment where each user shares time/resources.

l.l0.        Unix and RSX:-

Bell Labs were using PDP/11 and wanted to do things in a real-time

environment; so they wrote their own operating system (Unix) to meet

the needs in this area which the native one could not provide. Later

DEC developed RSX (Real-time shared executive) which was much more

user friendly and secure than Unix. It is a multi-user operating

system in which each user can multi-task with different priorities. It

provides very high transfer rates to the real world and an environment

offering lots of facilities to the Fortran programmer. It is also well


l.ll.   Which simulation package should one choose?

        Visicalc   - offers very cheap runs on small machines

                     but can only handle small problems. It

                     is easy for the non-expert to get the

                     wrong results.

        ACSL       - the other end of the spectrum from Visicalc

                     and very expensive.

        Alphasim   - an Alpha-Comp product which runs on lots

                     of DEC machines. It is interactive, written

                     in Fortran, can provide graphical outputs

                     and allows incorporation of other modules,

                     eg, NAG library.

l.l2.   The future:-

Array processors offer good possibilities. In David's opinion PDP + array

processor would be more cost effective in this area than a VAX. He also

thought that Gould hardware offers the best value for money for simulation

although they have not got a good operating system.

l.l3. DEC products:-

David considers them of good quality and very reliable.